通過訪問與海量數(shù)據(jù)處理和搜索引擎相關(guān)的許多技術(shù)，我們經(jīng)常會看到許多精美的架構(gòu)圖。除了在每個圖表表面上嘆息圖紙的精細度之外，還隱藏了隱藏在架構(gòu)圖背后的設(shè)計理念。過去兩天我一直在收集大型網(wǎng)站的架構(gòu)設(shè)計圖紙。為了享受各種大型網(wǎng)站架構(gòu)設(shè)計的興奮，第二個也可用于休閑時間和排練。為什么不？在此，總結(jié)如外國維基百科，F(xiàn)acebook，雅虎！YouTube，MySpace，Twitter，國內(nèi)技術(shù)如優(yōu)酷等大型網(wǎng)站技術(shù)架構(gòu)（本文重點介紹優(yōu)酷的技術(shù)架構(gòu)），給讀者。本文重點介紹每張圖片的亮點及其背后的含義，同時簡化了圖的說明文字。好的，享受這個建筑盛宴。當(dāng)然，如果您有任何建議或疑問，請不要猶豫，糾正我。謝謝。 1. WikiPedia技術(shù)架構(gòu) WikiPedia技術(shù)架構(gòu)從維基百科復(fù)制@Mark Bergsma數(shù)據(jù)：峰值每秒30,000次HTTP請求每秒3Gbit流量，近375MB350臺PC服務(wù)器。 GeoDNSA：BIND的40行補丁，為BIND'中的現(xiàn)有視圖添加地理過濾器支持，將用戶帶到附近的服務(wù)器。 GeoDNS在WikiPedia架構(gòu)中的角色當(dāng)然取決于WikiPedia內(nèi)容的性質(zhì) - 適用于每個國家和地區(qū)。負載均衡：LVS，請參見下圖：。 2，F(xiàn)acebook架構(gòu) Facebook搜索功能架構(gòu)圖細心的讀者將能夠發(fā)現(xiàn)本文中出現(xiàn)的上層子架構(gòu)：從幾個架構(gòu)圖中竊取一點航海數(shù)據(jù)處理經(jīng)驗。本文與前一篇文章的區(qū)別在于前幾篇文章中只有少數(shù)幾篇。這個系列將有數(shù)百個架構(gòu)圖供您欣賞。 3.雅虎！郵件架構(gòu) Yahoo!郵件架構(gòu)雅虎！郵件體系結(jié)構(gòu)部署Oracle RAC以存儲與郵件服務(wù)相關(guān)的元數(shù)據(jù)。 4，twitter技術(shù)架構(gòu) twitter整體架構(gòu)設(shè)計圖Twitter平臺大致由twitter.com，手機和第三方應(yīng)用組成，如下圖所示（其中流量主要基于手機和第三方）：緩存大web該項目發(fā)揮了關(guān)鍵作用，因為數(shù)據(jù)更接近CPU并且速度越快。下圖是緩存緩存圖：關(guān)于緩存系統(tǒng)，您還可以查看下圖： 5，Google App Engine技術(shù)架構(gòu) GAE架構(gòu)圖簡單來說，上面的GAE架構(gòu)如圖所示分為三部分：前端，數(shù)據(jù)存儲區(qū)和服務(wù)組。前端由4個模塊組成：前端，靜態(tài)文件，App Server，App Master。 Datastore是一個基于BigTable技術(shù)的分布式數(shù)據(jù)庫。雖然它也可以理解為服務(wù)，但它是App Engine中的一個非常核心的模塊，因為它是整個App Engine存儲持久數(shù)據(jù)的地方。具體細節(jié)將在下一節(jié)中討論。 整個服務(wù)組包括許多App Server調(diào)用服務(wù)，例如Memcache，圖形，用戶，URL爬網(wǎng)和任務(wù)隊列。 6，亞馬遜技術(shù)架構(gòu)亞馬遜的Dynamo Key-Value存儲架構(gòu)圖可能是亞馬遜不熟悉的讀者，它現(xiàn)在是全球最大的各種在線零售商和全球第二大互聯(lián)網(wǎng)公司。之前它只是一個小型的在線書店。好的，我們來看看它的架構(gòu)。 Dynamo是亞馬遜的鍵值模式存儲平臺，具有良好的可用性和可擴展性以及良好的性能：99.9％的讀寫訪問響應(yīng)時間在300ms內(nèi)。數(shù)據(jù)根據(jù)分布式系統(tǒng)中常用的散列算法進行劃分，并放置在不同的節(jié)點上。當(dāng)執(zhí)行讀取操作時，它還基于密鑰的哈希值搜索相應(yīng)的節(jié)點。 Dynamo使用Consistent Hashing算法。該節(jié)點對應(yīng)于某個散列值，但是對應(yīng)于散列值范圍。如果密鑰散列值落在此范圍內(nèi)，則沿著環(huán)順時針找到它。需要。 Dynamo對Consistent Hashing算法的改進是它將環(huán)上的一組機器作為節(jié)點（而不是memcached作為節(jié)點）。這組機器通過同步機制保證數(shù)據(jù)的一致性。 下圖是分布式存儲系統(tǒng)的示意圖，讀者可以觀察到它：亞馬遜的云架構(gòu)如下：亞馬遜的云架構(gòu)圖7，優(yōu)酷的技術(shù)架構(gòu)從一開始，優(yōu)酷已經(jīng)建立了一個CMS解決方案 - 結(jié)束頁面顯示，模塊之間的分離比較合適，前端的可擴展性非常好，UI的分離，使得開發(fā)和維護變得非常簡單靈活，下圖是優(yōu)酷前端的模塊調(diào)用關(guān)系 - 結(jié)束：基于模塊，方法和參數(shù)確定相對獨立的模塊非常簡單。下圖顯示優(yōu)酷的前端部分架構(gòu)：優(yōu)酷的數(shù)據(jù)庫架構(gòu)也經(jīng)歷了許多曲折，從單個MySQL服務(wù)器（Just Running）開始到簡單的MySQL主從復(fù)制，SSD優(yōu)化，垂直庫，水平分片子庫。簡單的MySQL主從復(fù)制。 MySQL主從復(fù)制解決了數(shù)據(jù)庫的讀寫分離問題，提高了讀取性能。原始圖片如下：主從復(fù)制的過程如下：然而，主從復(fù)制也帶來了其他一系列性能瓶頸：寫入無法擴展寫入無法緩存復(fù)制延遲鎖定表率增加表變大，緩存率降低，問題將永遠得到解決，從而產(chǎn)生以下優(yōu)化方案。 MySQL垂直分區(qū)如果業(yè)務(wù)被獨立切割，將不同的業(yè)務(wù)數(shù)據(jù)放入不同的數(shù)據(jù)庫服務(wù)器是個好主意，如果其中一個服務(wù)崩潰，它不會影響其他服務(wù)的正常運行，也會影響它負載分流的作用，大大提高了數(shù)據(jù)庫的吞吐量。 垂直分區(qū)后的數(shù)據(jù)庫模式如下：但是，雖然服務(wù)彼此之間足夠獨立，但某些服務(wù)總是或多或少地連接起來，例如用戶，基本上與每個業(yè)務(wù)相關(guān)聯(lián)，而這種分區(qū)方法可以解決單表數(shù)據(jù)暴漲的問題，為什么不嘗試水平分片？ MySQL水平分片（Sharding）這是一個非常好的主意，分組用戶按照一定的規(guī)則（通過id hash），并將用戶組的數(shù)據(jù)存儲到數(shù)據(jù)庫分片中，即分片，所以作為數(shù)量用戶增加，只需配置服務(wù)器。原理圖如下：如何確定用戶的分片，可以創(chuàng)建與用戶和分片對應(yīng)的數(shù)據(jù)表。找到用戶的分片ID，然后從相應(yīng)的分片查詢相關(guān)數(shù)據(jù)，如下所示：然而，優(yōu)酷如何解決交叉分片查詢？這是一個難點。根據(jù)介紹，優(yōu)酷試圖不跨越分片查詢。對于多維碎片索引和分布式搜索引擎，缺點是分布式數(shù)據(jù)庫查詢（這非常麻煩并且消耗性能）。緩存策略看起來像一個大系統(tǒng)對“緩存”有一個情有獨鐘，從http緩存到memcached內(nèi)存數(shù)據(jù)緩存，但優(yōu)酷表示沒有內(nèi)存緩存，原因如下：避免內(nèi)存復(fù)制，避免內(nèi)存鎖，如果您收到來自大哥的通知刪除視頻，如果緩存中很麻煩并且Squid的write（）用戶進程空間被占用，則Lighttpd 1.5的AIO（異步I/O）將文件讀取到用戶內(nèi)存并且更少高效。 但是為什么我們訪問優(yōu)酷會如此順利，相比土豆，優(yōu)酷的視頻加載速度稍好一些？這要歸功于優(yōu)酷建立的完善的內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）。它保證位于該國不同位置的用戶進行近距離訪問。——用戶點擊視頻請求，優(yōu)酷將根據(jù)用戶的位置。靠近用戶并具有眾所周知的服務(wù)狀態(tài)的視頻服務(wù)器地址被發(fā)送給用戶，從而確保用戶可以獲得快速的視頻體驗。這是CDN帶來的優(yōu)勢，而且它已經(jīng)接近了。