分布式網站架構設計

1、求完整版的 《大型分布式網站架構設計與實踐》pdf 電子書

《大型分布式網站架構設計與實踐》主要介紹了大型分布式網站架構所涉及的一些技術細節，包括SOA架構的實現、互聯網安全架構、構建分布式網站所依賴的基礎設施、系統穩定性保障和海量數據分析等內容；深入地講述了大型分布式網站架構設計的核心原理，並通過一些架構設計的典型案例，幫助讀者了解大型分布式網站設計的一些常見場景及遇到的問題。

2、lamp的網站架構方案

LAMP（Linux- Apache-MySQL-PHP）網站架構是目前國際流行的Web框架，該框架包括：Linux操作系統，Apache網路伺服器，MySQL數據 庫，Perl、PHP或者Python編程語言，所有組成產品均是開源軟體，是國際上成熟的架構框架，很多流行的商業應用都是採取這個架構，和 Java/J2EE架構相比，LAMP具有Web資源豐富、輕量、快速開發等特點，微軟的.NET架構相比，LAMP具有通用、跨平台、高性能、低價格的 優勢，因此LAMP無論是性能、質量還是價格都是企業搭建網站的首選平台。
對於大流量、大並發量的網站系統架構來說，除了硬體上使用高 性能的伺服器、負載均衡、CDN等之外，在軟體架構上需要重點關注下面幾個環節：使用高性能的操作系統（OS）、高性能的網頁伺服器（Web Server）、高性能的資料庫（Database）、高效率的編程語言等。下面我將從這幾點對其一一討論。
操作系統
Linux操作系統有很多個不同的發行版，如Red Hat Enterprise Linux、SUSE Linux Enterprise、Debian、Ubuntu、CentOS等，每一個發行版都有自己的特色，比如RHEL的穩定，Ubuntu的易用，基於穩定性 和性能的考慮，操作系統選擇CentOS（Community ENTerprise Operating System）是一個理想的方案。
CentOS（Community ENTerprise Operating System）是Linux發行版之一，是RHEL/Red Hat Enterprise Linux的精簡免費版，和RHEL為同樣的源代碼，不過，RHEL和SUSE LE等企業版，提供的升級服務均是收費升級，無法免費在線升級，因此要求免費的高度穩定性的伺服器可以用CentOS替代Red Hat Enterprise Linux使用。
Web伺服器、緩存和PHP加速
Apache是LAMP架構最核心的Web Server，開源、穩定、模塊豐富是Apache的優勢。但Apache的缺點是有些臃腫，內存和CPU開銷大，性能上有損耗，不如一些輕量級的Web 伺服器（例如nginx）高效，輕量級的Web伺服器對於靜態文件的響應能力來說遠高於Apache伺服器。
Apache做為Web Server是負載PHP的最佳選擇，如果流量很大的話，可以採用nginx來負載非PHP的Web請求。nginx是一個高性能的HTTP和反向代理服 務器，Nginx以它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。Nginx不支持PHP和CGI等動態語言，但支持負載均衡和容 錯，可和Apache配合使用，是輕量級的HTTP伺服器的首選。
Web伺服器的緩存也有多種方案，Apache提供了自己的緩存模 塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。Squid Cache是一個Web緩存伺服器，支持高效的緩存，可以作為網頁伺服器的前置cache伺服器緩存相關請求來提高Web伺服器的速度，把Squid放在 Apache的前端來緩存Web伺服器生成的動態內容，而Web應用程序只需要適當地設置頁面實效時間即可。如訪問量巨大則可考慮使用memcache作 為分布式緩存。
PHP的加速使用eAccelerator加速器，eAccelerator是一個自由開放源碼PHP加速器，優化和動 態內容緩存，提高了性能PHP腳本的緩存性能，使得PHP腳本在編譯的狀態下，對伺服器的開銷幾乎完全消除。它還有對腳本起優化作用，以加快其執行效率。 使PHP程序代碼執效率能提高1-10倍。
具體的解決方案有以下幾種：
1、squid + Apache + PHP + eAccelerator
使用Apache負載PHP，使用squid進行緩存，html或圖片的請求可以直接由squid返回給用戶。很多大型網站都採用這種架構。
2、nginx/Apache + PHP（fastcgi） + eAccelerator
使用nginx或Apache負載PHP，PHP使用fastcgi方式運行，效率較高。
3、nginx + Apache + PHP + eAccelerator
此方案綜合了nginx和Apache的優點，使用Apache負載PHP，nginx負責解析其他Web請求，使用nginx的rewrite模塊，Apache埠不對外開放。
資料庫
開源的資料庫中，MySQL在性能、穩定性和功能上是首選，可以達到百萬級別的數據存儲，網站初期可以將MySQL和Web伺服器放在一起，但是當訪問 量達到一定規模後，應該將MySQL資料庫從Web Server上獨立出來，在單獨的伺服器上運行，同時保持Web Server和MySQL伺服器的穩定連接。
當資料庫訪問量達到更大的級別，可以考慮使用MySQL Cluster等資料庫集群或者庫表散列等解決方案。
總的來說，LAMP架構的網站性能會遠遠優於Windows IIS + ASP + Access（例如月光博客）這樣的網站，可以負載的訪問量也非常大，國內的大量個人網站如果想要支撐大訪問量，採用LAMP架構是一個不錯的方案。
綜上所述，基於LAMP架構設計具有成本低廉、部署靈活、快速開發、安全穩定等特點，是Web網路應用和環境的優秀組合。

3、什麼是分布式集群？

分布式與集群是不一樣的，簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。

如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。

採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。

而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整體來看，還是1小時內完成一個任務。

(3)分布式網站架構設計擴展資料

分布式系統可以分為機體內系統、建築物內系統、建築物間系統和不同地理范圍的區域系統等，它們的耦合度依次由高到低按應用領域的性質決定耦合度，可以分成三類：

一、是面向計算任務的分布並行計算機系統和分布式多用戶計算機系統，它們要求盡可能高的耦合度，以便發展成為能分擔大型計算機和分時計算機系統所完成的工作。

二、是面向管理信息的分布式數據處理系統。耦合度可以適當降低。

三、是面向過程式控制制的分布式計算機控制系統。耦合度要求適中，當然對於某些實時應用，其耦合度的要求可能很高。

4、何謂分布式伺服器，怎麼理解分布式服務框架

分布式是架構部署模式的一種。分布式多用於描述架構設計上，當然現在有各種新用法。
集群是硬體部署模式的一種，是集中部署在一個機房裡的計算機群體的集中稱謂。
分布式網站集群系統是一種多網站架構模式，支持生成獨立網站、多個網站,完成各個網站橫向一體化和縱向一體化網站群的構建，主站、子站、網站間的信息可共享和信息互聯。
簡單的說：　就是一個企業/個人可以像申請博客那樣自助建站，維護，更新，而分布式，就是把問題分開解決的意思，即系統分布在幾個不同伺服器上。

5、大型分布式網站架構設計與實踐 怎麼樣

大型分布式網站架構設計與實踐 這本書 的點評如下：
書中提到了很多大型分布式網站設計所必須的知識點，如soa、分布式系統的基礎設施，
系統穩定性設計，數據分析，系統穩定設計的章節寫的很有實踐性，
自檢腳本的編寫、日誌分析命令的妙用，互聯網安全方面之前講類似知識點的，
書中介紹的比較詳細，不錯
還有疑問請追問沒有疑問請採納。

6、大型網站架構模式有哪些

1.分布式
對於大型網站，分層和分割的一個主要目的是為了切分後的模塊便於分布式部署，即將不同模塊部署在不同的伺服器上，通過遠程調用協同工作。分布式意味著可以使用更多的計算機完成同樣的功能，計算機越多，CPU、內存、存儲資源也就越多，能夠處理的並發訪問和數據量就越大，進而能夠為更多的用戶提供服務。
2.分層
分層是企業應用系統中最常見的一種架構模式，將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和調用組成一個完整的系統。
分層結構在計算機世界中無處不在，網路的7層通信協議是一種分層結構；計算機硬體、操作系統、應用軟體也可以看作是一種分層結構。在大型網站架構中也採用分層結構，將網站軟體系統分為應用層、服務層、數據層。
3.分割
如果說分層是將軟體在橫向方面進行切分，那麼分割就是在縱向方面對軟體進行切分。
網站越大，功能越復雜，服務和數據處理的種類也越多，將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，一方面有助於軟體的開發和維護；另一方面，便於不同模塊的分布式部署，提高網站的並發處理能力和功能擴展能力。
4.集群
使用分布式雖然已經將分層和分割後的模塊獨立部署，但是對於用戶訪問集中的模塊（比如網站的首頁），還需要將獨立部署的伺服器集群化，即多台伺服器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。
5.緩存
緩存就是將數據存放在距離計算最近的位置以加快處理速度。緩存是改善軟體性能的第一手段，現代CPU越來越快的一個重要因素就是使用了更多的緩存，在復雜的軟體設計中，緩存幾乎無處不在。大型網站架構設計在很多方面都使用了緩存設計。
6.非同步
計算機軟體發展的一個重要目標和驅動力是降低軟體耦合性。事物之間直接關系越少，就越少被彼此影響，越可以獨立發展。大型網站架構中，系統解耦合的手段除了前面提到的分層、分割、分布等，還有一個重要手段是非同步，業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式非同步執行進行協作。

7、求 《大型分布式網站架構設計與實踐》陳康賢 全章 PDF

我幫你下好了共享的我的網路雲盤裡面了請去下載記得好評哦~哈哈

8、分布式系統的非同步處理流程通常有哪些設計解決方案

開源軟體已經成為許多大型網站的基本組成部分，隨著這些網站的逐步壯大，他們的網站架構和一些指導原則也出現在開發者們的面前，給予切實有用的指導和幫助。本文旨在介紹一些核心問題以及通過構建模塊來製作大型網站，實現最終目標。 這篇文章主要側重於Web系統，並且也適用於其他分布式系統。 Web分布式系統設計的原則 構建並運營一個可伸縮的Web站點或應用程序到底指的是什麼?在最初，僅是通過互聯網連接用戶和訪問遠程資源。 和大多數事情一樣，當構建一個Web服務時，需要提前抽出時間進行規劃。了解大型網站創建背後的注意事項以及權衡可能會給你帶來更加明智的決策，當你在創建小網站時。下面是設計大型Web系統時，需要注意的一些核心原則： 1.可用性 2.性能 3.可靠性 4.可擴展 5.易管理 6.成本 上面的這些原則給設計分布式Web架構提供了一定的基礎和理論指導。然而，它們也可能彼此相左，例如實現這個目標的代價是犧牲成本。一個簡單的例子：選擇地址容量，僅通過添加更多的伺服器(可伸縮性)，這個可能以易管理(你不得不操作額外的伺服器)和成本作為代價(伺服器價格)。 無論你想設計哪種類型的Web應用程序，這些原則都是非常重要的，甚至這些原則之間也會互相羈絆，做好它們之間的權衡也非常重要。 基礎 當涉及到系統架構問題時，這幾件事情是必須要考慮清楚的：什麼樣的模塊比較合適?如何把它們組合在一起?如何進行恰當地權衡?在擴大投資之前，它通常需要的並不是一個精明的商業命題，然而，一些深謀遠慮的設計可以幫你在未來節省大量的時間和資源。 討論的重點幾乎是構建所有大型Web應用程序的核心：服務、冗餘、分區和故障處理能力。這里的每個因素都會涉及到選擇和妥協，特別是前面所討論的那些原則。解釋這些核心的最佳辦法就是舉例子。 圖片託管應用程序 有時，你會在線上傳圖片，而一些大型網站需要託管和傳送大量的圖片，這對於構建一個具有成本效益、高可用性並具有低延時(快速檢索)的架構是一項挑戰。 在一個圖片系統中，用戶可以上傳圖片到一個中央伺服器里，通過網路連接或API對這些圖片進行請求，就像Flickr或者Picasa。簡單點，我們就假設這個應用程序只包含兩個核心部分：上傳(寫)圖片和檢索圖片。圖片上傳時最好能夠做到高效，傳輸速度也是我們最關心的，當有人向圖片發出請求時(例如是一個Web頁面或其他應用程序)。這是非常相似的功能，提供Web服務或內容分發網路(一個CDN伺服器可以在許多地方存儲內容，所以無論是在地理上還是物理上都更加接近用戶，從而導致更快的性能)邊緣伺服器。 該系統需要考慮的其他重要方面： 1.圖片存儲的數量是沒有限制的，所以存儲應具備可伸縮，另外圖片計算也需要考慮 2.下載/請求需要做到低延遲 3.用戶上傳一張圖片，那麼圖片就應該始終在那裡(圖片數據的可靠性) 4.系統應該易於維護(易管理) 5.由於圖片託管不會有太高的利潤空間，所以系統需要具備成本效益 圖1是個簡化的功能圖 圖1 圖片託管系統的簡化結構圖 在這個例子中，系統必須具備快速、數據存儲必須做到可靠和高度可擴展。構建一個小型的應用程序就微不足道了，一台伺服器即可實現託管。如果這樣，這篇文章就毫無興趣和吸引力了。假設我們要做的應用程序會逐漸成長成Flickr那麼大。 服務 當我們考慮構建可伸縮的系統時，它應有助於解耦功能，系統的每個部分都可以作為自己的服務並且擁有清晰的介面定義。在實踐中，這種系統設計被稱作面向服務的體系結構(SOA)。對於此類系統，每個服務都有它自己的獨特功能，通過一個抽象介面可以與外面的任何內容進行互動，通常是面向公眾的另一個服務 API。 把系統分解成一組互補性的服務，在互相解耦這些操作塊。這種抽象有助於在服務、基本環境和消費者服務之間建立非常清晰的關系。這種分解可以有效地隔離問題，每個塊也可以互相伸縮。這種面向服務的系統設計與面向對象設計非常相似。 在我們的例子中，所有上傳和檢索請求都在同一台伺服器上處理。然而，因為系統需要具備可伸縮性，所以把這兩個功能打破並集成到自己的服務中是有意義的。 快進並假設服務正在大量使用;在這種情況下，很容易看到寫圖片的時間對讀圖片時間有多大影響(他們兩個功能在彼此競爭共享資源)。根據各自體系，這種影響會是巨大的。即使上傳和下載速度相同(這是不可能的，對於大多數的IP網路來說，下載速度：上傳速度至少是3:1)，通常，文件可以從緩存中讀取，而寫入，最終是寫到磁碟中(也許在最終一致的情況下，可以被多寫幾次)。即使是從緩存或者磁碟(類似SSD)中讀取，數據寫入都會比讀慢(Pole Position，一個開源DB基準的開源工具和結果)。 這種設計的另一個潛在問題是像Apache或者Lighttpd這些Web伺服器通常都會有一個並發連接數上限(默認是500，但也可以更多)，這可能會花費高流量，寫可能會迅速消掉所有。既然讀可以非同步或利用其他性能優化，比如gzip壓縮或分塊傳輸代碼，Web服務可以快速切換讀取和客戶端來服務於更多的請求，超過每秒的最大連接數(Apache的最大連接數設置為500，這種情況並不常見，每秒可以服務幾千個讀取請求)。另一方面，寫通常傾向於保持一個開放的鏈接進行持續上傳，所以，使用家庭網路上傳一個1 MB的文件花費的時間可能會超過1秒，所以，這樣的伺服器只能同時滿足500個寫請求。 圖2：讀取分離 規劃這種瓶頸的一個非常好的做法是把讀和寫進行分離，如圖2所示。這樣我們就可以對它們單獨進行擴展(一直以來讀都比寫多)但也有助於弄明白每個點的意思。這種分離更易於排除故障和解決規模方面問題，如慢讀。 這種方法的優點就是我們能夠彼此獨立解決問題——在同種情況下，無需寫入和檢索操作。這兩種服務仍然利用全球語料庫的圖像，但是他們可以自由地優化性能和服務方法(例如排隊請求或者緩存流行圖片——下面會介紹更多)。從維護和成本角度來看，每一個服務都可以根據需要獨立進行擴展，但如果把它們進行合並或交織在一起，那麼有可能無意中就會對另一個性能產生影響，如上面討論的情景。 當然，如果你有兩個不同的端點，上面的例子可能會運行的很好(事實上，這非常類似於幾個雲存儲供應商之間的實現和內容分發網路)。雖然有很多種方法可以解決這些瓶頸，但每個人都會有不同的權衡，所以採用適合你的方法才是最重要的。 例如，Flickr解決這個讀/寫問題是通過分發用戶跨越不同的碎片，每個碎片只能處理一組用戶，但是隨著用戶數的增加，更多的碎片也會相應的添加到群集里(請參閱Flickr的擴展介紹)。在第一個例子中，它更容易基於硬體的實際用量進行擴展(在整個系統中的讀/寫數量)，而Flickr是基於其用戶群進行擴展(but forces the assumption of equal usage across users so there can be extra capacity)。而前面的那個例子，任何一個中斷或者問題都會降低整個系統功能(例如任何人都沒辦法執行寫操作)，而Flickr的一個中斷只會影響到其所在碎片的用戶數。在第一個例子中，它更容易通過整個數據集進行操作——例如，更新寫服務，包括新的元數據或者通過所有的圖片元數據進行搜索——而 Flickr架構的每個碎片都需要被更新或搜索(或者需要創建一個搜索服務來收集元數據——事實上，他們就是這樣做的)。 當談到這些系統時，其實並沒有非常正確的答案，但有助於我們回到文章開始處的原則上看問題。確定系統需求(大量的讀或寫或者兩個都進行、級別並發、跨數據查詢、范圍、種類等等)，選擇不同的基準、理解系統是如何出錯的並且對以後的故障發生情況做些扎實的計劃。 冗餘 為了可以正確處理錯誤，一個Web架構的服務和數據必須具備適當的冗餘。例如，如果只有一個副本文件存儲在這台單獨的伺服器上，那麼如果這台伺服器出現問題或丟失，那麼該文件也隨即一起丟失。丟失數據並不是什麼好事情，避免數據丟失的常用方法就是多創建幾個文件或副本或冗餘。 同樣也適用於伺服器。如果一個應用程序有個核心功能，應確保有多個副本或版本在同時運行，這樣可以避免單節點失敗。 在系統中創建冗餘，當系統發生危機時，如果需要，可以消除單點故障並提供備份或備用功能。例如，這里有兩個相同的服務示例在生產環境中運行，如果其中一個發生故障或者降低，那麼該系統容錯轉移至那個健康的副本上。容錯轉移可以自動發生也可以手動干預。 服務冗餘的另一重要組成部分是創建一個無共享架構。在這種體系結構中，每個節點都能相互獨立運行，並且沒有所謂的中央“大腦”管理狀態或協調活動其他節點。這對系統的可擴展幫助很大，因為新節點在沒有特殊要求或知識的前提下被添加。然而，最重要的是，這些系統是沒有單點故障的，所以失敗的彈性就更大。 例如在我們的圖片伺服器應用程序中，所有的圖片在另一個硬體上都有冗餘副本(理想情況下是在不同的地理位置，避免在數據中心發生一些火災、地震等自然事故)，服務去訪問圖片將被冗餘，所有潛在的服務請求。(參見圖3：採用負載均衡是實現這點的最好方法，在下面還會介紹更多方法) 圖3 圖片託管應用程序冗餘 分區 數據集有可能非常大，無法安裝在一台伺服器上。也有可能這樣，某操作需要太多的計算資源、性能降低並且有必要增加容量。在這兩種情況下，你有兩種選擇：縱向擴展或橫向擴展。 縱向擴展意味著在單個伺服器上添加更多的資源。所以，對於一個非常大的數據集來說，這可能意味著添加更多(或更大)的硬體設備，來使一台伺服器能容下整個數據集。在計算操作下，這可能意味著移動計算到一個更大的伺服器上，擁有更快的CPU或更大的內存。在各種情況下，縱向擴展可以通過提升單個資源的處理能力來完成。 橫向擴展在另一方面是添加更多的節點，在大數據集下，這可能會使用第二伺服器來存儲部分數據集，對於計算資源來說，這意味著分割操作或跨節點載入。為了充分利用橫向擴展，它應作為一種內在的系統架構設計原則，否則修改或拆分操作將會非常麻煩。 當談到橫向擴展時，最常見的做法是把服務進行分區或碎片。分區可以被派發，這樣每個邏輯組的功能就是獨立的。可以通過地理界限或其他標准，如非付費與付費用戶來完成分區。這些方案的優點是他們會隨著容量的增加提供一個服務或數據存儲。 在我們的圖片伺服器案例中，用來存儲圖片的單個文件伺服器可能被多個文件伺服器取代，每個裡面都會包含一套自己獨特的圖像。(見圖4)這種架構將允許系統來填充每一個文件/圖片伺服器，當磁碟填滿時會添加額外的伺服器。這樣的設計需要一個命名方案，用來捆綁圖片文件名到其相應的伺服器上。圖像名字可以形成一個一致的哈希方案並映射到整個伺服器上;或者給每張圖片分配一個增量ID，當客戶端對圖片發出請求時，圖片檢索服務只需要檢索映射到每個伺服器上(例如索引)的ID。 圖4 圖片託管應用程序冗餘和分區 當然，跨越多個伺服器對數據或功能進行分區還是有許多挑戰的。其中的關鍵問題是數據本地化。在分布式系統中，數據操作或計算點越接近，系統性能就會越好。因此，它也可能是個潛在問題，當數據分散在多個伺服器上時。有時數據不是在本地，那麼就要迫使伺服器通過網路來獲取所需的信息，這個獲取的過程就會設計到成本。 另一潛在問題是不一致。當這里有多個服務對一個共享資源執行讀寫操作時，潛在可能會有另一個伺服器或數據存儲參與進來，作為競選條件——一些數據需要更新，但是讀的優先順序高於更新——在這種情況下，數據就是不一致的。例如在圖片託管方案中，有可能出現的不一致是：如果一個客戶端發送更新“狗”圖片請求，進行重新命名，把“Dog”改成“Gizmo”，但同時，另一個客戶端正在讀這張圖片。在這種情況下，標題就是不清楚的。“Dog”或“Gizmo” 應該被第二個客戶端接收。 當然，在進行數據分區時會產生一些障礙，但是分區允許把每個問題拆分到管理群里——通過數據、負載、使用模式等。這樣對可擴展和易管理都是有幫助的，但也不是沒有風險的。這里有很多方式來降低風險和故障處理;然而，為了簡便起見，並未在本文中詳細說明，如果你有興趣，可以訪問我的博客。 總結 以上介紹的都是設計分布式系統需要考慮的核心要素。可用性、性能、可靠性、可擴展、易管理、成本這幾個原則非常重要，但在實際應用中可能會以犧牲某個原則來實現另外一個原則，在這個過程中就要做好權衡工作，做到因時制宜。 在下面的構建分布式系統實戰中，我們將會深入介紹如何設計可擴展的數據訪問，包括負載均衡、代理、全局緩存、分布式緩存等。 英文地址：Dr.Dobb's 文：CSDN