# Tumblr Architecture-150 億頁面瀏覽量一個月，比 Twitter 更難擴展 > 原文： [http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html)  Tumblr 每月擁有超過 150 億的頁面瀏覽量，已成為一個非常流行的博客平臺。 用戶可能會喜歡 Tumblr 的簡單性，美觀性，對用戶體驗的高度關注或友好而參與的社區，但他們喜歡。 每月以 30％以上的速度增長并非沒有挑戰。 其中一些可靠性問題。 它有助于認識到 Tumblr 的運行規模驚人地驚人：每天有 5 億次頁面瀏覽，每秒約有 4 萬個請求的峰值速率，每天約有 3TB 的新數據存儲，所有這些都在 1000 多個服務器上運行。 成功創業公司的常見模式之一是從創業公司到瘋狂成功創業的危險鴻溝。 尋找人員，不斷發展的基礎架構，為舊的基礎架構提供服務，同時處理每月逐月的巨大流量增長（全都只有四名工程師），這意味著您必須對工作內容做出艱難的選擇。 這就是 Tumblr 的情況。 現在，擁有 20 名工程師，他們有足夠的精力來解決問題并開發一些非常有趣的解決方案。 Tumblr 開始時是一種非常典型的大型 LAMP 應用程序。 他們現在的發展方向是朝著圍繞 Scala，HBase，Redis，Kafka，Finagle 構建的分布式服務模型以及為儀表板提供動力的有趣的基于單元的體系結構。 現在，我們正在努力解決其 PHP 應用程序中的短期問題，將其撤出并使用服務來正確完成。 Tumblr 的主題是大規模過渡。 從 LAMP 堆棧過渡到有點出血的邊緣堆棧。 從小型啟動團隊過渡到配備齊全的現成開發團隊，以開發新功能和基礎架構。 為了幫助我們理解 Tumblr 的生活方式，Tumblr 的分布式系統工程師，資深的初學者 [Blake Matheny](http://www.linkedin.com/in/bmatheny) 。 布雷克（Blake）對 Tumblr 之家的評價如下： 網站： [http://www.tumblr.com/](http://www.tumblr.com/) ## 統計信息 * 每天有 5 億頁面瀏覽量 * 每月瀏覽量超過 15B * ?20 名工程師 * 每秒約 40k 請求的峰值速率 * 每天有 1 TB 以上的數據進入 Hadoop 集群 * 每天有許多 TB 進入 MySQL / HBase / Redis / Memcache * 以每月 30％的速度增長 * 正在生產的?1000 個硬件節點 * 每個工程師每月有數十億的頁面訪問 * 帖子每天大約 50GB。 關注者列表每天更新約 2.7TB。 * 儀表板每秒運行一百萬次寫入，每秒 50K 讀取，并且還在不斷增長。 ## 軟件 * OS X 用于開發，Linux（CentOS，科學版）投入生產 * Apache * PHP，Scala，Ruby * Redis，HBase，MySQL * Varnish，HA 代理，nginx， * Memcache，Gearman，Kafka， Kestrel，Finagle * 節儉，HTTP * [Func](http://func.et.redhat.com/) -安全，可編寫腳本的遠程控制框架和 API * Git，Capistrano，木偶，詹金斯 ## 硬件 * 500 臺 Web 服務器 * 200 個數據庫服務器（其中許多是我們因故障而從備用池中抽出的一部分） * 47 個池 * 30 個碎片 * 30 個內存緩存服務器 * 22 個 Redis 服務器 * 15 個清漆服務器 * 25 個代理節點 * 8 nginx * 14 個作業隊列服務器（紅 est + Gearman） ## 架構 * Tumblr 具有與其他社交網絡不同的使用模式。 * 每天有 50+百萬個帖子，平均帖子數達數百人。 擁有數百萬關注者的不僅僅是一兩個用戶。 Tumblr 用戶的圖表有數百個關注者。 這與任何其他社交網絡都不同，這就是使 Tumblr 如此難以擴展的原因。 * 在用戶花費的時間方面排名第二。 內容很吸引人。 它是圖片和視頻。 帖子沒有字節大小。 它們并不都是長格式，但是它們有能力。 人們會寫一些值得一讀的深入內容，因此人們會呆上幾個小時。 * 用戶與其他用戶建立連接，因此他們將數百頁返回到儀表板以讀取內容。 其他社交網絡只是您采樣的流。 * 的含義是，鑒于用戶數量，用戶的平均覆蓋范圍以及用戶的高發布活動，需要處理大量更新。 * Tumblr 在一個托管站點中運行。 設計在將來會考慮地理分布。 * 以 Tumblr 為平臺的兩個組件：公共 [Tumblelogs](http://www.tumblr.com/tagged/tumblelogs) 和 [信息顯示板](http://www.tumblr.com/tagged/tumblr+dashboard) * 公眾 Tumblelog 是公眾根據博客處理的內容。 易于緩存，因為它不是那么動態。 * 儀表板類似于 Twitter 時間線。 用戶從他們關注的所有用戶那里獲取實時更新。 * 與博客的縮放特性非常不同。 緩存并不是那么有用，因為每個請求都是不同的，尤其是對于活躍的關注者而言。 * 需要實時且一致。 不應顯示過時的數據。 而且有很多數據要處理。 帖子每天只有大約 50GB。 關注者列表每天更新 2.7TB。 媒體全部存儲在 S3 中。 * 大多數用戶都將 Tumblr 用作消費內容的工具。 每天的 500+百萬頁面瀏覽量中，有 70％用于儀表板。 * 儀表板的可用性非常好。 Tumblelog 表現不佳，因為它們具有難以遷移的舊式基礎架構。 與一個小團隊一起，他們必須選擇并解決擴展問題。 ### 舊 Tumblr * 當公司開始使用 Rackspace 時，它給每個自定義域博客一個 A 記錄。 當他們超過 Rackspace 時，太多的用戶無法遷移。 這是 2007 年。他們在 Rackspace 上仍具有自定義域。 他們使用 HAProxy 和 Varnish 將 Rackspace 路由回到其 colo 空間。 這樣的遺留問題很多。 * 傳統的 LAMP 進展。 * 歷史上是用 PHP 開發的。 幾乎每個工程師都使用 PHP 進行編程。 * 從 Web 服務器，數據庫服務器和 PHP 應用程序開始，然后開始發展。 * 要擴展規模，他們開始使用內存緩存，然后放入前端緩存，然后在緩存之前放入 HAProxy，然后使用 MySQL 分片。 MySQL 分片非常有用。 * 充分利用單個服務器的方法。 在過去的一年中，他們在 C 語言中開發了一些后端服務： [ID 生成器](http://engineering.tumblr.com/post/10996371189/blake-matheny-id-generation-at-scale) 和 [樓梯](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，使用 Redis 為儀表板通知供電 * 儀表板使用分散收集方法。 當用戶訪問其儀表板時，將顯示事件。 將拉出并顯示您關注的用戶的事件。 這將再擴展 6 個月。 由于數據是按時間排序的分片方案，因此效果不佳。 ### 新 Tumblr * 由于招聘和開發速度原因，已更改為以 JVM 為中心的方法。 * 目標是將所有內容從 PHP 應用程序移到服務中，并使該應用程序成為確實需要身份驗證，表示等的服務的薄層。 * Scala 和 Finagle 選擇 * 內部，他們有很多具有 Ruby 和 PHP 經驗的人，因此 Scala 頗具吸引力。 * Finagle 是選擇 Scala 的重要因素。 它是 Twitter 的圖書館。 它處理大多數分布式問題，例如分布式跟蹤，服務發現和服務注冊。 您不必實現所有這些東西。 它只是免費提供的。 * 在 JVM 上，Finagle 提供了所需的所有原語（Thrift，ZooKeeper 等）。 * Foursquare 和 Twitter 正在使用 Finagle。 Meetup 也正在使用 Scala。 * 類似于 Thrift 應用程序界面。 它具有非常好的性能。 * 喜歡 Netty，但是想要退出 Java，因此 Scala 是一個不錯的選擇。 * 之所以選擇 Finagle，是因為它很酷，并且認識一些人，它不需要很多網絡代碼就可以工作，并且可以完成分布式系統中所需的所有工作。 * 未選擇 Node.js，因為使用 JVM 基礎更容易擴展團隊。 Node.js 開發不夠完善，無法提供標準和最佳實踐以及大量經過測試的代碼。 使用 Scala，您可以使用所有 Java 代碼。 關于如何以可擴展的方式使用它的知識并不多，它們的目標是 5 毫秒的響應時間，4 個 9s HA，每秒 40K 個請求，還有一些每秒 40 萬個請求。 他們可以利用 Java 生態系統中的很多功能。 * 內部服務正在從基于 C / libevent 的狀態轉變為基于 Scala / Finagle 的狀態。 * 正在使用更新的非關系數據存儲，例如 HBase 和 Redis，但它們的大部分數據當前存儲在高度分區的 MySQL 體系結構中。 不使用 HBase 替換 MySQL。 * HBase 支持數十億個 URL 以及所有歷史數據和分析的 URL 縮寫。 一直堅如磐石。 HBase 用于具有較高寫入要求的情況，例如替換儀表板每秒寫入一百萬次。 未部署 HBase 而不是部署 MySQL，因為他們無法與他們所擁有的人押寶 HBase 上的業務，因此他們開始將其用于規模較小，不太關鍵的項目中以獲取經驗。 * MySQL 和時間序列數據分片的問題一直是一個熱點。 由于從屬服務器上的插入并發性，還遇到了讀取復制滯后的問題。 * 創建了一個公共服務框架。 * 花了很多時間來預先解決如何管理分布式系統的操作問題。 * 建造了一種 Rails 腳手架，但用于服務。 模板用于在內部引導服務。 * 從操作角度來看，所有服務看起來都是相同的。 檢查統計信息，監視，啟動和停止所有服務的工作方式相同。 * 工具是圍繞 [SBT](https://github.com/harrah/xsbt/wiki) （一種 Scala 生成工具）的構建過程使用的，它使用插件和幫助程序來處理一些常見的活動，例如在其中標記內容 git，發布到存儲庫等。大多數開發人員不必進入構建系統的膽量。 * 前端層使用 HAProxy。 Varnish 可能會受到公共博客的歡迎。 40 臺機器。 * 500 個運行 Apache 的 Web 服務器及其 PHP 應用程序。 * 200 個數據庫服務器。 使用許多數據庫服務器是出于高可用性的原因。 使用了商品硬件，MTBF 令人驚訝地低。 丟失的硬件比預期的要多得多，因此在發生故障的情況下有許多備用件。 * 6 個支持 PHP 應用程序的后端服務。 一個團隊致力于開發后端服務。 每 2-3 周推出一項新服務。 包括儀表板通知，儀表板二級索引，URL 縮短器和用于處理透明分片的內存緩存代理。 * 在 [MySQL 分片](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) 中投入了大量時間和精力。 盡管 MongoDB 在紐約（其所在地）很受歡迎，但并未使用。 MySQL 可以很好地擴展。. * Gearman 是一種工作隊列系統，用于長時間的開火和忘卻式工作。 * 可用性是根據覆蓋范圍衡量的。 用戶可以訪問自定義域或儀表板嗎？ 同樣在錯誤率方面。 * 歷史上最高優先項是固定的。 現在，對故障模式進行了系統地分析和處理。 目的是從用戶角度和應用程序角度衡量成功。 如果無法滿足要求的一部分，則為 * 最初，Actor 模型與 Finagle 一起使用，但已被刪除。 為了免于失火，使用作業隊列。 此外，Twitter 的 [實用程序庫](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 包含 [期貨](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 實現和服務 就期貨而言。 在需要線程池的情況下，將期貨傳遞到期貨池中。 一切都提交給將來的池以異步執行。 * Scala 鼓勵沒有共享狀態。 Finagle 被認為是正確的，因為它已經在 Twitter 上進行了生產測試。 使用 Scala 或 Finagle 中的構造避免了可變狀態。 不再使用長時間運行的狀態機。 狀態從數據庫中拉出，使用，然后寫回數據庫。 優勢在于，開發人員無需擔心線程或鎖。 * 22 個 Redis 服務器。 每個服務器有 8-32 個實例，因此生產中使用了 100 個 Redis 實例。 * 用于儀表板通知的后端存儲。 * 通知就像用戶喜歡您的信息一樣。 通知會顯示在用戶的儀表板上，以指示其他用戶對其內容執行的操作。 * 高寫入率使 MySQL 不適合使用。 * 通知是短暫的，因此刪除通知不會太可怕，因此 Redis 是此功能的可接受選擇。 * 讓他們有機會了解 Redis 并熟悉它的工作原理。 * Redis 完全沒有問題，社區很棒。 * 為 Redis 創建了一個基于 Scala 期貨的界面。 現在，此功能正在遷移到其單元架構中。 * URL 縮短器使用 Redis 作為第一級緩存，使用 HBase 作為永久存儲。 * 信息中心的二級索引圍繞 Redis 構建。 * 使用由 Finagle 構建的內存緩存代理，Redis 用作 Gearman 的持久層。 * 從 Memcache 緩慢移至 Redis。 最終希望僅依靠一種緩存服務。 性能與 Memcache 相當。 ### 內部消防水帶 * 內部應用程序需要訪問活動流。 活動流是有關用戶創建/刪除帖子，喜歡/取消喜歡帖子等的信息。一個挑戰是實時分發如此多的數據。 希望能夠在內部進行擴展并且可以可靠地擴展應用程序生態系統。 需要一個中心分發點。 * 以前，此信息是使用 Scribe / Hadoop 分發的。 服務將登錄到 Scribe 中并開始拖尾，然后將該數據通過管道傳輸到應用程序中。 此模型幾乎立即停止了擴展，特別是在人們每秒創建數千個帖子的高峰期。 不想讓人們將文件和管道拖到 grep。 * 創建了一個內部 firehose 作為消息總線。 服務和應用程序通過 Thrift 與 Firehose 對話。 * LinkedIn 的 Kafka 用于存儲郵件。 在內部，消費者使用 HTTP 流從 Firehose 讀取數據。 未使用 MySQL 是因為分片實現經常更改，因此使用巨大的數據流來實現它不是一個好主意。 * firehose 模型非常靈活，與假定數據丟失的 Twitter firehose 不同。 * 消防水帶可以及時退繞。 它保留一周的數據。 在連接時，可以指定開始閱讀的時間點。 * 多個客戶端可以連接，并且每個客戶端都不會看到重復的數據。 每個客戶端都有一個客戶端 ID。 卡夫卡支持一個消費者群體的想法。 消費者組中的每個消費者都有自己的消息，不會看到重復的消息。 可以使用相同的使用者 ID 創建多個客戶，并且客戶不會看到重復的數據。 這樣就可以獨立并并行地處理數據。 Kafka 使用 ZooKeeper 定期檢查消費者閱讀的距離。 ### 儀表板收件箱的單元格設計 * 當前用于提供儀表板功能的分散收集模型的跑道非常有限。 它不會持續更長的時間。 * 解決方案是移至使用類似于 [Facebook 消息](http://www.facebook.com/note.php?note_id=454991608919) 的基于單元的架構實現的收件箱模型。 * 收件箱與分散收集相反。 用戶的儀表板由跟隨的用戶的帖子和其他用戶采取的操作組成，按時間順序邏輯存儲在一起。 * 解決了分散收集問題，因為它是一個收件箱。 您只需要問收件箱中的內容，就可以節省費用，然后便宜得多。 這將擴展很長時間。 * 很難重寫儀表板。 數據具有分布式性質，但具有交易質量，用戶無法部分獲得更新。 * 數據量令人難以置信。 消息必須平均發送給數百個不同的用戶，這與 Facebook 面臨的問題截然不同。 大日期+高分發率+多個數據中心。 * 規格為每秒寫一百萬，每秒讀 50K。 數據集大小為 2.7TB 的數據增長，未啟用任何復制或壓縮。 百萬寫秒是從 24 字節行鍵寫入的，它指示收件箱中的內容。 * 在已經流行的必須保持運行的應用程序上執行此操作。 * 細胞 * 單元是一個獨立的安裝，其中包含適用于一系列用戶的所有數據。 呈現用戶儀表板所需的所有數據都在單元格中。 * 用戶被映射到單元格中。 每個數據中心存在許多單元。 * 每個單元都有一個 HBase 群集，服務群集和 Redis 緩存群集。 * 用戶被安置在一個單元中，并且所有單元都通過 firehose 更新消耗所有帖子。 * 每個單元都基于 Finagle，并通過 Thrift 上的 firehose 和服務請求填充 HBase。 * 用戶進入儀表板，用戶位于某個特定的單元格內，服務節點通過 HBase 讀取其儀表板，并將數據傳回。 * 后臺任務從防火墻中消耗掉，以填充表和處理請求。 * Redis 緩存層用于單元內的帖子。 * 請求流：用戶發布帖子，該帖子被寫入 firehose，所有單元格消耗該帖子并將該帖子內容寫到帖子數據庫中，單元格查找以查看帖子創建者是否有任何關注者 在單元格中，如果是的話，則跟隨者收件箱將更新為帖子 ID。 * 電池設計的優勢： * 大規模規模需要并行化，而并行化要求組件彼此隔離，因此沒有相互作用。 單元提供一個并行化單元，可以隨著用戶群的增長而調整為任意大小。 * 細胞隔離故障。 一個單元故障不會影響其他單元。 * 單元可以實現一些不錯的功能，例如測試升級，實施滾動升級以及測試軟件的不同版本的能力。 * 容易遺漏的關鍵思想是： 所有帖子都復制到所有單元格 。 * 每個單元格都存儲所有帖子的單個副本。 每個單元格可以完全滿足儀表板渲染請求。 應用程序不要求提供所有帖子 ID，然后要求提供這些 ID 的帖子。 它可以為用戶返回儀表板內容。 每個單元都具有完成儀表板請求所需的所有數據，而無需進行任何跨單元通信。 * 使用了兩個 HBase 表：一個存儲每個帖子的副本。 與存儲該單元內每個用戶的每個帖子 ID 的另一個表相比，該數據很小。 第二張表告訴用戶儀表板的外觀，這意味著他們不必獲取用戶關注的所有用戶。 這也意味著跨客戶，他們將知道您是否閱讀了帖子，并且在其他設備上查看帖子并不意味著您閱讀了相同的內容兩次。 使用收件箱模型，狀態可以保持在您已閱讀的內容上。 * 帖子太大，因此無法直接放入收件箱。 因此，將 ID 放入收件箱，并將帖子內容僅放入單元格一次。 該模型大大減少了所需的存儲空間，同時使返回用戶收件箱的按時間順序的視圖變得簡單。 缺點是每個單元格包含完整的呼叫記錄副本。 令人驚訝的是，帖子比收件箱映射要小。 每天的后期增長是每個單元 50GB，收件箱每天增長 2.7TB。 用戶消費超過他們生產的東西。 * 用戶的信息中心不包含帖子的文本，僅包含帖子的 ID，而大部分增長都來自 ID。 * 隨著關注者的更改，設計是安全的，因為所有帖子均已在單元格中。 如果只有關注者帖子存儲在一個單元格中，那么隨著關注者的更改，該單元格將過時，并且需要某種回填過程。 * 替代設計是使用單獨的帖子群集來存儲帖子文本。 這種設計的缺點是，如果群集出現故障，則會影響整個站點。 使用單元設計并向所有單元復制后，將創建一個非常強大的體系結構。 * 擁有數百萬個真正活躍的關注者的用戶可以通過根據其訪問模型選擇性地實現用戶供稿來處理（請參見 [Feeding Frenzy](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) ）。 * 不同的用戶具有適當的不同訪問模型和分發模型。 兩種不同的分發模式：一種用于流行用戶，另一種用于其他人。 * 數據的處理方式取決于用戶類型。 來自活躍用戶的帖子實際上不會發布，而帖子將有選擇地實現。 * 關注數百萬用戶的用戶與擁有數百萬關注者的用戶類似。 * 單元大小難以確定。 單元的大小是故障的影響點。 影響到一個單元的用戶數量。 要權衡他們愿意接受的用戶體驗以及相應的費用。 * 從 firehose 讀取是最大的網絡問題。 在一個小區內，網絡流量是可管理的。 * 隨著添加更多的細胞，可以將細胞放入一個從火喉讀取的細胞組中，然后復制到該組中的所有細胞中。 分層復制方案。 這也將有助于轉移到多個數據中心。 ### 關于在紐約創業 * NY 是一個不同的環境。 很多財務和廣告。 招聘具有挑戰性，因為沒有太多的啟動經驗。 * 在過去的幾年中，NY 致力于幫助初創企業。 紐約大學和哥倫比亞大學推出的計劃旨在使學生在初創企業中獲得有趣的實習機會，而不僅僅是去華爾街。 彭博市長正在建立一個專注于技術的本地校園。 ### 團隊結構 * 團隊：基礎架構，平臺，SRE，產品，網絡運營，服務。 * 基礎結構：第 5 層及以下。 IP 地址及以下，DNS，硬件配置。 * 平臺：核心應用程序開發，SQL 分片，服務，Web 操作。 * SRE：位于服務團隊和網絡運營團隊之間。 在可靠性和可伸縮性方面專注于更迫切的需求。 * 服務團隊：專注于更具戰略意義的工作（一個月或兩個月）。 * Web 操作：負責問題檢測和響應以及調整。 ### 軟件部署 * 從一組 rsync 腳本開始，這些腳本將 PHP 應用程序分布在各處。 一旦計算機數量達到 200，系統就開始出現問題，部署需要很長時間才能完成，并且計算機將處于部署過程的各種狀態。 * 下一階段使用 Capistrano 將部署過程（開發，登臺，生產）構建到其服務堆棧中。 可以在數十臺計算機上使用服務，但是通過 SSH 連接后，在部署到數百臺計算機上時再次開始出現故障。 * 現在，所有計算機上都運行一個協調軟件。 基于 RedHat 的 Func，這是一種用于向主機發出命令的輕量級 API。 縮放內置于 Func 中。 * 通過在一組主機上執行 X 來在 Func 上進行構建部署，這避免了 SSH。 假設您要在組 A 上部署軟件。主服務器伸向一組節點并運行 deploy 命令。 * deploy 命令通過 Capistrano 實現。 它可以進行 git checkout 或從存儲庫中提取。 易于擴展，因為他們正在使用 HTTP。 他們喜歡 Capistrano，因為 Capistrano 支持基于簡單目錄的版本控制，該版本與他們的 PHP 應用程序很好地兼容。 向版本更新邁進，每個目錄包含一個 [SHA](http://book.git-scm.com/1_the_git_object_model.html) ，因此可以輕松檢查版本是否正確。 * Func API 用于報告狀態，即這些機器具有這些軟件版本。 * 可以安全地重新啟動其所有服務，因為它們會清空連接，然后重新啟動。 * 激活之前，所有功能均在暗模式下運行。 ### 開發 * 從這樣的哲學開始：任何人都可以使用他們想要的任何工具，但是隨著團隊的成長，這種想法不起作用了。 新員工的入職非常困難，因此他們已經在堆棧上進行了標準化，以便他們能與之相處，快速發展團隊，更快地解決生產問題并圍繞他們開展業務。 * 流程大致類似于 Scrum。 輕巧。 * 每個開發人員都有一個預先配置的開發計算機。 它通過 Puppet 獲取更新。 * 開發人員機器可以滾動更改，進行測試，然后將其部署到階段，然后將其部署到生產中。 * 開發人員使用 vim 和 Textmate。 * 測試是通過 PHP 應用程序的代碼審查進行的。 * 在服務方面，他們已經實現了具有提交掛鉤，Jenkins 以及持續集成和構建通知的測試基礎架構。 ### 招聘流程 * 面試通常避免數學，困惑和腦筋急轉彎。 試著針對候選人實際要做的工作提出問題。 他們聰明嗎？ 他們會把事情做好嗎？ 但是衡量“完成工作”的難度很難評估。 目標是找到優秀的人才，而不是將人才拒之門外。 * 專注于編碼。 他們會要求提供示例代碼。 在電話采訪中，他們將使用 Collabedit 編寫共享代碼。 * 面試不是對抗性的，他們只是想找到最好的人。 面試期間，候選人可以使用他們的所有工具，例如 Google。 他們的想法是，開發人員在擁有工具時才能發揮最大作用，這就是他們進行采訪的方式。 * 挑戰是找到在 Tumblr 的流量水平下具有所需擴展經驗的人員。 世界上很少有公司致力于解決他們所面臨的問題。 * 例如，對于一個新的 ID 生成器，他們需要一個 JVM 進程以小于 1ms 的速率生成服務響應，速率為每秒 10K 請求和 500 MB RAM 限制并具有高可用性。 他們發現串行收集器在此特定工作負載下的延遲最小。 在 JVM 調整上花費了很多時間。 * 在 Tumblr 工程博客上，他們張貼了悼念詞，表達對 [Dennis Ritchie](http://engineering.tumblr.com/post/11381547149/derekg-rip-dennis-ritchie-he-gave-us-such) & [[ John McCarthy](http://engineering.tumblr.com/post/11893095969/john-mccarthy-widely-considered-the-father-of) 。 這是一種怪異的文化。 ## 獲得的經驗教訓 * 到處都是自動化。 * MySQL（加上分片）可擴展，而應用則不能。 * Redis 很棒。 * Scala 應用程序表現出色。 * 當您不確定項目是否可行時，請報廢項目。 * 請勿通過無用的技術手腕來依靠他們的生存來雇用人員。 雇用他們是因為他們適合您的團隊并且可以勝任。 * 選擇一個可以幫助您招聘所需人員的堆棧。 * 建立團隊的能力。 * 閱讀論文和博客文章。 像電池體系結構和選擇性實現這樣的關鍵設計思想都來自其他地方。 * 詢問您的同齡人。 他們與來自 Facebook，Twitter，LinkedIn 的工程師進行了交流，并交流了經驗。 您可能沒有權限訪問此級別，但可以與某人聯系。 * 韋德，不要涉足技術領域。 他們在嘗試將 HBase 和 Redis 投入生產之前，通過在試點項目或損害程度可能有限的角色中使用它們來學習。 非常感謝 Blake 的采訪。 他對時間很寬容，對解釋也很耐心。 如果您想談談您的架構配置文件，請 [與我聯系](http://highscalability.com/contact/) 。 ## 相關文章 * [Tumblr Engineering Blog](http://engineering.tumblr.com/) -包含很多優秀文章 * [與 Nathan Hamblen 一起使用 Finagle 和 Ostrich 構建網絡服務](http://vimeo.com/29763331) -Finagle 很棒 * [鴕鳥](https://github.com/twitter/ostrich/) -Scala 服務器的統計收集器&報告程序 * [規模為](http://tumblr.mobocracy.net/post/10984130543/id-generation-at-scale) 的 ID 生成，作者 Blake Matheny * [Finagle](http://twitter.github.com/finagle/) -JVM 的網絡堆棧，可用于構建 Java，Scala 或任何 JVM 托管語言的異步遠程過程調用（RPC）客戶端和服務器 。 Finagle 提供了一組豐富的獨立于協議的工具。 * [來自 Tumblr 的 Finagle Redis 客戶端](https://github.com/twitter/finagle/commit/c30ba58acfc19b96807f72162dcdd913365e2de2) * [Tumblr。 Evan Elias 撰寫的大量分片的 MySQL](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) -關于 MySQL 分片的更好的演示之一 * [Staircar：由 Redis 驅動的通知](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，作者：布萊克·馬森尼（Blake Matheny） * [Flickr 架構](http://highscalability.com/flickr-architecture)-談論 Flickr 的單元架構 是否有關于此基于單元的體系結構的更多信息？ 這些關鍵字對于 Google 來說是非常通用的... 如果您還要存儲數百萬個非法 mp3，也很難擴展。 查看 ex.fm API 關于 Tumblr 作為侵犯版權的避風港所暴露的內容。 在音樂方面，它們比 megaupload 更糟糕 我不知道該體系結構是否有一個標準術語 Andrew。 Salesforce 做類似的事情，例如使用術語 Pod。 Flickr 稱之為聯合方法。 似乎大多數服務器都包含： 500 臺運行 Apache 及其 PHP 應用程序的 Web 服務器。 使用 Nginx / PHP-FPM 代替 Apache / mod_php 是否有意義，因為事實證明，這可以顯著提高并發請求和服務整個頁面的時間？ 您為什么選擇 CentOS / Scientific 而不是 RHEL？ > 最初，Finagle 使用了 Actor 模型，但該模型已被刪除。 Anywhere I can read up on the issues they had with this approach? @meh：RHES 會帶來什么好處？ 這將是相當標準的安裝映像/配置。 任何操作系統問題，重新安裝都很簡單（為什么要進行故障排除，當您可以使用 PXE + config 管理在< 10m 中重新創建時）。 如此規模的 RHES 似乎是一筆不菲的巨額支出。 關于 tumblr 內部技術的真棒讀物。 感謝您發布文章，這一點非常有用。 虛擬化呢？ 他們僅使用硬件服務器嗎？ 管理所有這些的成本必須是巨大的。 該公司得到了風險投資公司的支持，但我想知道他們為保持運營狀況每年虧損多少錢？ > 是否有關于此基于單元的體系結構的更多信息？ 這些關鍵字對于 Google 來說是非常通用的... 還可以在該網站上查看 Evernote 上的文章； 它們具有類似的“單元”架構。 馬特，感謝您提供有關 Evernote 的提示。 我看了一下這篇文章：http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150million-reques.html，假設它是您本人 在想什么？ 我真的希望有人可以鏈接到受訪者提到的實際論文。 關于可伸縮性的噪音太多了，即使在這個級別上，也確實沒有那么困難。 本文所顯示的所有內容是，您可以擁有一個真正糟糕的體系結構，并且仍然維持相當大的流量。 這篇文章說 > MySQL（加上分片）可擴展，而應用則不能。 在多個地方，但是 MySQL 沒有分片。 這不是 MySQL 的功能，永遠不會。 應用程序在將數據發送到 MySQL 之前先對其進行分區。 這要求應用程序（或應用程序層）完全了解分區并進行管理。 這樣，您現在已經刪除了 RDBMS 的大多數核心功能（聯接，事務，外鍵完整性）。 這就引出了一個問題，當我們在追求擴展到所需容量的過程中，已經中止了 SQL 的所有基本功能時，為什么要全部使用 SQL。 是的，可以使用 MySQL 技術來執行此操作，但是最終您不再像 RDMBS 那樣使用它。 它具有您無法使用的所有功能，現在嚴重依賴于應用程序。 似乎僅僅使用為這種操作而設計的數據庫并從頭開始擴展會更聰明。 @本·烏雷茨基 使用 nginx / php-cgi 的性能更高，但是您必須注意： -您的腳本必須絕對無鎖且響應迅速。 一個“較長的”執行時間腳本（但< 1s）可能會阻止一個 CGI 進程，這對于整個服務器來說應該是不完整的。 -您需要找到一個“完美”的 php 版本，因為一個進程將執行的請求比使用 apache 重新發出的請求要多。 對于某些版本，您可能會感到有些意外。 根據我自己的經驗，在（nginx）/ fastcgi 上具有良好的可靠性需要花費更多時間。 架構...對...根本不起作用的功能呢，例如...搜索！ 還是不存在...像在主題開發人員的情況下清理上傳的資源？ 附言 不要誤會我的意思-我喜歡 Tumblr 的簡單性，但有些事情確實會踩到您的腳趾... 令人印象深刻的是，只有 15 位以上的網頁瀏覽工程師才 20 名。 令人印象深刻。 根據文章 HBASE 的使用： 支持 URL 縮短， 存儲歷史數據和分析 儀表板替換 我希望這意味著，所有博客 URL，博客數據都存儲在 HBASE 中。 如果我錯了，請糾正我。 文章還說， 大量數據存儲在 MySQL 中。 那么 MySQL 是否用于存儲在引入 HBASE 之前創建的舊博客？ 如果是這樣，服務節點是否將決定在何處加載儀表板？ 如果有人清楚，請解釋。 當整個小區停止服務時會發生什么？ 該單元中的用戶是否已重新歸宿？ 由于所有這些信息都存儲在故障節點中，這將如何影響那些用戶的收件箱？ “內部服務正在從基于 C / libevent 的方式轉變為基于 Scala / Finagle 的方式” 您能描述使用 Scala / Finagle 而不是 C / libevent 的原因嗎？ 謝謝！ 將這樣的系統以及支持該系統的業務基礎結構整合在一起需要做很多工作。 可能需要花費大量時間進行閱讀和編碼。 我說，恭喜 Tumblr 和 CEO Karp。 繼續做您所做的偉大工作。 :) 本文提到了 Nginx，但沒有說明如何使用它。 Varnish 用于緩存，HAProxy 用于 LB，Nginx 呢？ 感謝您的發布。 非常全面，連貫，詳細。 可以確定的時間是 Verizon 之前的收購。 我想知道老電話公司做了什么來弄亂這個漂亮的沙箱。 另一個奇跡：他們賺錢了嗎？