MQTT 5.0共享訂閱怎么理解

這篇文章主要介紹“MQTT 5.0共享訂閱怎么理解”，在日常操作中，相信很多人在MQTT 5.0共享訂閱怎么理解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MQTT 5.0共享訂閱怎么理解”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

前言

共享訂閱是 MQTT 5.0 協議引入的新特性，相當于是訂閱端的負載均衡功能。

我們知道一般的非共享訂閱的消息發布流程是這樣的：

在這種結構下，如果訂閱節點發生故障，就會導致發布者的消息丟失（QoS 0）或者堆積在 Server 中（QoS 1, 2）。一般情況下，解決這個問題的辦法都是直接增加訂閱節點，但這樣又產生了大量的重復消息，不僅浪費性能，在某些業務場景下，訂閱節點還需要自行去重，進一步增加了業務的復雜度。

其次，當發布者的生產能力較強時，可能會出現訂閱者的消費能力無法及時跟上的情況，此時只能由訂閱者自行實現負載均衡來解決，又一次增加了用戶的開發成本。

協議規范

現在，在 MQTT 5.0 協議中，你可以通過共享訂閱特性解決上面提到的問題。當你使用共享訂閱時，消息的流向就會變為：

同非共享訂閱一樣，共享訂閱包含一個主題過濾器和訂閱選項，唯一的區別在于共享訂閱的主題過濾器格式必須是 $share/{ShareName}/{filter} 這種形式。這幾個的字段的含義分別是：

• $share 前綴表明這將是一個共享訂閱

• {ShareName} 是一個不包含 "/", "+" 以及 "#" 的字符串。訂閱會話通過使用相同的 {ShareName} 表示共享同一個訂閱，匹配該訂閱的消息每次只會發布給其中一個會話

• {filter} 即非共享訂閱中的主題過濾器

需要注意的是，如果服務端正在向其選中的訂閱端發送 QoS 2 消息，并且在分發完成之前網絡中斷，服務端會在訂閱端重新連接時繼續完成該消息的分發。如果訂閱端的會話在其重連之前終止，服務!端將丟棄該消息而不嘗試發送給其他訂閱端。如果是 QoS 1 消息，服務端可以等訂閱端重新連接之后繼續完成分發，也可以在訂閱端斷開連接時就立即嘗試將消息分發給其他訂閱端，MQTT 協議沒有強制規定，因此需要視服務器的具體實現而定。但如果在等待訂閱端重連期間其會話終止，服務端則會將消息嘗試發送給其他訂閱端。

共享策略

雖然共享訂閱使得訂閱端能夠負載均衡地消費消息，但 MQTT 協議并沒有規定 Server 應當使用什么負載均衡策略。作為參考，EMQ X 提供了 random, round_robin, sticky, hash 四種策略供用戶自行選擇。

• random: 在所有共享訂閱會話中隨機選擇一個發送消息

• round_robin: 按照訂閱順序輪流選擇

• sticky: 使用 random 策略隨機選擇一個訂閱會話，持續使用至該會話取消訂閱或斷開連接再重復這一流程

• hash: 對發送者的 ClientID 進行 hash 操作，根據 hash 結果選擇訂閱會話

效果演示

最后，我們通過一個綜合性的示例來演示共享訂閱的效果。

服務端使用 emqx-v3.2.4，客戶端使用 emqtt，emqx 的共享訂閱分發策略為默認的 random：

broker.shared_subscription_strategy = random

使用 ./emqx start 啟動 emqx，然后使用 emqtt 啟動三個訂閱客戶端，分別訂閱 $share/a/topic, $share/a/topic, $share/b/topic

啟動一個發布客戶端，向 topic 主題發布消息。

$share/a/topic 與 $share/b/topic 屬于不同的會話組，非共享訂閱主題 topic 會在所有的會話組中進行負載均衡。客戶端 sub3 因為組內只有自己一個會話，所以收到了所有消息，而客戶端 sub1 與 sub2 則是遵循我們配置的 random 策略隨機接收消息。

到此，關于“MQTT 5.0共享訂閱怎么理解”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！