之前在網上看到關於Twitter、Sina以及騰訊微薄的一些實現技術，這個簡單做個摘要。

1、讀擴散還是寫擴散？

inbox: 收件箱，你收到的訊息，即你所關注的人釋出的訊息。
outbox: 發件箱，你釋出的訊息。

寫擴散(Push)

該方式為每個使用者維護一個訂閱列表，記錄該使用者訂閱的訊息索引（一般為訊息ID、型別、發表時間等一些元資料）。每當使用者釋出訊息時，都會去更新其follower的訂閱列表。
優點：讀很輕。初始化時僅需要讀取自己的inbox即可。
缺點：寫很重。每釋出一個訊息，會導致大量的寫操作。
注：一般來說，使用者釋出訊息，並不會更新所有followers的訂閱列表，僅更新線上followers即可。

讀擴散(Pull)

該方式為每個使用者維護一個傳送列表，記錄該使用者所有發表過的訊息索引。
優點：寫很輕，節省空間。使用者每釋出一條訊息，僅需更新自己的outbox。
缺點：讀操作很重，計算量大。假設你收聽了1k使用者，則初始化時，需要從1k個使用者的outbox拉取訊息，然後計算獲得最新的n條訊息。

混合模式(Push+Pull)

該方式既為讀寫擴散的結合，根據使用者followers的數量來決定是讀擴散還是寫擴散。例如followers大於1k的，則使用讀擴散，否則使用寫擴散。

從目前現在網上的一些資料來看，Twitter是寫擴散，騰訊微薄是讀擴散，新浪微薄則是二者結合。

2、關於Cache

對於一個千萬級甚至億級使用者的大型網站來說，合理使用Cache至關重要。

一個使用者的核心資料由如下幾個部分組成：inbox，outbox，關係鏈，訊息內容。

• inbox：主要快取訊息索引，僅為線上使用者快取，從Timyang的PPT來看，新浪微薄估計是使用redis的list或set實現。
• outbox：快取一定數量（例如200）條最近發表的訊息。
• 關係鏈：following相對於followers來說，快取容易些，follower載入開銷比較大，例如劉翔在騰訊微薄的聽眾超過1600萬。
• 訊息內容：按內容年齡快取；一般需要多份支援容災；需要快取xml，json，rss，atom等多種格式的快取以供API使用。

以Twitter為例，其將Cache分為四類：Vector Cache，Row Cache，Page Cache，Fragment Cache，均使用memcached實現。其中：

• Vector Cache主要快取使用者的inbox以及outbox索引，其命中率高達99%；
• Row Cache主要快取使用者關係鏈資料，以及Tweets內容，命中率為95%；
• Fragment Cache快取Tweet的xml，json，rss，atom四種格式資料，以供API使用，命中率為95%；
• Page Cache主要原來快取那些高人氣使用者的個人主頁，命中率僅為40%。

下圖為TwitterCache架構圖：

Twitter為啥要為API通道設定Fragment Cache和Page Cahce呢？其原因是Twitter的80%流量來自API。

下面以新浪微薄介紹一下Cache流程：

訊息釋出流程：

1. 更新自己的outbox
2. 載入followers列表
3. 更新followers inbox

獲取首頁流程：

1. 檢查inbox cache是否可用
2. 獲取關注列表
3. 聚合內容，獲得訊息索引
4. 根據索引，返回最終聚合的訊息內容

3、關於儲存

目前Twitter和新浪的落地儲存，都是使用MySQL。而騰訊微薄則使用採用SSD+大檔案儲存（每次寫操作都是append操作，寫操作可以先用記憶體快取，達到適當大小合併，儘量減少隨機寫）。其他細節因不清楚或不方便透露，不做細述。

4、關於洪峰處理。

一般用非同步佇列處理方式。訊息佇列產品有：Kestrel（twitter使用Scala實現），RabbitMQ（使用Erlang實現），MemcacheQ。

Twitter 09年時，使用者的平均followers數量為126個。按照每秒400訊息釋出數算，那每秒就需要推送126*400=50400條訊息出去。為了削 峰，Twitter自己用Scala實現了一個分散式訊息佇列Kestrel，其程式碼僅為1200行，執行在3臺機器上，其使用memcached協議， 其Server之間無共享狀態，且全記憶體。新浪使用的是MemcacheQ。

原文地址：http://blog.163.com/[email protected]/blog/static/1322296552013430114959121/