12 月，[NanoMQ](https://www.emqx.com/zh/products/nanomq) 繼續保持穩步更新，最新的 0.15 版本將於本月初發布。這一版本增加了配置熱更新功能和 Reload 命令；MQTT over QUIC 橋接再次得到升級，增加了擁塞控制和 QoS 訊息優先傳輸；另外也為上一個版本新增的 HOCON 配置檔案做了多項安全性和功能修復，併為硬實時翼輝（SylixOS）作業系統推出了能夠相容執行的版本。

## 配置熱更新

如果要在 NanoMQ 服務執行過程中修改執行引數而不影響已經連線的客戶端，就需要使用熱更新功能。由於 NanoMQ 為純 C 語言開發，無內建執行時，所以熱更新功能僅支援配置檔案中部分標註為「Hot updatable」的欄位，目的在於提供使用者一種可以實時調整 Broker 服務執行引數的方法。以 HOCON 格式配置檔案為例，可支援熱更新的引數如下：

```clean
mqtt.session {
    # # Property_size
    # # The max size for a MQTT user property
    # # MQTT 5.0 訊息中最大可攜帶的使用者屬性長度
    # # Hot updatable
    # # Value: 1-infinity
    property_size = 32
    
    # # The max packet size of NanoMQ (Kbytes)
    # # Defines the max size of a packet that NanoMQ could accept
    # # 最大可接收的MQTT報文長度，單位為位元組
    # # Hot updatable
    # # Value: 1 Byte-260 Mb
    max_packet_size = 1024
    
    # # The default max packet size of each client (Kbytes)
    # # Defines the default max size limit of sending packet to each client
    # # Will be overwrite if client set its own max size limit
    # # 最大允許向客戶端轉發的MQTT報文長度，單位為位元組
    # # Hot updatable
    # # Value: 1 Byte-260 Mb
    client_max_packet_size = 1024
    
    # # msq_len
    # # The queue length in-flight window
    # # This is essential for performance and memory consumption
    # # NanoMQ內建的緩衝飛行佇列長度，影響記憶體消耗和消費能力不足時訊息是否丟失。
    # # Hot updatable
    # # Value: 1-infinity
    msq_len = 2048
    
    # # qos_duration (s)
    # # The nano qos duration which also controls timer interval of each pipe
    # # 全域性定時器顆粒度，單位為秒
    # # Hot updatable
    # # Value: 1-infinity
    qos_duration = 10s
    
    # # anonymous
    # # allow anonymous login
    # # 是否允許匿名登入
    # # Hot updatable
    # # Value: true | false
    allow_anonymous = true
}
```

### HTTP 熱更新

同時 NanoMQ 也支援使用 HTTP API 請求和命令列兩種方式進行熱更新，使用 HTTP 介面 + Basic 認證方式示例如下：

```jboss-cli
（此功能需要http server支援; 設定 http_server.enable=true）
$ curl --location --request POST 'http://localhost:8081/api/v4/reload' \
--header 'Authorization: Basic YWRtaW46cHVibGlj' \
--header 'Content-Type: application/json' \
--data-raw '{
    "data": {
        "data": {
                "property_size": 32,
                "max_packet_size": 1024,
                "client_max_packet_size": 1024,
                "msq_len": 4096,
                "qos_duration": 20,
                "keepalive_backoff": 1250,
                "allow_anonymous": true
        }
    }
}'

{
    "code": 0
}
```

修改完成後，可以使用查詢基本配置的介面來驗證是否修改成功。

~~~dsconfig
```shell
$ curl --location --request GET 'http://127.0.0.1:8081/api/v4/configuration/basic' \
--header 'Authorization: Basic YWRtaW46cHVibGlj'
~~~

### Reload 命令

也可以直接使用命令列工具來過載選定的配置檔案，需要啟動的時候開啟 enable_ipc_internal=true，然後修改原配置檔案或新的配置檔案中支援熱更新的引數，最後執行指令：

```jboss-cli
# 若修改的是原檔案，可不帶配置檔案路徑
$ nanomq reload 
# 若使用新的配置檔案，需要帶上配置檔案路徑
$ nanomq reload --conf /tmp/nanomq2.conf
```

## MQTT over QUIC 橋接再升級

QUIC 橋接功能一經推出得到了熱烈反響，許多使用者都在各種複雜的弱網環境下嘗試使用了該功能來完成資料到雲端的上傳同步。根據從各位使用者和各種測試場景收集的資料，本次 NanoMQ 版本釋出著重最佳化升級了 [MQTT over QUIC](https://www.emqx.com/zh/blog/getting-started-with-mqtt-over-quic-from-scratch) 橋接功能在弱網環境下的表現，增加了擁塞控制演算法的支援，併為 QoS 訊息設定了更高的優先傳輸級別。

### 擁塞控制演算法支援

每當網路環境突然變差，而訊息上傳的速率卻並沒有降低，上行資料通道就會發生擁塞。這時候如果還想保持連線，並且最大限度有效利用剩餘的頻寬，就需要擁塞控制演算法出場了。擁塞控制是 TCP/QUIC 協議的一個基礎部分，多年來經過一個個版本的迭代（如 Tahoe、Reno、Vegas 等），擁塞控制演算法得到了持續的提升。本文不對演算法做詳細介紹，簡而言之透過實時偵測和改變傳送滑動視窗的大小來完成慢啟動、擁塞避免、快速重傳和快速恢復等功能，NanoMQ 的 QUIC 橋接功能依賴於 MsQUIC，目前支援的有比較流行的兩種擁塞控制演算法：CUBIC 和 BBR。一般使用中建議開啟 BBR。開啟方式很簡單，只需在配置檔案中開啟即可：

```jboss-cli
bridges.mqtt {
    nodes = [
        {
            name = emqx
            enable = false
            connector {
                  ......
            }
            ......
            ## 此處設定 cubic/bbr 字串來選擇擁塞控制演算法即可
            congestion_control = cubic
            subscription = [
                {
                    topic = "cmd/topic1"
                    qos = 1
                },
                {
                    topic = "cmd/topic2"
                    qos = 2
                }
            ]
            ......
```

### QoS 訊息優先順序分級

由於 IoT 資料具有強烈的時空伴隨特性，我們發現，在遇到網路突然變差時，使用者往往希望優先保證一些重要的資料傳輸不受到影響，但可以接受一些普通的採集資料因為弱網而丟失。同時如果一條資料因為多次重傳、擁塞排隊或嘗試過久而造成極大的訊息延時，這樣就算最終達到了雲端，也會因為延時過大而失去了原有的價值，而只能被雲端丟棄。這樣既浪費了頻寬，還影響了其他更有價值資料的傳輸。

針對這一情況，NanoMQ 特地在 QUIC 橋接模式上推出了 QoS 訊息優先傳輸的功能，使用者釋出到橋接通道內的 QoS 1/2 級別的訊息會先於 QoS 0 的資料被處理和排程，在傳輸 QoS 0 的訊息時若發現擁塞佇列過長，則不會再繼續嘗試將此訊息入隊待傳送而是直接丟棄。如此最終就可達到讓重要資料優先使用有限頻寬的效果。

測試場景：

1. 施加 2s 延遲 + 40% 丟包的網路引數
2. 同時往 2 個橋接主題，以同樣 50 條訊息/s 的速率傳送長度為 128 位元組的 QoS 0 和 QoS 1 訊息，各 2000 條。
3. 在對端 Broker 以非弱網模式接收訊息並記錄最大延時

測試中 QUIC 連線都未發生重連。

[![](http://img.blog.itpub.net/blog/2023/01/05/caa9f86272b9e6c0.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202212)

可以發現，在使用優先順序傳輸模式並開啟用擁塞控制時，能保證 QoS 1 的訊息得到優先傳輸。

為了適配更多的使用場景，我們為這三種模式都預留了配置選項。

## 其他最佳化

### 完善修復 HOCON 配置檔案支援，並提高安全性

NanoMQ 0.14 版本引入 HOCON 配置檔案後，繼續對背後使用的純 C 語言開發的 HOCON 解析器進行完善和提高安全性工作，透過模糊測試和使用 AFL 工具測試發現並修復了許多問題。歡迎使用者試用這一小巧精簡的 HOCON 解析庫。

### 新增作業系統相容支援

NanoMQ 自誕生之初就具備極強的可移植性和相容性，現在相容的作業系統列表上又新增了一個成員：翼輝（SylixOS）作業系統。

[SylixOS](https://www.acoinfo.com/product/108/?category=42&subCategory=262&curCategory=108) 是一個嵌入式實時作業系統，支援 SMP 多核實時排程，可執行於多種 CPU 架構目標平臺。具有卓越實時性和可靠性，提供豐富的功能，可為不同行業的嵌入式裝置提供理想的軟體開發平臺。NanoMQ 響應基礎軟體國產化浪潮，也正式適配了其 2.1.6 版本。

針對 [SylixOS 嵌入式系統](https://www.acoinfo.com/product/108/?category=42&subCategory=262&curCategory=108)，我們為 NanoMQ 和 NanoSDK 都移植了專用的版本，並且對基礎的 MQTT Broker 功能都進行了完整測試，若您對在 SylixOS 上使用 NanoMQ 有興趣，歡迎與我們聯絡。

## 問題修復

1. 修復了 HOCON 格式配置檔案中配置規則引起不生效的問題。
2. 修復了若干使用 Reload 命令過載異常配置檔案會導致服務中止的問題。
3. 修復了使用 MQTT over QUIC 橋接時，在大量資料傳輸時網路突然斷開可能造成的資料競爭問題。

## 即將到來

在一二月，NanoMQ 專案會繼續提高 MQTT over QUIC 橋接的體驗，透過引入 Multi-Stream 模式來實現各個主題資料的隔離排程。還會為 NanoMQ 加入 DDS 協議的轉換閘道器，以支援使用者將 DDS 的資料透過 NanoMQ 來完成跨域傳輸並透過 MQTT 和雲端互通。

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

配置熱更新/支援 Reload、QUIC 橋接再升級

相關文章