gopush-cluster 架構

主要分爲三個模塊來開發，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大致的架構就說到這了，之後會寫其他模塊細節以及優化和遇到的問題。