gopush-cluster 架構

前言

gopush-cluster是一套golang開發的實時消息推送集羣，主要分享一下開發這套系統的想法和思路。

架構

主要分爲三個模塊來開發，comet/web/message。

comet

主要負責消息排隊、消息推送以及和客戶端的鏈接維護；整套系統依據是消息ID順序原則獲取消息（客戶端本地獲取最大的消息是1，那麼以後獲取的消息就是大於1的，獲取離線消息的時候也要從上次最大消息ID來獲取），所以消息推送之後須要在comet中排隊而後發起RPC給message實現存儲。

message 

主要負責消息的存儲和讀寫；接受來自comet模塊的消息進行持久化，或者接受web模塊的讀取消息請求獲取離線消息。message是能夠部署多個節點來負載來自大量comet的推送壓力，好比不一樣的comet使用不一樣的message節點（節點無狀態），以後在comet也會作多message節點的負載均衡RPC調用和故障轉移（TODO）。

web

主要負責節點詢問，以及離線消息獲取和後臺節點管理等；節點詢問主要依據客戶端的訂閱Key一致性hash計算出鏈接的comet節點地址，所以海量客戶端鏈接的時候能夠打散到多個comet來服務；另外離線消息也是經過web接口返回給客戶端的，可是消息的讀取是經過RPC發送給message模塊的，儘可能的職責單一。web節點由於無狀態，能夠部署多個web，來實現負載均衡和故障轉移。

thrid-part

消息存儲如今主要依賴Redis進行消息讀寫（Sorted Set），由於Sorted Set不支持int64類型的Score（咱們也開發了一個支持int64 Score的分支可是由於時間緣由沒有大量測試上線），以後可能會使用HBase集羣代替Redis的使用，已提供更安全的離線消息存儲（TODO）。

另外使用了Zookeeper來實現的同一個comet的故障轉移，例如comet 節點1能夠有一個備選節點節點2，當節點1註冊到zookeeper以後，由於機器或者其餘緣由宕了，這時候會在web層觸發zookeeper的選舉選中節點2來服務。

結束語

gopush-cluster大體的架構就說到這了，以後會寫其餘模塊細節以及優化和遇到的問題。