支撐5億用戶、1.5億活躍用戶的Twitter最新架構詳解及相關實現

http://www.csdn.net/article/2013-07-11/2816199-architecture-twitter-uses-to-deal-with-150m-active-users

摘要：Twitter出道之初只是個奮鬥在RoR上的小站點，而現在已擁有1.5億的活躍用戶，系統日傳輸tweet更多達4億條，並已完成了以服務爲核心的系統架構蛻變。

Twitter現在在世界範圍內已擁有1.5億的活躍用戶，爲了給用戶生成timeline（時間軸）需支撐30萬QPS，其firehose每秒一樣生成22MB數據。整個系統天天傳輸tweet 4億條，而且只須要5分鐘就可讓一條tweet從Lady Gaga手中呈現到她3100萬粉絲的屏幕上。當下Twitter系統的規模及強大的吞吐量確實惹人豔羨，然而在出道之初Twitter也只是個奮鬥在 RoR上的小站點而已，下面就一覽Twitter如何完成從RoR到以服務爲核心的系統架構蛻變。

 

Twitter系統的一些特性：

1. 當下的Twitter已不知足於Web Ap的現狀。Twitter指望成爲一組API，驅動世界範圍內的移動客戶端，成爲世界級最大的實時事件鏈之一。

2. Twitter主導的是消費機制，而不是生產機制。每秒讀取timeline的操做就會產生30萬次的查詢，而每秒的寫入請求只有6000左右。

3. 離羣值，擁有巨量粉絲的個體開始變得廣泛，大量粉絲擁有者發送tweet時會由於大量的擴散而變得緩慢。Twitter試圖將這個延時控制在5秒內，可是也並不是一直生效，特別是名人們發送tweet以及相互轉發變得愈來愈頻繁後。這樣就致使轉發的內容可能比原始內容先一步到達共同粉絲的界面上，這樣一來，就高價值用戶來講，Twitter的主要精力必須從寫操做轉移到讀操做上。

4. 使用Redis集羣處理Home Timeline（首頁時間軸，包含了衆多關注者的tweet），最大條數爲800。

5. 從你關注的人和你點擊的連接，Twitter能夠獲知一系列關於你的信息。

6. 用戶最關心的是tweet內容，然而大部分的基礎設施卻和這些內容不相關。

7. 對如此複雜堆棧進行性能追蹤所需求的監視和調試系統每每很是複雜，一樣舊決策的影響會不時的出現。

Twitter面臨的挑戰

1. 1.5億的用戶以及支撐timeline（home及Search）的30萬QPS會讓最初的具體實現（Naive materialization）變得緩慢。

2. 最初的具體實現由大量選擇語句組成，遍佈整個Twitter系統，曾今使用後被取締。

3. 使用一個基於寫的擴散方案。在接收到tweet時，系統將作大量的計算以發現tweet須要呈現的用戶。這將造就更快、方便的讀取，不要對讀作任何的計算。因爲全部的計算都被安排到寫去執行，每秒大約可處理4000個寫操做，比讀操做要慢一些。

Twitter的團隊合做

1. Platform Service團隊承擔起了Twitter核心基礎設施的一切事務：

 

• 他們負責Timeline Service、Tweet Service、User Service、Social Graph Service這些驅動Twitter平臺的全部組件。
• 內外客戶端使用了大體相同的API
• 產品團隊不須要擔憂任何規模相關
• 針對第三方API的註冊應用過百萬
• 作容量規劃，打造可擴展後端系統架構，在網站超出預期增加時要不斷的更換基礎設施。

 

2. Twitter還擁有一個架構團隊。負責Twitter的總體架構，維護技術負債列表。

Pull和Push模式

1. 任什麼時候刻都有用戶在Twitter上發佈內容，Twitter的任務就是考慮如何將消息同步發出並呈現到粉絲。

2. 真正的挑戰就是實時性約束，目標則是在5秒內將消息發送到粉絲：

• 交付意味着儘量快的收集內容、投入互聯網，而且在儘量短的時間內返回。
• 交付要作的是發佈到內存timeline集羣、推送通知以及觸發電子郵件，其中包括全部的iOS、黑莓、安卓通知以及SMS。
• Twitter是最大的SMS製造者
• Elections能夠成爲產生內容而且以最快速度擴散內容的最大動力

3. 兩種類型的timeline：user timeline（用戶時間軸，即指定用戶tweet頁）及home timeline

• user timeline就是一個指定的用戶發佈的全部tweet
• Home timeline是你全部關注用戶user timeline的一個臨時合併
• 業務規則。非你關注人@你時，將會被自動過濾，轉發的tweet也能夠被過濾。
• 在Twitter的規模作這些事情是很是有挑戰性的

 

Pull模式

1. 指向timeline，好比Twitter.com及hone_line API。之因此將tweet發送給你，是由於你對其進行了請求。基於Pull的交付：你經過REST API的調用向Twitter請求這些數據。

2. 查詢timeline，搜索API。對資料庫進行查詢，儘量快的返回全部匹配指定查詢的tweet。

Push模式

1. Twitter運行了一個巨型的實時事件系統，經過Firehose以每秒22M的速度推送tweet。

• 給Twitter打開一個socket，他們將會在150毫秒內完成全部公共tweet的推送。
• 任什麼時候候給推送集羣打開的socket都超過1百萬個
• 使用相似搜索引擎的firehose客戶端，全部公共的tweet都經過這些socket傳輸

2. 用戶流鏈接。TweetDeck及Mac版的Twitter一樣經過這種方式驅動。在登陸的時候，Twitter會查看你的社交圖，一樣也只會推送關注人的消息，重建home timeline，而不是在持久的鏈接過程當中得到同一個timeline。

3. 查詢API，發佈一個對tweet的持續查詢時，每當有新的tweet發佈，而且被認定匹配這個查詢，系統會將這條tweet發送給相應的socket。

高等級基於Pull的timeline

 

• Tweet由一個寫入API生成，它將會經過負載均衡器及TFE（Twitter Front End）
• 這種作法很直接，全部的業務邏輯在tweet生成時就已經被執行。
• 隨着tweet的擴散過程開始，新生成的tweet會被投入一個大規模的Redis集羣中。每一個tweet都會在3個不一樣的機器上作3個拷貝。由於在Twitter的規模，天天會有大把的機器出故障。
• 粉絲的查詢基於Flock的社交圖服務，Flock會維護粉絲及粉絲列表：

 

 

• Flock會返回一個接收者的社交圖，而且開始循環訪問全部存儲在Redis集羣上的timeline
• Redis集羣擁有TB級以上的內存
• 每次投遞4K左右的tweet
• Redis使用原生的表結構
• 若是你有2萬個粉絲，負責粉絲查詢的守護進程將會確認2萬個用戶在Redis集羣中的具體位置，而後它會橫跨整個Redis集羣將Tweet ID插入相應的列表中。因此當你有2萬個粉絲時，每條tweet的寫入都會形成2萬個插入操做。
• 儲存的信息包括新生成tweet的ID、tweet編寫者ID以及一個4字節大小的狀態信息（轉發、評論或者是其它相關）。
• Home timeline位於Redis集羣中，每一個有800條tweet。若是你向後翻太多頁就沒了，RAM是限制列表tweet數量的最大瓶頸。
• 爲了控制延時，全部活躍用戶都存儲在內存中。
• 活躍用戶的定義是在30天內有登錄過Twitter，固然這個規則能夠根據緩存容量、實際使用等進行修改。
• 若是你不是活躍用戶，tweet就不會被放入緩存。
• 只對home timeline進行存盤（持久化。PS：我的以爲這裏應該是user timeline，若是是home timeline下文的重建方法顯然不科學，歡迎你們討論）
• 若是home timeline不在Redis集羣中，則須要經歷一個重建的過程：

 

 

1. 對社交圖服務進行查詢，找出你關注的人。分別的訪問磁盤獲取每一個人的數據，而後將他們送回Redis。
2. 經過Gizzard使用MySQL處理磁盤存儲，這將抽象出全部SQL事務而且提供了全局備份。

 

 

• 鑑於每條tweet都會作3個備份，若是其中某臺機器發生故障，他們無需對這臺機器上的全部timeline進行重建。
• 當tweet被轉發時，將會存儲一個指向原tweet的指針。

 

 

• 當作home timeline查詢時，Timeline Service將被調用。Timeline Service確認home timeline究竟存在哪臺機器上：

 

 

• 鑑於timeline備份在3個不一樣的機器上，因此須要運行3個不一樣的哈希環。
• 一旦找着其中一個，就會盡量快的返回結果。
• 雖然這個過程會花費稍長的一點時間，可是讀的處理仍然很快。從冷緩存到瀏覽器上呈現大約須要2秒，其中一個API的調用時間大約400毫秒。

 

 

• 鑑於timeline只包含了tweet的ID，因此還必需要作tweet內容的查詢。肯定了ID之後，Twitter將經過T-bird並行獲取tweet的內容。
• Gizmoduck是個用戶服務，而Tweetypie則是個tweet對象服務，每一個服務都擁有本身的獨立緩存。用戶緩存使用的是memcache集羣，緩存了全部用戶。Tweetypie處理的是上個月的內容，它將一半的tweet儲存在它獨立的memcache集羣中，固然這個部分服務的是內部用戶。
• 內容的過濾一樣會省卻一些讀取時間，好比過濾掉法國的納粹相關，這些內容的讀取時間在呈現以前就被過濾了。

 

高等級的搜索

1. 全部的計算都經過讀來解決，這讓寫更加簡潔

2. 當有tweet生成時，Ingester會作相應的語法分析和索引，隨後會將其傳入Early Bird機器中。Early Bird屬於Lucene的修改版本，同時索引都儲存在內存中。

3. 在tweet擴散過程當中，它可能會被儲存在多個home timeline中，其個數由粉絲的數量決定。然而在Early Bird中，一個tweet只會被存入一個Early Bird機器中（不包括備份）。

4. Blender負責timeline的查詢，橫跨整個數據中心作集散操做。它對每一個Early Bird作查詢，以發現與查詢條件匹配的內容。若是你搜索「New York Times」，Blender會查詢數據中心的全部分片並返回結果，同時還會作分類、合併及從新排序等。排序的規則基於互動的數據，也就是轉發、收藏及評論的數量等。

5. 互動的信息使用寫的模式完成，這裏會創建一個互動timeline。若是你收藏或者回復一個tweet，將會觸發對互動timeline的修改；相似於home timeline，它一樣由一系列的互動ID組成，好比收藏ID、評論ID等等。

6. 全部這些信息都被送到Blender。以讀的方式進行重算、合併以及分類，返回的結果就是search timeline爲你呈現的界面。

7. Discovery是個基於你相關信息的定製搜索，這些信息主要來自你關注的人、打開的連接，而從新排序的規則一樣基於這些信息。

Search和Pull是相反的

1. 搜索和pull看起來很是類似，其實他們有着本質上的區別。

2. 在home timeline狀況下：

• 寫。一個寫tweet的動做會觸發一個O（n）規模的Redis集羣寫入操做，n的值取決於粉絲的數量，因而可知處理Lady Gaga及Barack Obama這樣擁有數千萬粉絲的名人將會很麻煩。Redis集羣上的信息都會寫入磁盤，Flock集羣會將user timeline儲存到磁盤上，可是一般狀況下timeline在Redis集羣的內存中均可以發現。
• 讀。經過API或網絡查找Redis是一個常數規模的操做。Twitter對home tiimeline的讀操做作了高可用性優化，讀操做只花費數十毫秒。這裏也能夠看出Twitter主導的是一個消費機制，而不是生產機制。每秒可處理30萬個讀操做，而寫操做每秒處理6000個。

3. 搜索timeline狀況：

• 寫。Tweet生成，而且傳輸到Ingester，只會寫入一個Early Bird機器。一個tweet處理的時間大約爲5秒，其中包括了排隊及尋找待寫入的Early Bird 機器。
• 讀。每一個讀請求都會觸發一個O(n)規模的集羣讀操做。讀大約須要100毫秒，搜索不涉及到存盤。全部的Lucene索引都保存在RAM中，因此聚散是很是有效率的，由於不涉及到磁盤。

4. Tweet的內容基本上與大多數的基礎設施都是無關的。T-bird存儲了全部tweet內容，大部分的tweet內容都是在內存中。若是沒有的話，能夠經過select查詢將其拉回內存。與tweet內容相關的功能很是少，搜索就是其中一個，而Home timeline則徹底不關心。

將來的工做

1. 如何將這條數據的管道打造的更快更有效

2. 在5秒內作到tweet的擴散，可是並非時刻的奏效，特別是愈來愈多的高粉單位。

3. Twitter是非對稱的關注，只有你關注人的tweet纔會呈現給你。Twitter能夠從這些單向關注中獲取你更多的信息，有些單向關注一樣還影射出一些社會契約。

4. 問題通常發生在大基數的圖上：@ladygaga擁有3100萬粉絲，@katyperry擁有2800萬粉絲，@justinbieber擁有2800萬粉絲，@barackobama擁有2300萬粉絲。

5. 大批量粉絲的擁有者每發送一條tweet將形成數據中心大量的寫入操做，而隨着愈來愈多名人之間的交互，挑戰變得更加的艱鉅。

6. 這些須要擴散給大批量用戶的tweet是Twitter最大的挑戰，在關注這些名人的共同粉絲中，常常會出現回覆tweet比原文更早一步送達的狀況。他們在站點中引入競態條件，好比最近關注Lady Gaga的粉絲可能會比老早以前關注的粉絲早5分鐘看到tweet內容。好比說一個用戶先收到了tweet，並進行回覆，然而這時候Lady Gaga的原微博並無擴散完畢，這樣就會存在有些用戶先看到回覆的狀況，爲用戶形成很大的困擾。Tweet經過ID進行排序，由於他們大多數是單調遞增的，然而在如此粉絲規模下，這種作法並不奏效。

7. 尋找讀和寫途徑的合併，再也不作如此大規模的擴散；好比傳播Taylor Swift新生成的tweet，取代在生成時進行擴散tweet ID，而是在讀取時候就進行合併。經過平衡讀寫途徑，節省百分之幾十的資源。

解耦相關

1. 基於Twitter經過各類途徑傳播tweet，解耦可讓不一樣技術團隊獨立完成本身的工做。

2. 基於性能問題，系統也須要解耦。Twitter過去使用的一直是徹底同步模式，而在兩年前由於性能問題他們停用了這個模式。設備接收一個tweet須要145毫秒，接收完畢後就斷開全部客戶端鏈接，這麼作一樣也由於技術負債。寫的路徑由Ruby驅動，經過MRI實現，一個單線程服務器，每次Unicorn worker分配都會耗盡全部處理性能。每當有tweet流入，Ruby就會接收它，將它放到一個隊列中而後斷開連接。他們在每臺服務器上只運行45-48個進程，這樣的話每一個機箱能同時處理的tweet數量也是這麼多，因此他們必須儘量快的斷開鏈接。

3. 當下的tweet已經經過異步模式來處理，而這些討論也都是創建在異步之上。

監視相關

1. 系統性能實時儀表盤

2. 使用VIZ系統監視每一個集羣，請求Timeline Service並從Scala集羣獲取數據的平均時間爲5毫秒。

3. 基於Google Dapper系統的Zipkin，工程師能夠經過Zipkin對請求的細節進行監視，好比獲取請求所訪問的服務及請求時間，這樣就能夠獲知每一個請求的性能細節。這樣就能夠經過每一個階段耗費的時間對系統進行調試，一樣也能夠從整體上看從請求到交付耗費的時間。花費了兩年的時間，Twitter將活躍用戶的timeline降到2毫秒。

部分統計數據：

 

• 若是你有100萬個粉絲，每一個tweet將耗費數秒的時間來傳播
• Tweet輸入統計：天天4億條；日平均統計5000每秒；日統計峯值7000每秒；大事件期間高於1.2萬每秒。
• Timeline交付統計：天天300億次（更多數據見原文）

 

原文連接： The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds  （編譯/仲浩 審校/周小璐）

歡迎關注 @CSDN雲計算微博，瞭解更多雲信息。 

本文爲CSDN編譯整理，未經容許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)