mqtt使用場景

MQTT（Message Queuing Telemetry Transport）是一種輕量級的消息傳輸協(xié)議，特別適用于資源受限的設(shè)備（內(nèi)存小）和網(wǎng)絡(luò)環(huán)境較差（低帶寬、降低網(wǎng)絡(luò)流量成本）的場景。適用于物聯(lián)網(wǎng)（IoT）設(shè)備之間的通信，常用于發(fā)布/訂閱模式的消息傳輸。

mqtt可能缺點

不適合大數(shù)據(jù)量傳輸、缺乏復雜的事務(wù)處理、消息順序不保證、依賴中間代理

mqtt學習疑問探索

1、mqtt主題發(fā)布過的歷史消息，全新連接的client能消費到嗎？

針對普通消息不能，只能消費新發(fā)布的普通消息；
保留消息（retained messages）例外，有些設(shè)備上線要知道最新的設(shè)備狀態(tài)等

2、mqtt的client掉線如何重連，重連后訂閱的topic配置還在不？

可以配置成自動連接或手動連接。
連接后，訂閱的topic配置不存在了，確實需要重新訂閱之前的主題

3、mqtt的client掉線重連后，如何保證掉線期間的消息能被消費到？

可以設(shè)置會話不被清空，會話清空的話，就消費不到掉線期間產(chǎn)生的消息了。
參考方法setCleanSession(true or false)

4、mqtt客戶端訂閱的消息能保證按序消費嗎？

得考慮是否支持QoS2配置、能否按序生產(chǎn)、能否按序消費

5、mqtt客戶端能訂閱自己發(fā)布的主題消息嗎？

可以

6、mqtt設(shè)置QoS=2還有必要在業(yè)務(wù)端判重嗎？

保守、嚴謹來說，業(yè)務(wù)側(cè)還是很有必要進行判重。
主要是因為消息消費后，在最后的確認機制未成功反饋結(jié)果時（極端情況下手動確認時，網(wǎng)絡(luò)異常、系統(tǒng)故障等），消息還是可能被重復進行消費

7、mqtt協(xié)議服務(wù)端支持的最大連接數(shù)？

具體看選擇的mqtt協(xié)議中間件類型、服務(wù)器配置、壓測等情況…

8、mqtt服務(wù)器控制臺？

看具體使用的mqtt協(xié)議中間件

9、mqtt中的普通消息、保留消息、遺囑消息區(qū)別？

保留消息可以在新客戶端訂閱時，推送；
遺囑消息是客戶端連接時指定的消息，可以在broker監(jiān)測離線時，推送告知給其他訂閱的客戶端

10、消息默認是否過期，能否設(shè)置過期時間？

發(fā)布后broker存儲，默認不過期，普通消費消費后自動刪；
可以設(shè)置過期時間，過期不消費會被清掉，不會再推送消費

11、支持延遲發(fā)布？

支持，即可提前發(fā)布消息在broker服務(wù)端留存，達到一定的延遲時間，再推送到訂閱的客戶端去消費

12、用戶屬性？

可以在發(fā)送消息時，指定用戶屬性（有點類似于設(shè)置http接口的請求頭參數(shù)）

13、共享訂閱？

mqtt5.0支持，即共享訂閱后，同一主題的多個客戶端可以負載均衡處理消息。
在普通的訂閱中，我們每發(fā)布一條消息，所有匹配的訂閱端都會收到該消息。當某個訂閱端的消費速度無法跟上消息的生產(chǎn)速度時，我們沒有辦法將其中一部分消息分流到其他訂閱端中來分擔壓力。這使訂閱端容易成為整個消息系統(tǒng)的性能瓶頸。

14、排它訂閱？

一個主題當前僅能存在一個訂閱者，在當前訂閱者未取消訂閱前，其他訂閱者都將無法訂閱該主題。

15、自動訂閱？

自動訂閱能夠給 EMQX 設(shè)置多個規(guī)則，在設(shè)備成功連接后按照規(guī)則為其訂閱指定主題，不需要額外發(fā)起訂閱。

16、主題通配符？

支持通配符規(guī)則設(shè)置，主要用于客戶端一次訂閱多個主題