[發明專利]一種基于redis的分布式消息通信方法在審
| 申請號: | 202010825774.3 | 申請日: | 2020-08-17 |
| 公開(公告)號: | CN112671819A | 公開(公告)日: | 2021-04-16 |
| 發明(設計)人: | 劉永 | 申請(專利權)人: | 紫光云技術有限公司 |
| 主分類號: | H04L29/08 | 分類號: | H04L29/08 |
| 代理公司: | 天津濱海科緯知識產權代理有限公司 12211 | 代理人: | 劉瑩 |
| 地址: | 300459 天津市濱海新區*** | 國省代碼: | 天津;12 |
| 權利要求書: | 查看更多 | 說明書: | 查看更多 |
| 摘要: | |||
| 搜索關鍵詞: | 一種 基于 redis 分布式 消息 通信 方法 | ||
本發明提供了一種基于redis的分布式消息通信方法,包括agent消息隊列創建選擇方法,所述agent消息隊列創建選擇方法包括:S1、Agent啟動之后查看是否持有代表一個消息隊列的名稱值,如果不存在,執行步驟S2;如果存在執行步驟S6;S2、獲取分布式鎖;S3、檢查配置在環境變量中的消息隊列名稱列表,查看redis中是否已經存在了此消息隊列,如果不存在,則執行步驟S4;否則,釋放鎖執行步驟S1。本發明所述的一種基于redis的分布式消息通信方法能夠保證存在依賴關系的消息順序的到達設備,且不存在單點故障問題,提高了集群的可靠性,并且由于將消息分布在不同的消息隊列中也提高了消息的處理能力。
技術領域
本發明屬于redis消息通信方法領域,尤其是涉及一種基于redis的分布式消息通信方法。
背景技術
當前現狀,agent作為與設備交互的端點,在集群環境下由于要保證消息的順序性,故僅有一個agent服務程序運行,現有技術的agent服務存在單點問題,并且消息沒有持久化,一旦agent服務異常,將導致消息丟失和業務不可用,可靠性得不到保證。
發明內容
有鑒于此,本發明旨在提出一種基于redis的分布式消息通信方法,通過redis實現消息傳遞機制,啟動多個agent保證服務多活,且能夠保證消息的順序可靠到達。
為達到上述目的,本發明的技術方案是這樣實現的:
一種基于redis的分布式消息通信方法,包括agent消息隊列創建選擇方法,所述agent消息隊列創建選擇方法包括:
S1、Agent啟動之后查看是否持有代表一個消息隊列的名稱值,如果不存在,執行步驟S2;如果存在執行步驟S6;
S2、獲取分布式鎖;
S3、檢查配置在環境變量中的消息隊列名稱列表,查看redis中是否已經存在了此消息隊列,如果不存在,則執行步驟S4;否則,釋放鎖執行步驟S1;
S4、創建消息隊列并向消息隊列中寫入KEY_A字段,設置KEY_A字段的值為一個隨機數,Agent持有此隨機數,并設置這個KEY_A自動在N秒后超時則釋放鎖,執行步驟S5;
S5、循環獲取消息隊列A中的消息,并處理消息發送到設備;
S6、持有的KEY_A字段中的隨機數與Agent中記錄的隨機數不一致,則執行步驟S2重新獲取消息隊列,否則,重置KEY_A,執行步驟S5繼續處理消息;
S7、使用Kubernetes服務探針,每N-N/2秒發送一次重置KEY_A的消息,保證Agent只要存活就能持有消息隊列A。
進一步的,步驟S2中獲取分布式鎖用于保證獲取消息隊列或者創建消息隊列的過程在多個agent間是互斥的。
進一步的,步驟S6中持有的KEY_A字段中的隨機數與Agent中記錄的隨機數不一致,表明此Agent已經沒有此KEY_A所代表的Agent的消息隊列A。
進一步的,步驟S7中使用Kubernetes服務探針,用于解決在Agent處理消息時間過長導致KEY_A超時丟失,導致其他Agent獲取消息隊列A的權限的問題。
進一步的,步驟S7中使用Kubernetes服務探針,每N-N/2秒發送一次重置KEY_A的消息,還用于保證Agent只要存活就能持有消息隊列A。
相對于現有技術,本發明所述的一種基于redis的分布式消息通信方法具有以下優勢:
本發明所述的一種基于redis的分布式消息通信方法能夠保證存在依賴關系的消息順序的到達設備,且不存在單點故障問題,提高了集群的可靠性,并且由于將消息分布在不同的消息隊列中也提高了消息的處理能力。
附圖說明
該專利技術資料僅供研究查看技術是否侵權等信息,商用須獲得專利權人授權。該專利全部權利屬于紫光云技術有限公司,未經紫光云技術有限公司許可,擅自商用是侵權行為。如果您想購買此專利、獲得商業授權和技術合作,請聯系【客服】
本文鏈接:http://www.szxzyx.cn/pat/books/202010825774.3/2.html,轉載請聲明來源鉆瓜專利網。





