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大致的架構就說到這了，之後會寫其他模組細節以及最佳化和遇到的問題。