MQTT 5.0 特性 | 保留消息

前言

發佈訂閱模式雖然讓消息的發佈者與訂閱者充分解耦，但也出現了一個隱含的問題，即訂閱者沒法主動向發佈者請求消息，訂閱者什麼時候收到消息徹底依賴於發佈者什麼時候發佈消息，這在某些場景中就產生了不便。例如，某設備按期發佈自身 GPS 座標，但對於訂閱者而言，從它發起訂閱到第一次收到數據可能須要幾秒鐘，也可能須要十幾分鍾甚至更多，這樣並不友好。所以 MQTT 引入了保留消息。

保留消息

當服務端收到 Retain 標誌爲 1 的 PUBLISH 報文時，它將進行如下操做：

1. 若是存在匹配此主題名的訂閱者，則按正常邏輯進行轉發，並在轉發前清除 Retain 標誌。MQTT v3.1.1 協議中 Retain 標誌必須被清除，而 MQTT v5.0 協議則在訂閱選項中新增了一個 Retain As Publish 字段，由客戶端自行指示服務端在轉發前是否須要清除 Retain 標誌。
2. 若是 Payload 非空，存儲此應用消息，若是此主題名下已經存在保留消息則進行替換。若是 Payload 爲空，服務端不會存儲此應用消息，同時清除此主題名下已經存在的保留消息。

而每當有訂閱者創建訂閱時，服務端就會查找是否存在匹配該訂閱的保留消息，若是保留消息存在，就會當即轉發給訂閱者。當保留消息在這種狀況下被轉發給訂閱者時，它的 Retain 標誌必須保持爲 1。相比 MQTT v3.1.1，MQTT v5.0 對於訂閱創建時是否發送保留消息作了更細緻的劃分，並在訂閱選項中提供了 Retain Handling 字段。例如某些客戶端可能僅但願在首次訂閱時接收保留消息，又或者不但願在訂閱創建時接收保留消息，均可以經過 Retain Handling 選項調整。

保留消息雖然存儲在服務端中，但它並不屬於會話的一部分。也就是說，即使發佈這個保留消息的會話終結，保留消息也不會被刪除。刪除保留消息只有兩種方式：

1. 前文已經提到過的，客戶端往某個主題發送一個 Payload 爲空的保留消息，服務端就會刪除這個主題下的保留消息。
2. 消息過時間隔屬性在保留消息中一樣適用，若是客戶端設置了這一屬性，那麼保留消息在服務端存儲超過過時時間後就會被刪除。

藉助保留消息，新的訂閱者可以當即獲取最近的狀態，而不須要等待沒法預期的時間，這在不少場景下很很是重要的。

---

更多信息請訪問咱們的官網 emqx.io，或關注咱們的開源項目 github.com/emqx/emqx ，詳細文檔請訪問 官方文檔。