MQTT 5.0的Inflight Window與Message Queue是什么

本篇內容介紹了“ MQTT 5.0的Inflight Window與Message Queue是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Inflight Window 與 Message Queue 說明

為了提高消息吞吐效率和減少網絡波動帶來的影響，EMQ X 消息服務器允許多個未確認的 QoS 1 和 QoS 2 報文同時存在于網路鏈路上。這些已發(fā)送但未確認的報文將被存放在 inflight Window 中直至完成確認。

當網絡鏈路中同時存在的報文超出限制，即 Inflight Window 到達長度限制（見 max_inflight）時，EMQ X 消息服務器將不再發(fā)送后續(xù)的報文，而是將這些報文存儲在 Message Queue 中。一旦 Inflight Window 中有報文完成確認，Message Queue 中的報文就會以先入先出的順序被發(fā)送，同時存儲到 Inflight Window 中。

當客戶端離線時，Message Queue 還會被用來存儲 QoS 0 消息，這些消息將在客戶端下次上線時被發(fā)送。這功能默認開啟，當然你也可以手動關閉，見 mqueue_store_qos0。

需要注意的是，如果 Message Queue 也到達了長度限制，后續(xù)的報文將依然緩存到 Message Queue，但相應的 Message Queue 中最先緩存的消息將被丟棄。如果隊列中存在 QoS 0 消息，那么將優(yōu)先丟棄 QoS 0 消息。因此，根據(jù)你的實際情況配置一個合適的 Message Queue 長度限制（見 max_mqueue_len）是非常重要的。

Inflight Window 與 Receive Maximum

MQTT v5.0 協(xié)議為 CONNECT 報文新增了一個 Receive Maximum 的屬性，官方對它的解釋是：客戶端使用此值限制客戶端愿意同時處理的 QoS 為 1 和 QoS 為 2 的發(fā)布消息最大數(shù)量。沒有機制可以限制服務端試圖發(fā)送的 QoS 為 0 的發(fā)布消息。也就是說，服務端可以在等待確認時使用不同的報文標識符向客戶端發(fā)送后續(xù)的 PUBLISH 報文，直到未被確認的報文數(shù)量到達 Receive Maximum 限制。

不難看出，Receive Maximum 其實與 EMQ X 消息服務器中的 Inflight Window 機制如出一轍，只是在 MQTT v5.0 協(xié)議發(fā)布前，EMQ X 就已經對接入的 MQTT 客戶端提供了這一功能?，F(xiàn)在，使用 MQTT v5.0 協(xié)議的客戶端將按照 Receive Maximum 的規(guī)范來設置 Inflight Window 的最大長度，而更低版本 MQTT 協(xié)議的客戶端則依然按照配置來設置。

配置項

“ MQTT 5.0的Inflight Window與Message Queue是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！