# Twitter 的架構用于在 5 秒內處理 1.5 億活躍用戶，300K QPS，22 MB / S Firehose 以及發送推文 > 原文： [http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) [](http://www.flickr.com/photos/13733851@N00/9235686327/sizes/o/in/photostream/) 解決 Twitter“問題”的玩具解決方案是最受歡迎的可伸縮性。 每個人都認為 Twitter 很容易。 揮舞著一點建筑手，我們就擁有了一個可擴展的 Twitter，就這么簡單。 好吧，這不是那么簡單，就像 Twitter 的工程副總裁 [Raffi Krikorian](https://twitter.com/raffi) 在他對 [時間軸的出色且詳盡的介紹中所描述的那樣 規模](http://www.infoq.com/presentations/Twitter-Timeline-Scalability) 。 如果您想了解 Twitter 的工作原理，請從這里開始。 它是逐漸發生的，所以您可能會錯過它，但是 Twitter 已經成長。 它最初是一個苦苦掙扎的 [三層 Ruby on Rails](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster) 網站，現在已經成為一個精美的服務驅動核心，我們現在實際去看看其他服務是否已關閉。 很大的變化。 Twitter 現在擁有 1.5 億全球活躍用戶，處理 300K QPS 來生成時間線，以及每秒輸出 22 MB 速度的流水線。 每天有 4 億條推文通過該系統，從 Lady Gaga 的手指到 3100 萬追隨者的推文最多可能需要 5 分鐘。 有幾點值得注意： * Twitter 不再希望成為網絡應用程序。 Twitter 希望成為為全球移動客戶端提供動力的一組 API，充當地球上最大的實時事件總線之一。 * Twitter 主要是一種消費機制，而不是生產機制。 300K QPS 用于讀取時間軸，而每秒僅 6000 個請求用于寫入。 * 具有大量關注者名單的離群值正在成為一種常見情況。 從具有大量關注者的用戶發送推文（即扇出大）可能會很慢。 Twitter 嘗試在 5 秒內做到這一點，但它并不總是有效，特別是當名人互相推 t 時，這種情況越來越多。 結果之一是，回復可能會在收到原始推文之前到達。 Twitter 正在從對寫入的所有工作轉變為對高價值用戶進行更多的讀取工作。 * 您的家庭時間軸位于 Redis 集群中，最多包含 800 個條目。 * Twitter 從您關注的人以及單擊的鏈接上對您了解很多。 當雙向遵循不存在時，隱式社會契約可以暗示很多。 * 用戶關心推文，但是推文的文本與 Twitter 的大多數基礎結構幾乎無關。 * 它需要一個非常復雜的監視和調試系統來跟蹤復雜堆棧中的性能問題。 過去遺留決策的幽靈總是困擾著系統。 Twitter 如何運作？ 閱讀 Raffi 精彩演講的內容，并發現... ## 挑戰 * 1.5 億用戶的時間軸（首頁和搜索）的 300K QPS 可能會很慢。 * 幼稚的物化是整個 Twitter 上大量的精選聲明。 它被審判并死亡。 * 解決方案是基于寫的扇出方法。 推文到達時要進行大量處理，以找出推文應該去哪里。 這樣可以快速輕松地讀取時間。 不要對讀取進行任何計算。 在寫路徑上執行所有工作后，攝取速率比讀路徑慢，約為 4000 QPS。 ## 團體 * 平臺服務小組負責 Twitter 的核心可擴展基礎架構。 * 他們運行稱為“時間軸服務”，“推文服務”，“用戶服務”，“社交圖譜服務”的東西，這些工具為 Twitter 平臺提供了強大的支持。 * 內部客戶端使用與外部客戶端大致相同的 API。 * 已針對第三方 API 注冊了超過 1 百萬個應用 * 與產品團隊簽訂合同是他們不必擔心規模。 * 進行容量規劃，設計可擴展的后端系統，隨著站點以意想不到的方式不斷增長而不斷替換基礎架構。 * Twitter 有一個架構小組。 有關 Twitter 的整體整體架構。 維護技術債務清單（他們希望擺脫的清單）。 ## 推我拉我 * 人們一直在 Twitter 上創建內容。 Twitter 的工作是弄清楚如何將內容聯合起來。 如何將其發送給您的關注者。 * 真正的挑戰是實時約束。 目標是在不超過 5 秒的時間內將消息流傳遞給用戶。 * 交付意味著收集內容并在 Internet 上施加壓力，以使其盡快恢復。 * 傳遞到內存中的時間軸群集，推式通知，已觸發的電子郵件，所有 iOS 通知以及 Blackberry 和 Android，SMS。 * Twitter 是按世界上任何活躍用戶的最大 SMS 生成器。 * 選舉可能是內容進入和內容散播的最大驅動力之一。 * 時間線的兩種主要類型：用戶時間線和主時間線。 * 用戶時間軸是特定用戶已發送的所有推文。 * 主時間軸是您正在關注的人的所有用戶時間軸的時間合并。 * 業務規則被應用。 @您不認識的人的回復被刪除。 可以過濾掉來自用戶的轉發。 * 在 Twitter 規模上做到這一點具有挑戰性。 * 拉式 * 目標時間表。 諸如 twitter.com 和 home_timeline API 之類的東西。 發推文是因為您要求查看而發給您的。 基于拉式的傳遞：您正在通過 REST API 調用從 Twitter 請求此數據。 * 查詢時間軸。 搜索 API。 針對語料庫的查詢。 盡快返回與特定查詢匹配的所有推文。 * 基于推送 * Twitter 運行著最大的實時事件系統之一，通過 Firehose 以 22 MB /秒的速度推送推文。 * 打開一個 Twitter 套接字，他們將在 150 毫秒內將所有公開推文推送給您。 * 在任何給定時間，推集群都可以打開約一百萬個套接字。 * 面向搜索引擎之類的客戶。 所有公開推文都來自這些插座。 * 不，你不能擁有它。 （您無法處理/承擔事實。） * 用戶流連接。 Powers TweetDeck 和適用于 Mac 的 Twitter 也經歷了這里。 當您登錄時，他們會查看您的社交圖，僅從您所關注的人那里發送消息，從而重新創建家庭時間軸體驗。 通過持久連接，無需輪詢即可獲得相同的時間軸體驗。 * 查詢 API。 發出關于推文的常規查詢。 創建推文并找到與查詢匹配的推文后，會將它們路由到查詢的注冊套接字中。 ## 高水平的基于拉的時間軸 * 通過寫 API 發出推文。 它通過負載平衡器和 TFE（Twitter 前端）以及其他無法解決的問題。 * 這是一條非常有方向的道路。 完全預先計算的家庭時間表。 隨著推文的出現，所有業務規則都將執行。 * 立即發生扇出過程。 傳入的推文放置在龐大的 Redis 集群中。 每個推文在 3 臺不同的計算機上復制 3 次。 在 Twitter 規模上，許多機器每天都會發生故障。 * 扇出查詢基于[群](https://github.com/twitter/flockdb)的社交圖服務。 Flock 維護關注者和關注者列表。 * Flock 返回收件人的社交圖，并開始遍歷 Redis 集群中存儲的所有時間軸。 * Redis 群集具有幾個 TB 的 RAM。 * 一次流水線式 4k 目的地 * Redis 內部使用本機列表結構。 * 假設您發了推文，并且有 2 萬名關注者。 扇出守護程序將執行的操作是查找 Redis 集群中所有 20K 用戶的位置。 然后，它將開始在整個 Redis 集群的所有這些列表中插入 tweet 的 Tweet ID。 因此，在 Redis 集群中，每條推文寫入操作都會產生多達 20K 次插入。 * 存儲的內容是生成的推文的推文 ID，該推文發起人的用戶 ID，以及用于標記是轉推，回復還是其他內容的 4 個字節的位。 * 您的家庭時間軸位于 Redis 集群中，長度為 800 個條目。 如果翻頁時間足夠長，您將達到限制。 RAM 是確定當前 tweet 集可以持續多長時間的限制資源。 * 每個活動用戶都存儲在 RAM 中，以降低延遲。 * 活動用戶是指在 30 天內登錄 Twitter 的用戶，該用戶可能會根據緩存容量或 Twitter 的使用情況而變化。 * 如果您不是活躍用戶，則該推文不會進入緩存。 * 只有您的家庭時間軸命中磁盤。 * 如果您從 Redis 集群中掉出來，那么您將經歷一個稱為重建的過程。 * 針對社交圖服務查詢。 找出您關注的人。 為它們中的每一個命中磁盤，然后將它們推回 Redis。 * 它是 MySQL 通過 [Gizzard](https://github.com/twitter/gizzard) 處理磁盤存儲的功能，該存儲區提取了 SQL 事務并提供了全局復制。 * 如果一臺機器有問題，則通過復制 3 次，則他們不必為每個數據中心重新創建該機器上所有時間線的時間線。 * 如果推文實際上是轉發，則將指針存儲到原始推文。 * 當您查詢家庭時間軸時，將查詢時間軸服務。 然后，“時間線服務”只需要查找一臺帶有您自己的家庭時間線的機器。 * 有效地運行 3 個不同的哈希環，因為您的時間軸位于 3 個不同的位置。 * 他們找到第一個可以最快到達的人，并盡快返回。 * 權衡是扇出需要更長的時間，但是讀取過程很快。 從冷緩存到瀏覽器大約 2 秒鐘。 對于 API 調用，大約需要 400 毫秒。 * 由于時間軸僅包含推文 ID，因此它們必須“水合”那些推文，即找到這些推文的文本。 給定一個 ID 數組，他們可以執行一次 multiget 并從 T-bird 并行獲取這些推文。 * Gizmoduck 是用戶服務，而 Tweetypie 是推特對象服務。 每個服務都有自己的緩存。 用戶緩存是具有整個用戶庫的內存緩存群集。 Tweetypie 大約有一個月的推文和一半的推文存儲在其 Memcache 集群中。 這些暴露給內部客戶。 * 一些讀取時間過濾發生在邊緣。 例如，在法國過濾掉納粹的內容，因此在內容被發送出去之前會進行讀取。 ## 高級搜索 * 與拉力相反。 所有這些都在讀取路徑上計算得出，這使寫入路徑變得簡單。 * 當出現一條推文時，Ingester 會標記化并找出他們想要索引的所有內容，并將其填充到一臺 Early Bird 機器中。 Early Bird 是 Lucene 的修改版本。 索引存儲在 RAM 中。 * 在扇出狀態中，一條推文可能會存儲在 N 個關注您的家庭時間軸中，在 Early Bird 中，一條推文僅存儲在一臺 Early Bird 計算機中（復制除外）。 * Blender 創建搜索時間線。 它必須在數據中心內分散聚集。 它會查詢每個 Early Bird 碎片，并詢問您是否有與此查詢匹配的內容？ 如果您要求“紐約時報”，則查詢所有分片，然后將結果返回，排序，合并和重新排序。 重新排名是通過社交方式證明的，這意味著要查看轉發，收藏和回復的數量。 * 活動信息是在寫入的基礎上計算的，其中有一個活動時間表。 當您偏愛和回復推文時，將維持活動時間線，類似于家庭時間線，它是一系列活動的 ID，因此有收藏夾 ID，回復 ID 等。 * 所有這些都送入攪拌機。 在讀取路徑上，它會重新計算，合并和排序。 返回您所看到的搜索時間軸。 * 發現是根據他們對您的了解進行的定制搜索。 他們之所以知道很多，是因為您關注了很多人，單擊鏈接，這些信息將用于發現搜索。 它會根據收集到的有關您的信息進行排名。 ## 搜索和拉是反函數 * 搜索和拉動看起來非常相似，但是它們具有彼此相反的屬性。 * 在主時間軸上： * 寫。 當有一條推文出現時，會有一個 O（n）進程寫入 Redis 集群，其中 n 是跟隨您的人數。 令 Lady Gaga 和 Barack Obama 感到痛苦的是，他們在整個集群中進行了數以千萬計的插入操作。 所有 Redis 群集都在備份磁盤，Flock 群集將用戶時間線存儲到磁盤，但是通常在 Redis 群集的 RAM 中找到時間線。 * 讀。 通過 API 或網絡查找合適的 Redis 機器為 0（1）。 Twitter 經過優化，可以在家庭時間軸上的讀取路徑上高度可用。 讀取路徑以 10 毫秒為單位。 Twitter 主要是一種消費機制，而不是生產機制。 每秒讀取 300K 請求，寫入每秒 6000 RPS。 * 在搜索時間軸上： * 寫。 當一條推文進入并擊中 Ingester 時，僅擊中一臺 Early Bird 機器。 寫入時間路徑為 O（1）。 在排隊和處理之間的 5 秒鐘內，將提取一條推文，以找到要寫入的一條“早起的鳥兒”。 * 讀。 當讀取進來時，它必須在整個群集中讀取 0（n）。 大多數人不使用搜索，因此他們可以有效地存儲推文以進行搜索。 但是他們及時付款。 讀數約為 100 毫秒。 搜索從不打磁盤。 整個 Lucene 索引都位于 RAM 中，因此散點式聚集讀取非常有效，因為它們從未命中磁盤。 * 推文幾乎與大多數基礎架構無關。 [T 鳥存儲](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html) 整個推文集。 一條推文的大部分內容都在 RAM 中。 如果沒有，請打 T-bird 并執行選擇查詢以再次將它們退回。 文字幾乎無關緊要，除了搜索，趨勢或正在發生的事情之外。 家庭時間表幾乎根本不在乎。 ## 未來 * 如何使該管道更快，更高效？ * 扇出動作可能很慢。 嘗試在 5 秒內完成操作，但有時不起作用。 非常辛苦，尤其是在名人鳴叫時，這種情況越來越多。 * Twitter 關注圖是不對稱關注。 僅在給定時間關注的人上呈現推文。 Twitter 對您了解很多，因為您可能關注 Lance Armstrong，但他沒有關注您。 當雙向遵循不存在時，隱式社會契約可以暗示很多。 * 問題在于大型基數圖。 @ladygaga 有 3100 萬粉絲。 @katyperry 有 2800 萬關注者。 @justinbieber 有 2800 萬關注者。 @barackobama 有 2300 萬關注者。 * 這些人之一發推文時，要在數據中心中寫很多推文。 當他們開始互相交談時，這尤其具有挑戰性，這種情況一直存在。 * 這些高扇出用戶是 Twitter 面臨的最大挑戰。 在名人的原始推文發布之前，一直都有回復。 他們介紹了整個站點的比賽條件。 如果從 Lady Gaga 發推文到宣告發散花幾分鐘的時間，那么人們會在不同的時間點看到她的推文。 最近關注 Lady Gaga 的人可能比過去關注她的人早 5 分鐘看到她的推文。 假設某人在早期接收列表中進行了回復，然后在仍在進行扇出操作的同時對該回復的扇出進行了處理，因此該回復會在接收到其推文的人的原始推文之前注入。 引起很多用戶混亂。 由于推文主要是單調增加的，因此在發布前按 ID 對其進行排序，但這并不能解決該范圍的問題。 高價值扇出始終排隊備份。 * 試圖弄清楚如何合并讀寫路徑。 不再分散高價值用戶。 對于像泰勒·斯威夫特（Taylor Swift）這樣的人，不再煩惱扇出，而在閱讀時將其合并到時間表中。 平衡讀寫路徑。 節省百分之十的計算資源。 ## 去耦 * 推文以許多不同的方式分叉，主要是使團隊彼此分離。 搜索，推送，關注電子郵件和家庭時間軸團隊可以彼此獨立工作。 * 由于性能原因，系統已被解耦。 Twitter 以前是完全同步的。 由于性能原因，這種情況在 2 年前就停止了。 將推文吸收到推文 API 中最多需要 145 毫秒，然后所有客戶端都將斷開連接。 這是出于遺留原因。 Ruby 通過 MRI（單線程服務器）為寫入路徑提供動力，每次分配 Unicorn 工作者時，處理能力就被消耗 eat 盡。 他們希望能夠盡快釋放客戶端連接。 出現一條推文。Ruby 將其吸收。 將其放入隊列并斷開連接。 他們每個盒子只運行大約 45-48 個進程，因此每個盒子只能同時攝取那么多推文，因此他們希望盡快斷開連接。 * 這些推文將傳遞到異步途徑，我們一直在討論的所有內容都將在其中傳遞。 ## 監控方式 * 辦公室周圍的儀表板顯示了系統在任何給定時間的運行情況。 * 如果您有 100 萬關注者，則需要花費幾秒鐘來散布所有推文。 * 推文輸入統計：每天 4 億條推文； 日均 5K /秒； 每日峰值 7K /秒； >在大型活動中為 12K / sec。 * 時間軸交付統計：每天 30b 次交付（?21m / min）； 3.5 秒@ p50（第 50 個百分位數），傳送到 1m； 30 萬次/秒； @ p99，最多可能需要 5 分鐘 * 名為 VIZ 的系統監視每個群集。 向時間線服務請求以從 Scala 群集中獲取數據的平均時間為 5 毫秒。 @ p99 是 100 毫秒。 @ p99.9 是它們命中磁盤的位置，因此需要花費幾百毫秒的時間。 * [Zipkin](https://twitter.com/zipkinproject) 基于 Google 的 Dapper 系統。 有了它，他們可以對請求進行污染并查看其命中的每個服務以及請求時間，因此他們可以對每個請求的性能有非常詳細的了解。 然后，您可以深入查看并查看每個單個請求，并了解所有不同的時間。 通過查看在請求上花費的時間來花費大量時間來調試系統。 他們還可以按階段顯示匯總統計信息，以查看扇出或交付所需的時間。 這是一個為期 2 年的項目，目的是使活動用戶的時間線降低到 2 毫秒。 花了很多時間來解決 GC 暫停問題，解決內存緩存查找問題，了解數據中心的拓撲結構以及為這種成功設置集群。 ## 相關文章 * [為什么 Facebook，Digg 和 Twitter 很難擴展？](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1hve87/the_architecture_twitter_uses_to_deal_with_150m/) * [關于黑客新聞](https://news.ycombinator.com/item?id=6007650) * [Twitter 上的實時交付體系結構](http://www.infoq.com/presentations/Real-Time-Delivery-Twitter) * [論文：瘋狂的飼料：有選擇地實現用戶的事件 Feed](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) * [Google：馴服長時延的尾巴-當更多的機器等于更差的結果時](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) * [Facebook 是否開發了自定義的內存數據庫來管理其新聞提要？](http://www.quora.com/Facebook-Engineering/Did-Facebook-develop-a-custom-in-memory-database-to-manage-its-News-Feeds) （閱讀時扇出） 我不會將 22MB / s 稱為“ firehose”，這確實占用很少的帶寬……您確定您有權利嗎？ 我雖然說“不會再有類似的東西了” 然后我雖然是 NSA Prism 的一員。 @吉姆·柯林斯（Jim Collins）：假設每條推文都是最大長度，即每秒約 144,179 條推文。 顯然，并非所有的推文都具有最大長度，因此可能要大得多。 回復：Firehose 吉姆（Jim），推特（Twitter）從一開始就一直將其稱為“火柴”。 要記住的是，它是每條公共推文（每天刪除）中大約每天 1-2kb 大小的連續推文流，每條每天 10-20k /秒。 沒有休息，沒有暫停。 典型的消費者將實時（或接近）實時處理該卷，因為從歷史上看，您不應該保存推文內容。 以 22 兆/秒的速度，這對客戶端來說是 57 TB /月的入口。 但是，Twitter 需要將相同的數據發送給多個客戶（此計數尚未公開），這就是他們向該服務收費的原因之一（如果我沒記錯的話，每月收費約 2 萬美元）。 嗯是的。 你笑了，但這不是一個小問題。 Scala 規則 不是“公共汽車”-不僅僅是一個吻。 是“公共汽車”。 如果您認為 22MB /秒是小帶寬，那么您是新手。 一年的 31,536,000 秒中的每個秒為 22MB /秒。 是的，這是 3150 萬 x 22MB。 關鍵確實在于它是不間斷的。 您的 USB 密鑰以 22MB /秒的速度持續一分鐘，與發送數萬條消息的 22MB /秒的流無關。 這是瘋狂的并發，它的工作原理令人驚訝。 親愛的 Pedantic，公車是公車的正確復數形式。 在幸災樂禍之前先查一下。 在 Fashiolista，我們已經建立了一個類似的解決方案，我們正在開源中。 對于早期預覽，請查看： https://github.com/tschellenbach/Feedly 經過數百萬用戶的考驗。 （不是成千上萬的推特：）） 我們仍在與 Fashiolista 完全分離的過程中，第一個用戶友好的 Beta 版將于 7 月底完成。 目前，您可以將其用作靈感來源。 QPS ==每秒查詢嗎？ > >一條推文最多可能需要 5 分鐘才能從 Lady Gaga 的手指流到她的 3100 萬關注者。 你的意思是 5 秒，不是嗎？ “應用了業務規則。刪除了您不關注的人的回復。可以過濾掉來自用戶的轉發。在 Twitter 范圍內做到這一點具有挑戰性。” 嗯...當他們做出這個改變，殺死了我的“新人”之后，發現率就死了，他們說這是因為它沒有擴展？ 現在他們說進行這種過濾具有挑戰性嗎？ 此外，所有帳戶的 firehose 客戶最多不超過 20 個，但有趣的是（請看他們的招聘模式和客戶列表）是 dataminr 處理 Ruby 的單線程需要相當多的技巧。 Matz 在 2009 年中旬訪問了 Moffett Field 的 SV RoR 聚會時說，并行化是 Ruby 的第一要務。 但是已經四年了... 不要使用獨角獸，使用彪馬。 MRI 會尖叫。 看起來像是該課程的所有數據 http://blogs.ischool.berkeley.edu/i290-abdt-s12/ 公交車與公交車 在 21 世紀的英語中，公交車是名詞公交車的首選復數形式。 總線偶爾出現，并且字典將其列為輔助拼寫，但是一個多世紀以來一直不受青睞。 在所有主要英語版本中都是如此。 在 19 世紀以公車的縮寫出現公共汽車之后，公共汽車和公共汽車（邏輯上是公共汽車的復數形式，是公共汽車的早期替代拼寫）爭奪了幾十年的統治地位。 但是，到 20 世紀初，公共汽車已成為明顯的贏家，并且它已經逐漸流行。 如今，對于每種實例，公交車都會在網絡上出現 15 次。 “扇出”，“扇出”到底是什么意思？？？？ Gizzard 已退休： [https://github.com/twitter/gizzard](Gizzard on GitHub) 似乎需要更新。 但是，Twitter 的體系結構可能正在不斷發展。 如果您正在閱讀此文章，則 Stream-Framework 和 Stream 可能會派上用場： https://getstream.io/ https://github.com/tschellenbach/stream-framework 基于拉取的時間軸的高級錯誤： 這是不正確的： 只有您的家庭時間軸命中磁盤。 正確的是： 只有您的用戶時間軸命中磁盤。 您的主時間軸都不會命中磁盤，而只會在 Redis 集群中。 “由于您的時間軸位于 3 個不同的位置，因此有效地運行 3 個不同的哈希環。” -為什么三聲響？ 每個副本集都有一個不同的哈希表環嗎？ 緩存如何分片？ 通過 userId？