[發明專利]分布式消息廣播通知實現方法

有效

• 申請號: 201911152452.0
• 申請日: 2019-11-22
• 公開（公告）號: CN110932874B
• 公開（公告）日: 2022-08-16
• 發明（設計）人: 楊帆;張東冬;師銘
• 申請（專利權）人: 南京甄視智能科技有限公司
• 主分類號: H04L12/18
• 分類號: H04L12/18;H04L67/1042;H04L1/18
• 代理公司: 南京行高知識產權代理有限公司 32404
• 代理人: 王培松

本發明提供一種分布式消息廣播通知實現方法，包括以下步驟：加入集群中的節點請求消息中心訂閱公共主題；節點再次請求消息中心訂閱屬于每個節點的私有主題；消息發送者在發送消息前請求消息中心，獲取當前訂閱公共主題的客戶端數量，請求數據中心發送到公共主題；消息發送者將消息體發送后，等待來自私有主題上的消息，其中等待到至少M條消息，如果在指定時間內未等到預期數量的消息，判定為執行超時；集群內的節點接收到來自公共主題的消息后，根據消息中的標識信息以發出響應或者不做響應。本發明基于長連接的通信，并且解耦節點與節點間的依賴，可實現節點上下線狀態可以快速被消息中心感知到，不影響消息到達。

技術領域

本發明涉及消息廣播與處理領域，具體而言涉及一種分布式消息廣播通知實現方法。

背景技術

在應用開發過程中，經常會遇到向集群內的其他節點或者服務發送消息通知，并且需要同步等待接收方處理結果的業務需求，例如節點本地某個人員信息的緩存，當在另一個節點刪除該人員時需要通知其他節點刪除本地緩存。

目前，針對此類業務需求，在一些實施方式中，主要通過注冊中心獲取到集群內的所有節點，然后進行遍歷定向通知，通知方式有HTTP、RPC(如dubbo)協議，如圖1所示，其流程如下：節點加入集群后，向注冊中心發起請求，將節點注冊到注冊中心；節點定時向注冊中心發起心跳請求，匯報在線狀態；節點需要發起廣播通知時，需要從注冊中心拉取當前在線的所有節點信息；遍歷所有在線的節點，發起通知，例如請求其他的http接口；等待所有節點通知完畢，完成本次消息廣播通知。

但我們現有技術的消息通知實現過程來看，以上通知方式屬于短連接方案，建立連接的成本較高，效率較低；而且節點之間會直接產生依賴，如果節點數量較多，通信成本會大幅提高；同時還存在注冊中心對節點的上線和下線感知存在延遲，導致節點實際上線后，可能不能立刻收到通知消息的缺陷，因此需要降低因為注冊中心感知節點狀態的延遲，導致消息不能有效到達節點的概率。

發明內容

本發明目的在于提供使用長連接通信并降低節點與節點之間通信成本和依賴的分布式消息廣播通知實現方法，包括：

步驟1、加入集群中的節點請求消息中心訂閱公共主題；

步驟2、節點再次請求消息中心訂閱屬于每個節點的私有主題；

步驟3、消息發送者在發送消息前請求消息中心，獲取當前訂閱公共主題的客戶端數量，記為client_count，如果訂閱公共主題的客戶端數量小于或等于1，則取消發送消息；如果訂閱公共主題的客戶端數量大于1，則由消息發送者組裝消息體，包含消息內容和發送者標識，請求數據中心發送到公共主題；

步驟4、消息發送者將消息體發送后，等待來自私有主題上的消息，其中等待到至少M條消息，其中M＝client_count-1，如果在指定時間內未等到預期數量的消息，判定為執行超時；

步驟5、集群內的節點接收到來自公共主題的消息后，根據消息中的標識信息以發出響應或者不做響應。

進一步地，在所述步驟5中，接收到來自公共主體的消息的節點首先根據消息體中發送者標識判斷消息是否來自于自身，如果是，則不做處理，如果發送消息來自于其他節點，對消息處理后，根據發送者標識，向對應的發送者私有主題發送響應消息。

進一步地，在所述步驟4中，如果執行超時，則重發消息或者結束消息發送流程。

應當理解，前述構思以及在下面更加詳細地描述的額外構思的所有組合只要在這樣的構思不相互矛盾的情況下都可以被視為本公開的發明主題的一部分。另外，所要求保護的主題的所有組合都被視為本公開的發明主題的一部分。

結合附圖從下面的描述中可以更加全面地理解本發明教導的前述和其他方面、實施例和特征。本發明的其他附加方面例如示例性實施方式的特征和/或有益效果將在下面的描述中顯見，或通過根據本發明教導的具體實施方式的實踐中得知。