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