## 引言：原生 MQTT 會話持久化支援

MQTT 協議標準中規定 Broker 必須儲存離線客戶端的訊息。在之前的版本中，[EMQX 開源版](https://www.emqx.io/zh)採用了基於記憶體的會話儲存，企業版則在此基礎上進一步提供了外部資料庫儲存方案，藉此實現資料持久化。

這種基於記憶體、非持久化的會話儲存方式雖然是基於吞吐量和延遲之間相互權衡下的最優解，但在某些場景下仍會給使用者使用帶來一定的限制。

本著關注社群反饋、不斷完善為使用者帶來更易用產品的理念，我們在 EMQX 5.x 的產品規劃中增加了基於 RocksDB 的原生 MQTT 會話持久化支援。目前這一功能已進入正式開發階段，預計將在 5.1.0 版本中和各位使用者見面。

本文是對這一特性的搶鮮技術分享。透過對 [MQTT 會話](https://www.emqx.com/zh/blog/mqtt-session)相關概念以及 EMQX 會話持久化功能設計原理的介紹，幫助讀者瞭解這一更加高可靠、低時延的資料持久化方案。同時，我們還將基於 RocksDB 持久化能力進行更多新功能探索。

## 瞭解 MQTT 會話

在協議規範中，QoS 1 和 QoS 2 訊息首先會在客戶端與 Broker 儲存起來，在最終確認抵達訂閱端後才會被刪除，此過程需要 Broker 將狀態與客戶端相關聯，這稱為會話狀態。除了訊息儲存外，訂閱資訊（客戶端訂閱的主題列表）也是會話狀態的一部分。

[![QoS 1 訊息流程示意圖](http://img.blog.itpub.net/blog/2022/08/08/dd3b1b821827b252.png?x-oss-process=style/bb "QoS 1 訊息流程示意圖")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "QoS 1 訊息流程示意圖")

[![QoS 2 訊息流程示意圖](http://img.blog.itpub.net/blog/2022/08/08/2ed02fd65e0d79e2.png?x-oss-process=style/bb "QoS 2 訊息流程示意圖")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "QoS 2 訊息流程示意圖")

> 關於 QoS 的更多資訊可參考 [MQTT QoS（服務質量）介紹](https://www.emqx.com/zh/blog/introduction-to-mqtt-qos)。

客戶端中的會話狀態包括：

- 已傳送到伺服器，但尚未完全確認的 QoS 1 和 QoS 2 訊息
- 已從伺服器收到但尚未完全確認的 QoS 2 訊息

伺服器中的會話狀態包括：

- 會話的存在狀態，即使會話為空
- 客戶訂閱資訊
- 已傳送到客戶端，但尚未完全確認的 QoS 1 和 QoS 2 訊息
- 等待傳輸到客戶端的 QoS 0（可選）、QoS 1 和 QoS 2 訊息
- 已從客戶端收到但尚未完全確認的 QoS 2 訊息，Will Message（遺囑訊息）和 Will Delay Interval（遺囑延時間隔）

### 會話生命週期與會話儲存

會話是 MQTT 協議通訊的關鍵，MQTT 協議要求網路連線開啟時**必須保留**會話狀態；當網路連線關閉後，則根據 Clean Session（MQTT 3.1.1）以及 Clean Start + 會話過期間隔（MQTT 5.0）的設定情況控制實際的丟棄時機。

[![MQTT Clean Session](http://img.blog.itpub.net/blog/2022/08/08/81b03eb1a74a7b73.jpeg?x-oss-process=style/bb "MQTT Clean Session")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "MQTT Clean Session")

[![MQTT Session Expiry Interval](http://img.blog.itpub.net/blog/2022/08/08/7821cf095431bf31.png?x-oss-process=style/bb "MQTT Session Expiry Interval")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "MQTT Session Expiry Interval")

本文不再贅述不同機制下會話生命週期差異，相關內容可以參考文章 [Clean Start 與 Session Expiry Interval - MQTT 5.0 新特性](https://www.emqx.com/zh/blog/mqtt5-new-feature-clean-start-and-session-expiry-interval)。

總而言之，當 Broker 中存在會話的時候，訊息將持續進入會話，當會話對應的客戶端斷開連線或不具備訊息處理能力時，訊息將在會話中堆積。

MQTT 協議並未規定會話永續性上的實現，這意味著客戶端和 Broker 可以根據場景需求和自身設計，選擇將其儲存在記憶體或磁碟中。

## 過往版本的 EMQX 會話持久化設計

在此前的版本中，EMQX 並未支援 Broker 內部訊息持久化，這是吞吐量和延遲之間的權衡以及架構設計選擇：

1. EMQX 解決的核心問題是連線與路由，極少情況下需要將訊息持久儲存，而保留訊息作為一種特例是支援儲存在磁碟的。
2. EMQX 作為雲端服務，這類環境下伺服器穩定性足夠可靠，即使訊息都在記憶體中也不會有太大的丟失風險。
3. 內建持久化設計需要權衡高吞吐場景下記憶體與磁碟的使用、多伺服器分佈叢集架構下資料的儲存與複製設計，在快速發展的專案中很難確保持久化設計一步到位。

儘管從效能的角度來看將所有訊息儲存在記憶體中是有益的，但基於記憶體的會話儲存仍不可避免地會帶來一些問題：大量的連線和可能存在的會話訊息堆積將帶來較高的記憶體佔用，這將限制使用者大規模使用持久會話功能（Clean Session = 0）；同時，在對 EMQX 進行重啟操作或者 EMQX 意外當機時也可能會導致會話資料丟失，從而對資料可靠性帶來一定影響。

隨著伺服器市場 SSD 磁碟的大量應用，記憶體與磁碟兩種方案之間的差距其實已經可以做到很小了。另外 LevelDB 和 RocksDB 基礎架構的繁榮發展以及在 Erlang 中的成熟使用也為原生會話持久化支援的實現奠定了基礎。

EMQX 自 5.0 正式開啟了億級物聯網連線時代，無論在功能還是效能方面均以匹配行業最新需求為目標進行了規劃設計，一個新的會話持久化能力支援設計方案也因此被提上日程。

## Why RocksDB：全新會話層選型

結合 EMQX 接入的資料特性，對比各種儲存引擎後我們最終選擇 RocksDB 作為新的持久化層。

### RocksDB 簡介

RocksDB 是一個嵌入式、持久化的鍵值儲存引擎。它針對快速、低延遲的儲存進行了最佳化，具有很高的寫入吞吐。RocksDB 支援預寫日誌，範圍掃描和字首搜尋，在高併發讀寫以及大容量儲存時能夠提供一致性的保證。

### 選型依據

在 [EMQX 會話層設計](https://www.emqx.io/docs/zh/v5.0/design/design.html#會話層設計)中，會話儲存於本地節點，我們傾向於在 EMQX 內部儲存資料，而不是把 EMQX 作為外部資料庫的一個前端，因此選型範圍限制在嵌入式資料庫中。除了 RocksDB 之外，我們還主要考察了以下資料庫：

- **Mnesia：** Mnesia 是 Erlang/OTP 自帶的分散式實時資料庫系統，在 Mnesia 叢集中，所有節點都是平等的。它們中的每一個節點都可以儲存一份資料副本，也可以啟動事務或執行讀寫操作。Mnesia 可以憑藉複製特性而支援極高的讀取吞吐，但這一特性也限制了其寫入吞吐，因為這意味著 MQTT 訊息基本上是在叢集內廣播的，廣播並不能橫向擴充套件。

[![Mnesia](http://img.blog.itpub.net/blog/2022/08/08/1fc46dd6bd379e9a.png?x-oss-process=style/bb "Mnesia")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "Mnesia")

- **LevelDB：** RocksDB 是 LevelDB 的一個改進分支，從功能上來說它們大多是等同的，但 LevelDB 在 Erlang 中缺少積極維護的驅動（Erlang NIF）因此沒有被採用。

相比之下，RocksDB 的優勢非常明顯：

- 極高的寫入吞吐：RocksDB 基於為資料寫入而最佳化的 LSM-Tree 結構，能夠支援 EMQX 海量訊息吞吐與快速訂閱時高頻的資料寫入
- 迭代器和快速範圍查詢：RocksDB 支援對排序的鍵進行迭代，基於此特性 EMQX 可以擴充套件更多功能
- 支援 Erlang：用於 RocksDB 的 NIF 庫已經成熟並得到積極支援

在對 RocksDB 會話持久化方案的初步測試中，RocksDB 的效能優勢得到充分發揮，相比記憶體儲存，在其他模組達到瓶頸之前即可達到相同的釋出率。

## EMQX 基於 RocksDB 的會話持久化設計

RocksDB 將替換當前 `apps/emqx/src/persistent_session` 目錄下的所有模組，以使用 RocksDB 來儲存 MQTT 會話資料。

EMQX 允許全部客戶端或使用 QoS、主題字首等過濾器配置需要啟用持久化的客戶端以及主題。在磁碟效能不足或可以接受訊息丟失、需要極端效能的場景中，允許使用者關閉持久化功能使用記憶體儲存方案。

### 資料分發

RocksDB 作為嵌入式資料庫，不具備叢集內資料分發的能力。在需要節點間傳遞資料的操作中，如會話從一個節點移動至另一個節點，會透過 EMQX 的訊息分發機制處理。

我們將 Mnesia 的複製特性與 RocksDB 的持久化特性結合到一起，會話可以儲存到 RocksDB，但是使用的是 Mnesia 的 API，RocksDB 只是 Mnesia 的一個後端。

[![Mnesia](http://img.blog.itpub.net/blog/2022/08/08/5b6dd8a0990d25e3.png?x-oss-process=style/bb "Mnesia")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "Mnesia")

### 哪些資料可以透過 RocksDB 持久化

1. 以 Clean Start = 0 連線的客戶端的會話記錄
2. 訂閱資料（Subscriptions），在訂閱時寫入 RocksDB，取消訂閱時從 RocksDB 刪除
3. 每次客戶端釋出訊息 QoS 1、QoS 2 訊息時，資料會寫入 RocksDB，保留至確認後刪除
4. 作為其他高吞吐低延遲場景的 Storage，如保留訊息、資料橋接快取佇列

## 持久化能力擴充套件

RocksDB 的引入為 EMQX 提供了一個高效能、可靠的持久化層，在此基礎上 EMQX 可以擴充套件更多的功能。

### 訊息重放

在某些場景下，釋出端不需要關心訂閱者是否線上，但又要求訊息必須到達訂閱端，即使訂閱端不線上甚至會話不存在。

透過持久層的支援，EMQX 能夠擴充套件 MQTT 協議實現以支援類似 Kafka 的訊息重放功能：訊息釋出時允許設定特殊的標誌位以持久儲存在釋出目標主題中，訂閱者攜帶非標準的訂閱屬性時，允許獲取主題中指定位置之後的訊息。

訊息重放能夠用於裝置初始化、OTA 升級這類不關心指令時效性的場景中，在釋出者和訂閱者之間更靈活的傳輸資料。

[![訊息重放典型流程](http://img.blog.itpub.net/blog/2022/08/08/af62199464ecaaa8.png?x-oss-process=style/bb "訊息重放典型流程")](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb "訊息重放典型流程")

訊息重放典型流程

1. 釋出端釋出一條永續性訊息
2. EMQX 將訊息儲存至重放佇列中，無需關心訂閱者是否線上
3. 訂閱端發起訂閱
4. EMQX 從指定位置讀取訊息
5. 重放訊息釋出到訂閱者

### 資料橋接快取佇列

將持久層用於資料橋接的快取佇列，當橋接資源不可用時可以將資料儲存至快取佇列，等待資源恢復後再繼續傳輸，避免大量資料在記憶體中堆積。

## 結語

基於 RocksDB 實現的原生 MQTT 會話持久化是 EMQX 釋出以來的一項突破性的重要功能變革，這一能力將為開源使用者提供更可靠的業務保證，可以不受限制地充分利用 MQTT 協議特性進行物聯網應用開發。使用外部資料儲存的企業使用者則可以遷移到 RocksDB，從而獲得更低時延的資料持久化方案。

同時，結合物聯網實際使用場景，EMQX 還將圍繞持久化能力擴充套件更多的功能支援，以滿足日益多樣化的物聯網資料需求。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb](https://www.emqx.com/zh/blog/mqtt-persistence-based-on-rocksdb)

基於 RocksDB 實現高可靠、低時延的 MQTT 資料持久化

相關文章