• 單播:服務器發送消息給單個客戶端用戶

• 多播:服務器發送消息給多個客戶端用戶

• 組播/廣播:服務器發送消息給一組客戶端。有組ID來標識這組用戶

• 上行消息:服務器發送消息給一組客戶端。有組ID來標識這組用戶

• 下行消息:服務器端給客戶端發送消息

二、系統架構

• proxy:部署在邊緣機房，客戶端通過智能dns就近接入

• logicService：處理認證、心跳、上下線、進出群

• pushService:單播，廣播，接收到消息后轉發給comet，之后再由comet把消息發出去

• imService:聊天服務器，處理單聊群聊，離線消息

• cosumerService:對群消息進行異步寫擴散

• authService:認證服務

數據結構

• user_id 是業務指定的，唯一標識一個用戶

• conn_id 由存儲進程分配，唯一標識該用戶的一條連接

• server_id 標識這條連接屬于哪個接入進程

• Connection 是客戶端連接的封裝，可以向它推送消息

三、消息模型

3.1 讀擴散模型

• 優點：只寫一次，降低了寫入次數，特別在群模式下

• 缺點: 同步消息的邏輯會比較復雜，接收端每個會話都要讀取一次，放大了讀，會產生很多無效請求。

3.2 寫擴散模型

• 優點：拉取消息的邏輯簡單

• 缺點: 放大了寫，單聊要額外寫兩次，群里要寫N次

四、實現方式

4.1 單聊

4.1.1 設計目標

4.1.2 在線消息

4.1.3 離線消息

4.1.4 檢測消息丟失

4.2 群聊

4.2.1 設計目標

4.2.2 小群(寫擴散)

4.2.3 大群(讀擴散)

五、高性能分析

5.1 容量規劃：（阿里云主機16C32G-2.5GHz，預留50%余量）

• 10,000 conn per proxy

• 100 proxy

• 50 logicService/cacheService/pushService

• or 改進：

• 10 logicService

• 5 pushService

• kafka cluster

• zookeeper cluster

• 10 cacheService

5.2內部通信無瓶頸，可水平擴容的路徑有：

• 客戶端發起的RPC mobile -> proxy -> micro

• 上線/下線/切換房間/心跳 mobile -> proxy -> logicService -> cacheService

• 單播 micro -> logicService (-> cacheService) -> pushService -> proxy -> mobile

• 在線信息查詢

• 按用戶查在線查房間 /session

5.3 內部通信，可能有瓶頸的路徑：

• 批量單播 micro -> logicService ((N-parallel)-> router) -> pushService -> proxy -> mobile

• 限制：一批用戶總數，不宜過多

• 廣播 micro -> logicService -> pushService -> proxy -> mobile

• 限制：由于pushService定期absorb proxy上的room list, so pushService數量不可過多

• 改進：logicService和pushService解耦，用kafka連接。由于 pushService 對 CPU 的消耗在 proxy/logicService/cacheService 中最少，只需要非常少的 pushService 實例就行。

• 在線信息查詢

• 查在線總數 /count 由于logicService定期absorb cacheService上的room users，只能是有限的logicService打開counter定時查

• 按房間查用戶 /room 同 /count

• 遍歷 /list 調試用接口，別用于服務

5.4 proxy性能瓶頸

5.5 rpc性能瓶頸

六、高可用分析

• proxy 無狀態服務，重啟、升級時，客戶端檢測到連接斷開，自動重連到另一個 proxy

• logicService 無狀態服務，重啟、升級時，proxy 會自動尋找下一個 logic

• pushService 無狀態服務，重啟、升級時，有其它 pushService對外提供服務

• cacheService 有狀態服務，重啟、升級時，由備 cacheService 頂上；升級完成，切回主 cacheService

• imService 無狀態服務，重啟、升級時，有其它 pushService對外提供服務

• mysql：使用mysql master master機制來保證

• redis: 使用哨兵機制來保證可用性

七、異常情況處理

• 如何防止消息丟失(接收端上報已接收的最大消息id,異常服務端重發)

• redis主從切換引起自增id不連續

• 怎么提高proxy廣播的性能

• 怎么避免rpc的單條連接成為瓶頸

八、低成本、安全

• 幾乎沒有外部依賴，極低的運維成本

• 高性能的代碼實現，節省服務器成本

• 集成認證鑒權，也支持 HTTPS