# 為什么 Facebook，Digg 和 Twitter 很難擴展？ > 原文： [http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) 實時社交圖（人，地方和事物之間的連通性）。 這就是為什么要擴展 Facebook 很難[的原因，Facebook 技術副總裁 Jeff Rothschild](/blog/2009/10/12/high-performance-at-massive-scale-lessons-learned-at-faceboo-1.html) 說。 像 Facebook，Digg 和 Twitter 這樣的社交網站要比傳統網站難于擴展。 這是為什么？ 為什么社交網站比傳統網站更難擴展？ 讓我們找出答案。 傳統網站比社交網站更易于擴展，原因有兩個： * 他們通常僅訪問自己的數據和公共緩存的數據。 * 一次只有 1-2％的用戶在該站點上處于活動狀態。 想象一下像 Yahoo 這樣的大型網站。 當您來到 Yahoo 時，他們可以一鍵獲取您的個人資料記錄，足以為您建立網站視圖。 使用[分布式哈希方案](http://highscalability.com/blog/2009/8/5/anti-rdbms-a-list-of-distributed-key-value-stores.html)基于單個記錄擴展系統相對簡單。 而且由于一次只有很少一部分人同時訪問該站點，因此只需較少的 RAM 緩存即可處理所有活動用戶。 現在想想在 Facebook 上發生了什么。 假設您有 200 個朋友。 當您打您的 Facebook 帳戶時，必須同時**收集所有 200 個朋友的狀態**，以便您可以查看對他們有什么新變化。 這意味著需要同時發出 200 個請求，需要將答復合并在一起，需要聯系其他服務以獲取更多詳細信息，所有這些都需要合并在一起并通過 PHP 和 Web 服務器發送，因此您可以看到 Facebook 頁面在合理的時間內。 天啊。 這里有幾個含義，特別是考慮到在社交網站上一次有大量用戶同時在系統上（這是社交部分，人們閑逛）： * 所有數據始終處于活動狀態。 * 由于每個人都已連接，因此很難對這種系統進行分區。 * 所有內容都必須保存在 RAM 緩存中，以便可以盡快訪問數據。 分區意味著您希望找到某種方法將常用數據聚類在一起，以便可以更有效地對其進行訪問。 由于數據的互連性，Facebook 沒有找到任何可行的集群方案。 因此，Facebook **不會對數據進行分區和非規范化，而是保持數據規范化，并在數以千計的數據庫中隨機分配**數據。 這種方法需要非常快的緩存。 Facebook 使用 [memcached](http://highscalability.com/blog/category/memcached) 作為其緩存層。 所有數據都保存在緩存中，并且他們對 memcached 進行了大量修改，以加快數據傳輸速度并幫助其處理更多請求（所有信息都回饋社區）。 他們的**緩存層服務每秒提供 1.2 億個查詢**，這是站點的核心。 問題是 memcached 難以使用，因為它需要程序員的配合。 腐敗也很容易。 他們開發了一個復雜的系統，以使緩存層中的數據與數據庫保持一致，即使跨多個分布式數據中心也是如此。 請記住，它們是在此處緩存用戶數據，而不是 HTML 頁面或頁面片段。 考慮到他們的數據更改量，將很難使頁面緩存起作用。 我們在 Digg 看到了類似的問題。 例如，每當凱文·羅斯（Kevin Rose）挖掘鏈接時，Digg 就必須處理將更新發送給 [40,000 個關注者](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html)的問題。 Digg 和我認為 Twitter 也采取了與 Facebook 不同的方法。 Facebook 采用**按需拉動**方法。 要重新創建頁面或顯示片段，他們需要運行完整的查詢。 為了確定您的朋友中是否添加了一個新的喜愛的樂隊，Facebook 實際查詢了所有朋友，以查找最新消息。 他們可以擺脫這種情況，但是由于其強大的基礎架構。 但是，如果您曾經想過**，為什么 Facebook 的朋友數限制為 5,000 個用戶**，這就是為什么。 在某一點上很難實現“按需”規模。 找出新功能的另一種方法是**隨推即用**模型。 在此模型中，當用戶進行更改時，會將其推送到所有相關用戶，并且更改（以某種形式）與每個用戶一起存儲。 因此，當用戶要查看其更新時，他們需要訪問的就是他們自己的帳戶數據。 無需輪詢所有朋友的更改。 有了安全性和權限，要確定誰應該看到更新，可能會非常復雜。 如果用戶擁有 200 萬關注者，那么它的速度也可能令人驚訝地慢。 還有一個重復的問題。 存儲了大量重復數據（或引用），因此這是一種非規范化方法，可能會導致一些一致性問題。 例如，在生產或使用數據時是否應征得許可？ 或者，如果數據已經被復制后又被刪除了怎么辦？ 盡管所有這些一致性和重復性問題都很有趣，但``推動變革''似乎為真正的追隨者提供了更具可擴展性的方法。 推動所有更改確實需要很多工作，但是可以由作業排隊系統處理，因此工作可以分布在整個集群中。 隨著我們擁有越來越多的人，越來越多的相互聯系，越來越快的變革以及對實時消耗所有這些的渴望，挑戰將越來越大。 我們距離能夠應對這個勇敢的新世界還有很長的路要走。 關于社交網站的整個可伸縮性問題的非常不錯的概述。 但是，我確定下一個要緊推模型，特別是在經典聊天應用程序之外使用 XMPP 之類的協議。 感謝您的精彩文章。 我一直想知道 Facebook 如何擺脫龐大的互連數據庫。 “他們的緩存層服務每秒提供 1.2 億個查詢，這是站點的核心。” 您可以為此找到參考嗎？ 在他的演講中嗎？ 如果是這樣，我會去看的。 網絡行業可以向金融行業學習。 多年來，股票市場一直在以非常低的延遲向大量節點傳遞消息的股價信息。 有多種商業產品，例如 Tibco Rendezvous，都提供了這樣的消息總線。 那時，向 40,000 個關注者（可能駐留在更少的分區上）發布更新不是一個真正的挑戰。 Facebook 的限制也反映出我們注意力經濟的自然限制：沒有人可能知道（或保留）約 5000 名其他人的一切。 只要 Web 體系結構只需要圍繞我們弱小的人腦擴展，我們就處于相當安全的領域。 我喜歡這篇文章，非常有幫助。 分布式系統和緩存始終是我感興趣的主題：） 好帖子。 嗯..有趣的點。 涉及到影響可訪問量如此大的站點的可伸縮性的一些重要點。 你好 我們最近有一篇文章涉及 OSN 的擴展，并且我們處理了 您提到的一些問題-包括分區問題。 可以在以下網站找到該論文：http://bit.ly/18Gqmx 請隨時與作者聯系以獲取更多信息。 干杯， 歡呼 偉大的話題和問題的解釋。 如果您對解決此問題的絕佳方法感興趣，請查看附件鏈接和網絡研討會。 http://budurl.com/oct15wbnr 不錯的發人深省的文章。 我想我有一個想法如何處理“同時收集所有 200 個朋友的狀態”。 根本不要。 人們不太可能希望甚至無法一次查看全部大小的數據，因此請以不占優勢的塊形式提供數據。 不錯的文章，但您錯失了 5,000 個用戶限制。 我記得前一段時間看過一位 Facebook 工程師的演講（我認為那是 Yahoo Brickhouse 的 Jeff Hammerbacher 的演講），他說限制是“產品決定”，而不是工程決定。 他還說，粉絲專頁使用的樣式與普通人完全一樣，那里沒有限制。 因此，基本上，5,000 個朋友的限制是完全任意的，明天他們可以毫無問題地將其刪除。 有趣且很有見地。 從很長時間以來，我一直在尋找可擴展性問題的答案，甚至在博客上都對此發表了看法，但這是我遇到的最好的解釋。 很棒的帖子。 當我們處理擴展這些大型站點的軟件架構時，這真的變得很有趣：) 首先，facebook 和 dig 使用的方法是最好的方法。 然而，他們尋找更優化的解決方案的努力可能會觸發數據管理的新發明。 如您所知，技術是在戰爭中最發達的，這就是在競爭激烈的市場中為金錢而戰：) 是的，我為 Facebook，Flickr，Digg 等購買此產品。 它們具有相對簡單的數據結構和非常小的數據庫。 他們最近聲稱，在邁克爾·杰克遜（Michael Jackson）事件期間，他們每秒最多有 5,000 條消息。 即使我很慷慨地說，他們平均每秒平均連續發送 5,000 條消息，但一年仍然只能收到 20Tb 的消息。 當然他們有很多要求，但是要提取的數據并不多。 如果他們只愿意執行某種形式的實時推送而不是讓人們投票，那么他們發現的 api 調用也可能會大大減少。 與 Facebook 相比，Twitter 并沒有太多的借口來應對近期的所有故障。 帕特里克 聽起來是時候將某個人的社交網絡直接構建到硬件中了。 也許是社交網絡 ASIC？ 極端情況下的社交網絡問題最終與神經網絡面臨的經典問題以及其他大規模并行計算問題（互連的階乘擴展）密切相關。 每個附加節點 N 將潛在連接數增加 N-1 倍。 在大腦中，典型的神經元與大約 10,000 個接收器和 10,000 個發送器連接，因此乘數僅約為 10,000，而不是數十億。 因此，Facebook 限制的數量級相似。 有趣的是，分組交換網絡比硬交換具有更好的可伸縮性，因此，除非實現了類似于網絡的總線層，否則 ASIC 可能不是走的路。 那是我一直在研究的設計。 生物神經網絡還通過不修剪不帶明顯信號的互連部分解決了這一問題，而“表決權”得不到定期使用的神經元（它們的輸出并未受到任何接收神經元的高度加權）實際上會死亡。 可悲的是，用戶不在乎并且不容忍由可伸縮性問題（或缺乏可伸縮性問題）引起的可見錯誤。 非常有趣的文章。 謝謝！