Digg 建筑 · HighScalability 中文示例

# Digg 建筑 > 原文： [http://highscalability.com/blog/2009/4/4/digg-architecture.html](http://highscalability.com/blog/2009/4/4/digg-architecture.html) **更新 4：**：[由 Joe Stump 介紹 Digg 的 IDDB 基礎結構](http://blog.digg.com/?p=607)。 *IDDB 是一種在多個存儲服務器之間分區索引（例如整數序列和唯一字符索引）和實際表的方式（目前支持 MySQL 和 MemcacheDB，后面還會有更多內容）。* **更新 3：**：[擴展 Digg 和其他 Web 應用程序](http://highscalability.com/scaling-digg-and-other-web-applications)。 **Update 2：**： [Digg 的工作方式](http://blog.digg.com/?p=168)和 [Digg 的實際工作方式](http://blog.digg.com/?p=177)（佩戴耳塞）。直接從 Digg 的博客帶給您。在跟蹤系統中的請求時，對 Digg 架構的主要元素進行了非常簡潔的解釋。我已經使用新信息更新了此配置文件。 **更新：** [Digg 現在每月獲得 2.3 億以上的頁面瀏覽量和 2600 萬獨立訪問者-流量，這需要進行重大內部升級](http://www.readwriteweb.com/archives/digg_townhall_2_wrapup.php)。 Digg 的超過 2200 萬名著急信息的用戶和 2.3 億頁面訪問量所產生的訪問量，可能會毫無疑問地將網站直接撞入其 CPU，內存和帶寬限制。 Digg 每月如何處理數十億個請求？網站：http：//digg.com ## 信息來源 * [Digg 的工作原理](http://blog.digg.com/?p=168)作者 Digg* [Digg.com 如何使用 LAMP 堆棧向上擴展](http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9017778)* [Digg PHP 的可伸縮性和性能](http://www.oreillynet.com/onlamp/blog/2006/04/digg_phps_scalability_and_perf.html) ## 平臺 * 的 MySQL* 的 Linux* 的 PHP* Lucene* 蟒蛇* [APC PHP 加速器](http://us.php.net/apc)* [MCache](http://www.mohawksoft.org/?q=node/8)* [Gearman](http://www.danga.com/gearman/) -作業調度系統* [MogileFS](http://www.danga.com/mogilefs/) -開源分布式文件系統* 阿帕奇* Memcached ## 統計資料 * 從 2004 年末開始，當時只有一臺運行 Apache 1.3，PHP 4 和 MySQL 的 Linux 服務器。 4.0 使用默認的 MyISAM 存儲引擎* 超過 2200 萬用戶。* 每月超過 2.3 億的頁面瀏覽量* 每月 2600 萬唯一身份訪問者* 每月數十億的頁面瀏覽量* 所面臨的擴展挑戰都與 PHP 沒有任何關系。面臨的最大問題是與數據庫有關的。* 數十個 Web 服務器。* 數十個數據庫服務器。* 六個專門的圖形數據庫服務器運行推薦引擎。* Six to ten machines that serve files from MogileFS. ## 里面有什么 * 專用的負載平衡器設備可監視應用程序服務器，處理故障轉移，根據運行狀況不斷調整群集，平衡傳入請求以及緩存 JavaScript，CSS 和圖像。如果您沒有合適的負載均衡器，請查看 Linux Virtual Server 和 Squid 作為替代產品。* 請求被傳遞到 Application Server 群集。應用程序服務器包括：Apache + PHP，Memcached，Gearman 和其他守護程序。他們負責協調對不同服務（DB，MogileFS 等）的訪問，并創建發送到瀏覽器的響應。* 使用 MySQL 主從設置。 -四個主數據庫按功能劃分：升級，配置文件，注釋，主要。每個主服務器都掛有許多從數據庫。 -寫入主機，讀取發送給從機。 -大量事務的服務器使用 InnoDB 存儲引擎。 -OLAP 繁重的服務器使用 MyISAM 存儲引擎。 -他們沒有注意到從 MySQL 4.1 到版本 5 的性能下降。 -與“您的平均數據庫設計”相比，該架構的規格化程度更高。 -分片用于將數據庫分為幾個較小的數據庫。* Digg 的使用模式使他們更易于擴展。大多數人只是查看首頁而離開。因此，Digg 的數據庫訪問中有 98％是讀取的。憑借這種平衡的操作，他們不必擔心為寫入而設計的復雜工作，這使他們進行擴展變得容易得多。* 他們的存儲系統出現問題，告訴他們寫的確實不在磁盤上。控制器這樣做是為了改善其性能外觀。但是，這樣做的結果是在故障場景中保留了巨大的數據完整性。這確實是一個非常普遍的問題，可能很難解決，具體取決于您的硬件設置。* 為了減輕數據庫負載，他們使用了 APC PHP 加速器 MCache。* Memcached 用于緩存，memcached 服務器似乎分布在其數據庫和應用程序服務器中。專門的守護程序監視連接并終止打開時間過長的連接。* 您可以結合使用 Apache 2 的工作線程，FastCGI 和 PHP 加速器，將 PHP 配置為不在每次加載時進行解析和編譯。在頁面的第一次加載中，將編譯 PHP 代碼，因此任何后續頁面加載都非常快。* MogileFS 是一種分布式文件系統，提供故事圖標，用戶圖標，并存儲每個故事來源的副本。分布式文件系統在許多磁盤上分布和復制文件，從而支持快速和可擴展的文件訪問。* 建立了專門的推薦引擎服務以充當其分布式圖形數據庫。關系數據庫的結構不佳，無法生成建議，因此創建了單獨的服務。 LinkedIn 為他們的圖表做了類似的事情。 ## 得到教訓 * 機器的數量并不重要，它們是什么以及它們如何組裝在一起。* 不要把數據庫當作錘子。建議與關系模型不符，因此他們提供了專門的服務。* 通過選擇數據庫引擎來調整 MySQL。在需要事務時使用 InnoDB，在不需要事務時使用 MyISAM。例如，主服務器上的事務表可以將 MyISAM 用于只讀從服務器。* 在增長曲線的某個時刻，他們無法通過添加 RAM 來增長，因此必須通過架構來增長。* 人們經常抱怨 Digg 很慢。這可能是由于其龐大的 javascript 庫而不是其后端體系結構。* 他們擴展的一種方法是注意在系統上部署的應用程序。他們注意不要釋放使用過多 CPU 的應用程序。顯然，Digg 具有一個相當標準的 LAMP 體系結構，但是我認為這很有趣。工程師通常有很多很酷的功能要發布，但是如果這些功能不能隨功能一起增長，那么這些功能可能會破壞該功能。因此，請向后推，直到系統可以處理新功能為止。這涉及容量規劃，這是 Flickr 在擴展過程中強調的內容。* 您是否想知道，通過限制新功能以匹配其基礎架構，Digg 可能會與其他快速發展的社交書簽服務相比而失去優勢嗎？也許，如果基礎架構更容易擴展，他們可以更快地添加功能以幫助他們更好地競爭嗎？另一方面，僅添加功能是因為您也沒有任何意義。在數據層中，最容易發現擴展性和性能問題，并且這些問題是特定于語言的。您將使用 Java，PHP，Ruby 或它們插入您喜歡的語言。 ## 相關文章 * [LinkedIn 架構](http://highscalability.com/linkedin-architecture-0) * [](http://highscalability.com/linkedin-architecture-0)[實時日志體系結構](http://highscalability.com/livejournal-architecture) * [Flickr 架構](http://highscalability.com/flickr-architecture) * [數據庫設計的非傳統方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的來臨 * [Ebay 架構](http://highscalability.com/ebay-architecture) 是的，為什么 digg 只有 30 GB 的數據？如果這份報告是真實的，我會很高興。 30gb 是數據庫數據，是 HUUUUUGE！我已經寫博客了將近 4 年，而我只使用了大約 15 mb 的數據庫數據。 30 gb 的數據庫數據非常龐大。如果他們僅跟蹤有關其 120 萬用戶的一些歷史數據，則 30 gb 的數據庫并不多。我不相信。 Digg 需要的容量遠遠超過此處顯示的 30GB 數據（無論如何）。您想知道為什么“只有” 30GB 嗎？數據庫是文本。字符是一個字節。算一算。也許我會一個人，但對我來說，沒有什么值得驕傲的。它看起來像是標準的美國公司，那里的箱子比人的便宜，因此，購買 EXPLAIN 命令更容易購買 100 臺服務器，然后只需支付 10 人即可。您可能來自某個時代，當時您確實必須竭盡全力從硬件中獲得所有性能提升。但是，（某種程度上）事實是，成本/收益分析正朝著僅將更多硬件投入問題的方向發展。工程師，特別是優秀的工程師，并不便宜。硬件是。因此，雖然您可能不會留下深刻的印象，但我發現知道何時花更少的錢來完成同一任務“智能”。現在，這并不意味著應該放棄適當的數據庫設計。實際上，在關系，約束，索引等方面，我有點加法。但是有時候，做具有成本效益的事情才有意義，我希望這就是 digg 所做的。哇，直到現在我才意識到我的最后一個問題有多糟。最后一件事，要水平縮放實際上需要花費很多精力。僅僅因為他們使用了很多盒子，并不意味著他們沒有在整個系統架構和數據庫設計上花費很多時間和精力。這是我目前正在設計的系統可以做到的事情，并不是這樣，所以我不必擔心優化代碼，這樣我就可以進行容量規劃和購買資源，以逐步處理增加的負載并節省成本。我發現能夠做到這一點令人印象深刻。他指的 30 GB 可能是每個群集節點上所需的空間。 OS +應用程序等我將是第一個不同意的人。首先，如果沒有合適的人設計整個體系結構，那么在一個問題上丟箱子只會增加您的電費。我已經看到了與客戶的第一手資料。實際上，我已經看到使用集群的“解決方案”實際上降低了性能，因為設計反表明集群的使用（換句話說，它不是可擴展的設計）。就個人而言，我寧愿選擇一些架構師和管理員以及許多功能強大的機器，而不是忙于工作人員并且沒有足夠的服務器資源。 :) - Dustin Puryear 作者， [http://www.puryear-it.com/pubs/linux-unix-best-practices“](<a rel=) >管理 Linux 和 UNIX 的最佳做法服務器 [http://www.puryear-it.com“](<a rel=) > [http://www.puryear-it.com](http://www.puryear-it.com) Digg 使用哪種負載均衡解決方案/產品？確定他們可以廉價地添加服務器，但是每月要有 100 臺服務器才能獲得 2 億次觀看？相比之下，每月有 2 箱裝滿大量魚的魚有 1.1B 次瀏覽，digg sux？知道 Digg 使用哪種形式的 FastCGI？或者其他人用于 PHP / Apache 配置？為了清理。 30GB 的數據庫*為 closal* 。在 DIGG 上，您只需要在數據庫中存儲一個簡短的標題，簡短的上下文，鏈接 URL，日期，作者以及 Diggs 的數目，也就是這樣。然后再添加一些用戶帳戶數據...沒什么。 30 GB 為 30,000,000,000 字節（大約），每個字符為一個字節（UTF8）我的意思是，對于**來說，對于**，30GB 聽起來可能很小，因為您存儲視頻/音樂/游戲，但是我們在這里談論的是純文本。克服它。一個 30GB 的數據庫確實不是那么大。您忘記了該網站不僅存儲了數字，還存儲了誰，誰評論了哪些評論，最有可能存儲點擊（我懷疑他們用來檢測欺詐）。一個受歡迎的故事可能包含數千個挖掘，然后評論中包含數千個挖掘。此數據已全部存儲。我們還知道 digg 正在分片，因此我懷疑數據庫的大小遠大于此大小。我相信 BIG-IP :) 我非常懷疑這是真的，他們使用兩個框進行的瀏覽量可能不足 2000 萬。我曾與銀行的 MS SQL Server 合作，主要開發了業務核心和 BI 應用程序，其中 SQL Server MDF 已達到 100GB 以上。該數據庫在 5 個奇數年的時間內跟蹤了每個客戶針對每個帳戶進行的每筆交易。那就好那就是 SQL2000。它的速度非常快。 SQL Server 和可靠，可靠的企業體系結構是在.NET 框架>上開發的。認為他可以使用其他（劣等）工具集可以做得更好的任何反 MS 專家，只是在做夢。如前所述-30GB 是一個很大的數據庫。我不會說巨大，因為（對我而言）意味著在其界限的邊緣沒有任何增長空間的東西。但是，數據庫很大。在 www.freecrm.com 上，我們在 1 臺快速服務器上的 mySql 5 設置上達到了 30GB 的數據庫大小，但是在修剪了舊的電子郵件日志后，我們將其減少到 18GB 左右。在超過 60,000 個用戶的 CRM 應用程序中，這已超過 4 年的大量使用。到目前為止，mySql 可以順利進行，并且到目前為止，任何慢速查詢都是由于索引不足。 -Harel Malka ------------------------ [http://www.harelmalka.com](http://www.harelmalka.com) [http://www.freecrm.com](http://www.freecrm.com) [http://www.kadoink.com](http://www.kadoink.com) 與我管理的數據庫相比，30gb 很小。我管理的大多數生產數據庫的范圍從 600gb 到 2tb 不等，所有數據庫都運行 Oracle 10g。這些網站大多數都有麻煩，因為他們選擇 mysql 而不是真實的數據庫。像 Bebo 這樣的使用 Oracle 的網站都可以很好地擴展。 Bebo.com 的基礎架構每天僅使用 6 cpus 即可支持超過 1 億個網站頁面瀏覽量和每天約 120 萬張圖片上傳。鏈接在這里： [http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html](http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html) Lucene 數據的大小是多少？每個人都可能想注意到任何人說 30gb 是大型甚至中型的。當涉及到與高可伸縮性相關的任何事情時，您可能不希望聽取他們的意見。對于他們來說，顯然并不需要擴展。我想進一步了解他們如何/為什么使用 MCache。 APC 應該適合本地服務器緩存，memcached 適合分布式緩存。 MCache 有什么幫助？我曾經使用過 msession，在每個頁面上都有一些奇怪的啟動開銷。我改用 MySQL 進行會話，而不是使用 msession，這很棒。我不確定為什么他們將 MCache 添加到組合中，并且想知道如何以及為什么... 我猜每個服務器都有 30G 我認為將 30GB 的內存稱為小型磁盤的意義在于，您可以購買具有 128GB 以上的 RAM 的計算機，并將整個數據庫放入緩存中。考慮到戴爾提供的具有 32GB RAM 的四核 opteron 的價格為 6600 美元，看來浪費在 memcached 以及所有這些 Web 服務器上的資源，據我的數學計算，每秒 77 個請求有點過分。