Tumblr的訊息通知系統是如何構建的

2012·2彙總

tumblr是世界上最流行的輕部落格服務之一，2023年成立。

一，mysql+memcached

初期，其通知系統是由 mysql＋memcached 的傳統架構組成。

缺點：mysql負擔重，表象就是 mysql 併發事務數常常達到 innodb global transaction 最大值，即只能有1023個併發事務（注：特指 

mysql5.0/5.1存在的問題，5.5.4以上版本修復）。

二，tumblr 訊息系統應用特性

三，修改後的架構：staircar+redis

2023年，他們上線了如下架構：

staircar 的輕量級http伺服器+ redis 集群。

架構圖為：

四，效能指標要求

staircar 實際達到的指標：

在最高峰時的響應時間也在

5ms以下，其效能測試結果是能處理

每秒30,000次左右的請求。

五，引入 redis 的 presharding 思路

presharding。

缺點是，引入了運維複雜度，導致運維管理成本增加；要用好 presharing 方案，必須有相應的自動化運維手段相配套，比如：redis例項的啟停指令碼、能檢查redis狀態的運維監控手段。

優點是，更好的效能，更簡單的容錯，更能適應業務增長。

presharding 思路大致的描述為： 『

假設有n臺主機，每台主機上部署m個例項，整個系統有t = n × m個例項；

由於乙個redis例項的資源消耗非常小，所以一開始就可以部署比較多的 redis 例項，比如128個例項；

在前期業務量比較低的時候，n可以比較少，m比較多，而且主機的配置（cpu+記憶體）可以較低；

在後期業務量較大的時候，n可以較多，m變小。

總之，通過這種方法，在容量增長過程可以始終保持redis例項數(t)不變，所以避免了重新 sharding 的問題。 』

拆分過程如下：

在新機器上啟動好對應埠的 redis 例項。

配置新埠為待遷移埠的從庫。

待複製完成，與主庫完成同步後，切換所有客戶端配置到新的從庫的埠。

配置從庫為新的主庫。

移除老的埠例項。

重複上述過程遷移好所有的埠到指定伺服器上。

以上拆分流程是 redis 作者提出的乙個平滑遷移的過程，不過該拆分方法還是很依賴 redis 本身的複製功能的，如果主庫快照資料檔案過大，這個複製的過程也會很久，同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。

六，一些細節

來自於 tumblr 開發者的一些資訊：

參考資源：

1）2011，tumblr官方部落格，

staircar: redis-powered notifications；

2）上文的

中文譯稿；

3）2011，antirez，

redis presharding ；

4）2011，infoq，

redis複製與可擴充套件集群搭建，談及一種基於mysql作為主庫，redis作為高速資料查詢從庫的異構讀寫分離的方案：

贈圖一枚：

Tumblr的訊息通知系統是如何構建的

2012 2彙總 tumblr是世界上最流行的輕部落格服務之一，2007年成立。一，mysql memcached 初期，其通知系統是由 mysql memcached 的傳統架構組成。缺點 mysql負擔重，表象就是 mysql 併發事務數常常達到 innodb global transactio...

Redis訊息通知系統的實現

posted on 2012 02 29 by 老王 最近忙著用redis實現乙個訊息通知系統，今天大概總結了一下技術細節，其中演示 如果沒有特殊說明，使用的都是phpredis擴充套件來實現的。比如要推送一條全域性訊息，如果真的給所有使用者都推送一遍的話，那麼會占用很大的記憶體，實際上不管粘性有多...

Redis訊息通知系統的實現

最近忙著用redis實現乙個訊息通知系統，今天大概總結了一下技術細節，其中演示 如果沒有特殊說明，使用的都是phpredis擴充套件來實現的。比如要推送一條全域性訊息，如果真的給所有使用者都推送一遍的話，那麼會占用很大的記憶體，實際上不管粘性有多高的產品，活躍使用者同全部使用者比起來，都會小很多，所...