[發明專利]一種基于MQTT消息協議的集中器應用進程看護設計方法

在審

• 申請號: 202310177598.0
• 申請日: 2023-02-28
• 公開（公告）號: CN116126597A
• 公開（公告）日: 2023-05-16
• 發明（設計）人: 葛玉磊;孫彥鵬;沈海洋;李玉寧;趙璽
• 申請（專利權）人: 青島鼎信通訊股份有限公司;青島鼎信通訊科技有限公司
• 主分類號: G06F11/14
• 分類號: G06F11/14;G06F11/34
• 代理公司: 暫無信息
• 代理人: 暫無信息

1.一種基于MQTT消息協議的集中器應用進程看護設計方法，包括以下步驟：

步驟1：基于MQTT的消息框架，啟動一個MQTT?broker，看護程序app1與各集中器主要業務app作為客戶端連接至該broker，創建一個MQTT?；罹€程用來監測各app與MQTT?broker的連接情況；

步驟2：由看護程序app1定時向主要的業務app發送消息，各業務app通過訂閱收到消息后進行確認信息的回復，心跳消息中攜帶app的信息及系統時間；

步驟3：根據各業務app回復消息中攜帶的app信息構建Markov鏈模型，對業務app未來運行狀況進行預測，對于可能出現異常的狀況及時向主站發出告警信息；

步驟4：若業務app未在規定時間內向MQTT?broker發送回復包，此時看護程序app1仍繼續按照周期向MQTT?broker發布相應主題的消息信息并自動開啟報文監控，將交互的MQTT消息報文日志儲存在集中器的儲存單元；

步驟5：如果連續超過給定周期后該業務app仍未進行消息回復，則認為該app出現異常，需要嘗試重啟該app，由看護程序app1執行異常應用異常后的拉起操作；

步驟6：重啟后的app向服務端發起重連，則Broker會啟動客戶端接管機制：關閉舊的半連接，然后與該業務app建立新的連接。

2.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟1中的啟動一個MQTT?broker為在集中器中安裝mosquitto應用，啟動Mosquitto服務器，測試服務器訂閱與發布，確保mosquitto正確運行。

3.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟1中集中器主要業務app為集中器主要的功能app，包括交采app、負荷辨識app、回路狀態巡檢app、拓撲識別app、遙信app。

4.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟2中，看護程序app1每30秒向主要業務app發送消息，30秒為保活的心跳時間。

5.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟2中，各業務app回復的心跳消息中攜帶的系統信息應包括應用序號、應用名稱、容器名稱、應用版本、應用哈希值和應用服務數量及信息；應用服務的信息包括服務索引、服務名稱、服務是否使能、服務狀態、CPU使用率限值、CPU實際使用率、內存實際使用率及啟動時間。

6.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟3中，將業務app回復的CPU實際使用率看做狀態，則app運行狀態的Markov鏈模型λ＝(Ф，π，P)，其中：Ф＝{C1,C2,C2…Cn}表示狀態集合；π為初始狀態分布；表示狀態轉移矩陣，元素表示系統在t時刻處于狀態C_i，t+1時刻處于狀態C_j的概率。

7.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟3中，通過計算每個狀態C_j在C_i下的條件概率得到狀態矩陣，即其中表示集中器CPU占用率為C_i和C_j相鄰出現的次數，為狀態C_i出現次數。

8.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟3中，根據Markov鏈模型計算出概率該概率值越大，說明當前app運行越穩定；反之，運行出現異常的可能性越大。

9.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟3中的規定時間為保活心跳時間的1.5倍加上定時檢測的等待時間。

10.根據權利要求1所述的一種基于MQTT消息協議的集中器應用進程看護設計方法，其特征在于，所述步驟4中超過的給定周期為連接的?；顣r間，取值范圍為30秒到1200秒，本方法中設定為300秒，即連續10個周期時間。