[發明專利]一種基于Redis的通信系統分布式方法

有效

• 申請號: 202010355894.1
• 申請日: 2020-04-29
• 公開（公告）號: CN111565229B
• 公開（公告）日: 2020-11-27
• 發明（設計）人: 王云龍;董世永
• 申請（專利權）人: 創盛視聯數碼科技（北京）有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08;H04L12/24
• 代理公司: 北京智沃律師事務所 11620
• 代理人: 吳志宏

本發明提供了一種基于Redis的通信系統分布式方法，客戶端通過Nginx集群與Gateway網關集群的網關層建立Websocket長連接；Gateway網關集群獲取消息處理器集群獲取節點列表，請求消息處理器建立連接；客戶端發送消息，將消息請求轉發到消息處理器，消息處理器向Redis發布消息；針對訂閱的客戶端，發布者Redis Stream結構會通過xadd創建對應的Consumer Group，然后其他客戶端通過xreadgroup以及ack機制保證消息被可靠消費。本發明通過將消息推送與訂閱服務整合，單獨形成消息處理器集群，通過Eureka注冊中心集群，對其各節點的健康狀態進行監控，集群部署，達到高可用、分布式集群部署的高效服務模式。

技術領域

本發明涉及一種基于Redis主題訂閱模式的消息系統，尤其是涉及一種基于Redis的通信系統分布式方法。

背景技術

如圖1所示，現有的聊天系統服務器架構，已經從很大程度上解決了傳統聊天系統單機部署的不足，達到高可用、動態擴展等。采用分層的思想，通過將消息流處理器單獨抽離，用于處理推拉消息流，組成單獨的中間件處理器集群，向Redis集群對應信道推送和訂閱消息，再對消息進行轉發到其他所有連接到此服務器的對應客戶端。

現有技術方案的不足：

現有的基于Redis Pub/Sub主題訂閱模式的聊天系統，仍然存在部分不足之處，以下進行分析。

1、數據的可靠性無法保證：

一個客戶端發布消息，n個客戶端接收消息。消息的發布是無狀態的，即發布完消息后該客戶端不在理會該消息是否被接收到，是否在傳輸過程中丟失，即對于發布者來說，消息是”即發即失”的。

2、擴展性太差以及數據丟失風險大：

不能通過增加消費者來加快消耗發布者的寫入的數據，如果發布者發布的消息很多，則數據阻塞在通道中等待被消費者來消耗。阻塞時間越久，數據丟失的風險越大(網絡或者服務器的一個不穩定就會導致數據的丟失)。

消費者需要獨占鏈接，在訂閱期間，redis-client無法穿插其他操作，此時client以阻塞的方式等待”pub端”的消息；而TCP默認的連接時間固定，如果在這段時間內sub端沒有接收到pub端的消息，或pub端沒有消息產生，sub端的連接會被強制回收；一旦sub端斷開鏈接，將會失去部分消息，即鏈接失效期間的消息將會丟失。

另外，redis的Pub/Sub消息模型是Fire and Forgot。也就是說Redis本身并不保存任何歷史消息，如果某個用戶的網絡連接出現異常，重新加入后，他是看不到斷鏈期間的聊天記錄的，新加入的用戶同樣也看不到最近一段時間的歷史記錄，這個對用戶迅速的理解當前討論的問題非常不便。此外，如果Redis發生了重啟，所有的用戶也需要重新訂閱頻道。

發明內容

本發明提供了一種基于Redis的通信系統分布式方法，解決了現有的基于RedisPub/Sub主題訂閱模式存在消息處理可靠性差、丟失風險大的問題，其技術方案如下所述：

一種基于Redis的通信系統分布式方法，所述通信系統包括與客戶端相連接的Nginx集群，Nginx集群的負載采用keepalived，所述Nginx集群與Gateway網關集群相連接，所述Gateway網關集群與消息處理器集群和Eureka注冊中心集群相連接，所述消息處理器集群與Redis集群和Sentinel集群分別相連接，通信系統的分布式處理包括以下步驟：

S1：消息處理器集群中所有可用的消息處理器節點向Eureka注冊中心進行注冊，Eureka注冊中心集群通過心跳探測，維護和消息處理器節點之間的通信；

S2：客戶端通過Nginx集群與Gateway網關集群的網關層建立Websocket長連接；