# 擴展 Digg 和其他 Web 應用程序 > 原文： [http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html) Digg 的首席架構師 Joe Stump 在 Web 2.0 Expo 上向[進行了此演示](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)。 我找不到實際的演示文稿，但是[克里斯·喬丹](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)記下了一些很棒的筆記。 這樣一來，歷史上的關鍵時刻便會永遠被意外捕獲。 喬也很友好，可以通過電話回答我的電子郵件問題。 在本篇文章的第一部分中，喬分享了一些您可能沒有讀過的永恒的智慧。 我當然會花些力氣從原始演示文稿中提取所有智慧，而傾向于簡單的規則。 然而，真正令我震驚的是 Joe 認為 MemcacheDB *將成為擴展*領域中最大的新手。 MemcacheDB 已經存在了一段時間，但我從未想到過這種方式。 好吧，在帖子結尾處，為什么喬對 MemcacheDB 感到如此興奮。 ## 令人印象深刻的統計 * 世界第 80 至 100 大網站* 每月 2600 萬唯一* 3000 萬用戶。* 唯一身份流量只有該流量的一半。 流量=唯一的網絡訪問者+ API + Digg 按鈕。* 每月 20 億個請求* 13,000 請求/秒，高峰時為 27,000 請求/秒。* 3 位系統管理員，2 位 DBA，1 位網絡管理員，15 位編碼員，質量檢查小組* Lots of servers. ## 擴展策略 * 縮放是專業化。 當現成的解決方案不再能在一定規模上運行時，您必須創建滿足特定需求的系統。* Web 2.0 的教訓：人們喜歡胡扯并與世界分享。* Web 2.0 具有可伸縮性。 Web 1.0 平坦，包含大量靜態文件。 通過添加更多硬件來處理額外的負載。 Web 2.0 是高度交互的。 內容可以以極低的速率創建。* 語言無法擴展。 100％的時間瓶頸在 IO 中。 當您同時處理大量請求時，瓶頸就不是語言。 使 PHP 速度提高 300％無關緊要。 當 固定數據庫時，不要通過使用單引號而不是雙引號來優化 PHP。* 不分享狀態。 去中心化。 需要分區才能并行處理大量請求。* 向外擴展而不是向上擴展。 期待失敗。 只需添加框即可縮放并避免失敗。* 需要對數據庫驅動的站點進行分區，以在水平和垂直方向上進行擴展。 水平分區意味著將行的子集存儲在不同的機器上。 當一臺機器上無法容納的數據量更多時，將使用此功能。 垂直分區意味著將一些列放在一個表中，而將某些列放在另一個表中。 這使您無需停機即可將數據添加到系統。* 數據分為單獨的群集：用戶操作，用戶，注釋，項目等。* 構建數據訪問層，以便將分區隱藏在 API 的后面。* 帶有分區的 [CAP 定理](http://camelcase.blogspot.com/2007/08/cap-theorem.html)：您只能選擇以下三個中的兩個：強一致性，高可用性，分區容限。* 分區解決方案需要非規范化，這已成為 Digg 的大問題。 非規范化意味著數據被復制到多個對象中，并且必須保持同步。* MySQL 復制用于擴展讀取。* 使用異步排隊體系結構進行近期處理。 -這種方法將處理塊推向另一個服務，讓我們將該服務調度在處理器網格上進行處理。 -與 cron 相比，它更快，響應速度更快，但與實時響應相比，響應速度卻稍慢。 -例如，發出 5 個同步數據庫請求會使您減速。 并行執行。 -Digg 使用 Gearman。 一個示例用法是獲取永久鏈接。 并行完成三個操作：獲取當前記錄，獲取固定鏈接并獲取注釋。 然后將這三個全部合并，以將合并的單個答案返回給客戶端。 它也用于網站爬網和日志記錄。 這是另一種思維方式。 -請參閱 [Flickr-先做必要的工作，然后將其余部分排隊](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest)和 [Canonical Cloud Architecture](http://highscalability.com/canonical-cloud-architecture) 了解更多信息。* 瓶頸在 IO 中，因此您已經調整了數據庫。 當數據庫大于 RAM 時，磁盤會一直處于命中狀態，這會降低性能。 隨著數據庫的變大，無法再掃描該表。 因此，您必須： -反規范化 -避免加入 -避免通過對 進行分區來跨數據庫進行大型掃描-緩存 -添加讀取從屬設備 -不要使用 NFS* 在嘗試解決問題之前，請先編號，以確保事情確實可以進行。* 圖標和照片之類的文件是使用分布式文件系統 [MogileFS](http://www.danga.com/mogilefs/) 處理的。 DFS 支持高請求率，因為文件是在網絡中分布和復制的。* 緩存永久并且明確過期。* 在基于文件的緩存中緩存相當靜態的內容。* 將可變項目緩存在 memcached 中* 在 [APC](http://us2.php.net/apc) 中緩存很少更改的項目。 APC 是本地緩存。 它不是分布式的，因此沒有其他程序可以訪問這些值。* 對于緩存，請使用[責任鏈模式](http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern)。 在 MySQL，memcached APC 和 PHP 全局變量中進行緩存。 首先將 PHP 全局變量檢查為最快的緩存。 如果不存在，請檢查 APC，memcached 并上鏈。* Digg 的推薦引擎是一個最終保持一致的自定義圖形數據庫。 最終一致意味著寫入一個分區最終將寫入所有其他分區。 一次寫讀后，不必再返回相同的值，因為它們可以由不同的分區處理。 這比嚴格的一致性要寬松得多，這意味著更改必須在所有分區上同時可見。 接連進行的讀取將始終返回相同的值。* 假設每天有 100 萬人使用任何新功能，因此從一開始就使其具有可擴展性。 示例：Digg 上的“關于”頁面對主數據庫進行了實時查詢，以顯示所有員工。 只是做了一個快速的黑客出去。 然后，一只蜘蛛發瘋了，并把該地點倒了。 ## 雜種 * Digg 按鈕是產生點擊量的主要關鍵。* 使用 Debian Linux，Apache，PHP，MySQL。* 選擇您喜歡開發的語言，選擇編碼標準，添加可提取的內聯文檔，使用代碼存儲庫和錯誤跟蹤器。 喜歡 PHP，Track 和 SVN。* 你和你的人民一樣好。 必須相信你旁邊的人他在做他的工作。 為了建立信任，人們可以做出 決策。 相信人們會處理它，他們會照顧好它的。 減少會議時間，因為您知道人們會做正確的事。* 完全是 Mac 商店。* 幾乎所有的開發人員都是本地的。 有些人不愿提供 24 小時支持。* 喬的做法務實。 他沒有語言迷戀。 人們從 PHP 到 Python / Ruby，再到 Erlang。 使用 vim。 從命令行開發。 不知道人們如何一直在不斷更改工具集。 這不是很有效。* 服務（SOA）分離是一個巨大的勝利。 Digg 使用 REST。 內部服務返回映射到 JSON，XML 等的原始結構。URL 中的版本是因為它不花錢，例如： /1.0/service/id/xml。 版本內部和外部服務。* 人們不了解網站中有多少活動部件。 某些事情將會發生，并且將會失敗。 ## MemcacheDB：代碼的進化步驟，性能的革命步驟 想象一下 Digg 的創始人 Kevin Rose，他在本次演講時擁有 40,000 個關注者。 如果 Kevin 每天只進行一次挖掘，則可寫 40,000。 由于最活躍的挖掘者是最緊隨其后的，因此它成為巨大的性能瓶頸。 出現兩個問題。 您無法一次更新 40,000 個關注者帳戶。 幸運的是，我們前面討論的排隊系統已解決了這一問題。 第二個問題是發生大量寫入。 Digg 有寫問題。 如果普通用戶有 100 個關注者，則一天的收入為 3 億迪格斯。 那就是每秒 3,000 次寫入，每天 7GB 的存儲以及 5TB 的數據分布在 50 到 60 臺服務器上。 如此繁重的寫入負載使 MySQL 無法用于 Digg。 這就是 MemcacheDB 的用武之地。在筆記本電腦上的初始測試中，MemcacheDB 每秒能夠處理 15,000 次寫入。 MemcacheDB 自己的[基準測試](http://memcachedb.org/benchmark.html)顯示其每秒 23,000 次寫入和 64,000 次讀取/每秒的能力。 以這些寫入速度，不難理解為什么喬對 MemcacheDB 的 digg 泛濫能力感到如此興奮。 什么是 [MemcacheDB](http://memcachedb.org/) ？ 這是專為持久性而設計的*分布式鍵值存儲系統。 它不是緩存解決方案，而是持久存儲引擎，用于基于鍵值的快速，可靠的對象存儲和檢索。 它符合內存緩存協議（未完成，請參見下文），因此任何內存緩存客戶端都可以與其建立連接。 MemcacheDB 使用 Berkeley DB 作為存儲后端，因此支持許多功能，包括事務和復制*。 在您太興奮之前，請記住這是一個鍵值存儲。 您可以通過一個鍵來讀取和寫入記錄。 沒有多個索引，也沒有 SQL。 這就是為什么它可以這么快的原因。 Digg 使用 MemcacheDB 擴展了數據非規格化時發生的大量寫入。 請記住，這是一個鍵值存儲。 該值通常是一個完整的應用程序級對象，該對象可以從大量標準化表合并在一起。 歸一化引入了冗余，因為您將數據副本保留在多個記錄中，而不是在一個很好的標準化表中保留一個副本。 因此，非規范化意味著更多的寫入操作，因為必須將數據復制到包含副本的所有記錄中。 為了跟上他們的發展，他們需要一個能夠處理其寫負載的數據庫。 MemcacheDB 具有這種性能，尤其是當您將 memcached 的常規分區方案放在最頂層時。 我問 Joe 為什么不選擇一種內存數據網格解決方案？ 一些原因是：* 此數據是從許多不同的數據庫生成的，并且需要很長時間才能生成。 因此，他們希望將其存儲在持久性存儲中。* MemcacheDB 使用內存緩存協議。 Digg 已經使用 memcache，因此開始使用 MemcacheDB 無疑是很容易的。 它易于使用且易于設置。* 由于它不是新的設置，因此操作人員很樂意將其部署到數據中心。* 他們已經具有內存緩存的高可用性和故障轉移代碼，因此已經可以使用。* 使用新系統將需要更多的準備時間。* 如果代碼有任何問題，您可以看一下。 全部都是開源的。* 不確定其他產品是否足夠穩定。 因此，這是代碼的進化步驟，也是性能的革命步驟。 Digg 正在考慮全面使用 MemcacheDB。 ## 相關文章 * [擴展 Digg 和其他 Web 應用程序](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)，作者：Kris Jordan。* [MemcacheDB](http://memcachedb.org/)* [Joe Stump 的博客](http://www.joestump.net/)* [具有與 Memcached 有關的高擴展性標簽](http://highscalability.com/tags/memcached)* [高速緩存相關標簽](http://highscalability.com/tags/caching)* [BigTable](http://highscalability.com/tags/bigtable)* [SimpleDB](http://highscalability.com/tags/simpledb)* [Anti-RDBMS：分布式鍵值存儲列表](http://highscalability.com/anti-rdbms-list-distributed-key-value-stores)* [數據庫設計的非傳統方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的來臨* [Flickr 架構](http://highscalability.com/flickr-architecture)* [第 4 集：DIGG 首席架構師 Joe Stump 擴展大型網站](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) 除非他們想在 RAM 上花很多錢，否則他們會感到意外。 當 RAM 與數據庫大小之比降低到 0.8 左右時，Memcachedb / Berkeley 數據庫（或基于 B-Tree 的 MySQL，PostgreSQL 或其他傳統數據庫存儲）的性能將大打折扣。 當前，寫解決方案是 Hypertable，即使 RAM 與 DB 的大小比小于 0.1，它也可以每個客戶端維持 10k 次寫/秒。 “搜索”背后的架構是什么。 我假設正在使用某種全文數據庫。 有人可以指出在 IIS / ASP.Net 環境中擴展全文本搜索的最佳方法。 我知道 SQL Server 2005 不夠好。 我正在尋找使用基于非 SQL 的后端的東西，例如 berkley db。 任何指針將不勝感激？ Web 2.0 Expo 筆記的重新組合。 喬的演講很棒！ 首先請注意，指向我的筆記的鏈接似乎在 href 中包含一個 ，該鏈接中斷了該鏈接。 最好！ 克里斯 哇，對我來說好像他們是在爆發大家伙！ RT www.anon-tools.us.tc 您應該看一下 SOLR（基于 Lucene 的搜索服務器）。 在 Tomcat 和 Jetty 上運行良好...都在 Windows 上運行。 [http://lucene.apache.org/solr/](http://lucene.apache.org/solr/) 搜索/數據的 XML 存儲是 ASP.net 應用程序的最佳選擇，將 LINQ 與.net 3.5 配合使用，XML 比 SQL 快得多。 而且您不必擔心整天都會向 ms-sql-s 端口發送垃圾郵件。 [http://www.keyoti.com/products/search/dotNetWeb/index.html](http://www.keyoti.com/products/search/dotNetWeb/index.html) 這些家伙有一個非常不錯的搜索引擎，但是它只能通過爬網來搜索，但是您始終可以調整其源代碼，對于應該支持的簡單網站，也可以通過 Web 控件運行 喬錄制了一個非常不錯的播客，前段時間他在談論這個話題。 你可以在找到它 [http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/“](<a rel=) > [http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) 涼。 謝謝。 有趣的是，這并沒有出現在我的搜索中。 “ Digg 使用 MemcacheDB 來擴展數據非規范化時發生的大量寫入。” 這是個絕妙的主意：**請勿非正規化！** [http://kottke.org/04/10/normalized-data](http://kottke.org/04/10/normalized-data) 很棒的文章，我非常喜歡 memcache，并已在我的 [http://www.kiran.org.in'](<a rel="nofollow" href="http://www.kiran.org.in) >網站中實現了它 Todd 再次感謝您提供出色的摘要。 在仔細閱讀了所有細節之后，我覺得 Digg 必須在其基礎架構上投入大量資金才能達到這種級別的可伸縮性。 通過查看在 memcacheDB 上*不使用數據網格*的合理性，我得到的印象是，在評估此選項時沒有太多的思想投入，因為有些評論對我來說沒有意義。 例如，更改應用程序以將 mecacheDB 用作 MySQL 的應用程序需要進行重大更改。 使用數據網格，由于數據庫可以保持不變，因此更改可能會更低。 現在，我無法與成功爭論，但是，如果今天我需要擴展我的應用程序，那么在那條路線上走時將非常謹慎，尤其是在當前市場經濟條件下。 今天，有更多現成的解決方案可以完成本研究中提到的大多數事情。 這包括將應用程序分解為分布式服務，擴展數據層，與負載均衡器集成以實現動態擴展的能力（請參閱有關此方面的最新文章 [http://highscalability.com/handle-1-billion [使用記憶網格的事件日數]](<a rel=) >使用內存網格（1009）每天處理 10 億個事件。有趣的是，在過去幾周中，我們參與了幾個項目，這些項目展示了如何 您可以推動超過 10 萬次寫入/秒。我們使用 data-grid 作為前端，并保持對數據庫的異步更新。我們使用 MySQL 作為基礎數據庫，從維護的角度來看，帶來了使用標準 SQL 數據庫的優勢。 云計算還可以提供非常經濟高效的環境來實現這種級別的擴展，而不會帶來太多麻煩。 我不確定在 Digg 構建其解決方案時所有可用的替代方案是否可用，因此 Joe Stump 提出此架構是否合理。 知道喬今天是否會選擇該路線會很有趣。 請參閱 [http://natishalom.typepad.com/nati_shaloms_blog/2008/11/the-impact-of-cloud-computing-on-buy-vs-build-behaviour.html“](<a rel=) >影響 基于 Fred 布魯克斯出色的文章“ No Silver Bullets”撰寫的云計算在構建與購買行為之間的關系正如 Fred 所指出的那樣，在許多情況下，我們傾向于認為我們有專門的要求，并且最終在基礎設施建設和投資方面進行投資 經濟壓力迫使人們重新評估這些假設。 男孩， 對不起，你錯了。 您正在展示您的經驗。 處理大數據時，必須進行規范化以最大程度地減少數據集上的鎖定。 您還可以通過減少聯接來提高性能。 請記住，讀取量遠大于寫入量。 我不確定這是否相關。 假設您是 Digg，并且擁有 1 TB 的數據（可能更多，但是請在此處與我聯系）。 您可以將其分布在 40 個服務器上，每個服務器具有 24 GB 的 RAM 和 24 GB 的存儲。 根據我剛剛檢查的 HP 網站，將 DL 360 從 1GB RAM 升級到 24GB 的費用為 998 美元。 為了簡單起見，我們將其舍入到$ 1,000。 （服務器總成本不到 7,000 美元，包括 120GB RAID 1 SAS 存儲） 您最終得到的是$ 40,000 的 RAM，總計 1 TB，分布在 40 臺服務器上。 對于在服務器上花費 280,000 美元的公司來說，這不是一個壞交易。 這相當于 RAM 的服務器成本的 14％。 因此，敬請注意，低于 1.0 只是由于規劃不當或數據集過大。 （請注意，我足夠聰明地意識到 1TB 可能對于 Facebook 或 Flickr 這樣的公司來說是一個舍入誤差，但是他們的預算也相應地更大。） 我看到去年的播客，一個非常有趣的家伙，知道他的東西。 - [http://www.onlinebingoclub.co.uk/foxy-bingo/“](<a rel=) >狡猾 嗨， 我們正在處理一個項目，該項目實現了 MemcacheDB 作為持久性緩存的解決方案。 不幸的是，該產品似乎并不是所有的東西都那么光明： 1\. Get 時間平均變化為 50ms，標準差為 150ms（鍵和數據的大小小于 100bytes） 2.您 不知道 MemcacheDB 中存儲了多少數據，那里“丟失”了哪些數據，并且如果您沒有密鑰（也不能，不支持枚舉），就無法刪除信息。 3.似乎 前兩個事實是相關的（您不能刪除廢棄的項目，因此性能很差）。 4.根據產品的網站，該產品似乎已被廢棄，并且在目前的狀態下還遠遠不能管理。 最好的問候， Moshe Kaplan。 Performacne 專家。 感謝另一篇出色的文章，從網絡上一些最繁忙的站點中看到真實的示例，這為我們提供了有關準備工作的真正有價值的信息。 我在< http://www.mrkirkland.com/prepare-for-web-application-scalability/ >的最新文章中引用了 highscalability.com。 謝謝！ 柯克蘭先生 首席執行官 artweb.com