MQTT Broker 比較與選型

2020-08-10 16:43:42

開源 MQTT Broker 對比

截止 2020,物聯網行業裡可選的MQTT Broker有很多,除了經典的Mosquitto和AWS、Azure,百度雲、阿裡雲、IBM等幾個提供物聯網MQTT接入服務的產品外,可用於商業生產的MQTT Broker還有多款。

本文選取了幾個熱門開源的 MQTT Broker,其中部分專案提供商業支援,做簡單選型對比。

對比專案 EMQ HiveMQ VerneMQ ActiveMQ Mosquitto
License 開源+商業版 開源+商業版 開源+商業版 開源 開源
公司/社羣 EMQ HiveMQ VerenMQ Apache 基金會 Eclipse 基金會
開源協定 Apache License 2.0 Apache License 2.0 Apache License 2.0 Apache License 2.0 EPL/EDL licensed
開發團隊 杭州映雲科技有限公司 dc-square 股份有限公司,德國 Octavo Labs AG,瑞士 Apache 專案維護者 Eclipse 開源社羣
開發語言 Erlang Java Erlang Java C
專案歷史 2012年開始開源,2016年開始商業化 2013 年成立,一直以閉源方式向客戶提供軟體,2019 年開源 提供基於開源的商業化定製服務 2004 由 LogicBlaze 建立;原本規劃的 ActiveMQ 的下一代開源專案 Apollo 已經不活動(4年沒有程式碼更新)  
叢集架構 支援 僅企業版 支援 支援 不支援(有僞叢集實現)
系統部署 物理機、虛擬機器、K8S 物理機、虛擬機器、K8S 物理機、虛擬機器、K8S 物理機、虛擬機器、容器 物理機、虛擬機器、容器
支援協定 MQTT、CoAP、MQTT-SN、WebSocket、TCP、UDP、LwM2M MQTT MQTT JMS、Openwire、Stomp、AMQP、MQTT、WebSocket XMPP MQTT、WebSocket
系統效能 單機效能較高,單機支援百萬級併發,叢集支援千萬級併發 叢集支援千萬級併發 叢集支援百萬級併發 支援叢集 單機10W
MQTT v3.1,v3.1.1,v5.0 v3.1,v3.1.1,v5.0 v3.1,v3.1.1,v5.0 v3.1 v3.1,v3.1.1,v5.0
邊緣計算 EMQ X Edge 支援樹莓派,ARM 等架構,支援數據同步到雲服務 Azure IoT Hub AWS 不支援 不支援 不支援 支援(自身比較輕量)
安全與認證 TLS/DTLS、X.509證書、JWT、OAuth2.0、應用協定(ID/使用者名稱/密碼)、數據庫與介面形式的認證與 ACL 功能(LDAP、DB、HTTP) TLS/DTLS、X.509證書、JWT、OAuth2.0、應用協定(ID/使用者名稱/密碼)、組態檔形式的認證與 ACL 功能 TLS/DTLS、X.509證書、組態檔形式的認證與 ACL 功能、數據庫形式的認證與 ACL 功能,但支援數據庫較少 LDAP (JAAS)、Apache Shiro 等待
執行持久化 支援將訊息數據持久化至外部數據庫如 Redis、MySQL、PostgreSQL、MongoDB、Cassa、Dynamo 等,需企業版,開源版宕機則丟失 開源企業均支援本地持久化,採用磁碟系統,支援備份,導出備份 支援持久化至 Google LevelDB AMQ、KahaDB、JDBC、LevelDB 等待
擴充套件方式 Webhook、Trigger、Plugin 等,支援 Erlang 與 Lua、Java、Python 擴充套件開發,支援 Webhook 開發,侵入性不強 Trigger、Plugin 等,使用 Java 技術棧開發,提供方便開發的 SDK Trigger、Plugin 等,支援 Erlang 與 Lua 擴充套件開發 Java 擴充套件 等待
數據儲存 企業版適配數據庫:Redis、Mysql、PostgreSQL、MongoDB、Cassandra、OpenTSDB、TimescaleDB、InfluxDB 適配訊息佇列:Kakfa、RabbitMQ、Pulsar 橋接模式:支援橋接至標準 MQTT 協定訊息服務
開源版支援 HTTP 將數據同步、儲存
適配數據庫:無,提供 Java SDK 開發進行適配
訊息佇列:Kafka 橋接模式:支援橋接至標準 MQTT 協定訊息服務
適配數據庫:無,提供 Erlang 和 Lua 擴充套件開發 適配訊息佇列:無 橋接模式:支援橋接至標準 MQTT 協定訊息服務 適配數據庫:JDBC、KahaDB、LevelDB 適配訊息佇列:無 橋接模式:支援通過 JMS 橋接 等待
管理監控 支援視覺化的 Dashboard,實現叢集與節點的統一集中管理 支援第三方監控工具 Prometheus ,提供視覺化 Grafana 介面模板 支援視覺化的 HiveMQ Control Center,實現叢集與節點統一管理 支援第三方監控工具 Prometheus ,可提供視覺化 Grafana 介面 支援 InfluxDB 監控 內建簡單狀態管理視覺化介面 支援第三方監控工具 Prometheus ,可提供視覺化 Grafana 介面 支援視覺化的監控介面 支援第三方監控工具 Prometheus ,可提供視覺化 Grafana 介面 通過 MQTT 訂閱系統主題
規則引擎 支援規則引擎,基於 SQL 的規則引擎給予 Broker 超越一般訊息中介軟體的能力。除了在接受轉發訊息之外,規則引擎還可以解析訊息的格式(企業版)。
規則引擎由訊息的訂閱,發佈,確認的事件觸發,根據訊息的負載來執行相應的動作,降低應用開發的複雜度。
不支援 不支援 不支援 不支援
開發整合 支援通過 REST API 進行常用的業務管理操作如: 調整設定、獲取 Broker 狀態資訊、進行訊息發佈、代理訂閱與取消訂閱、斷開指定用戶端、檢視用戶端列表、規則引擎管理、外掛管理,提供 Java SDK、Python SDK 直接編碼處理業務邏輯 無,提供 Java SDK 在應用系統在編碼的層面操作進程,非常靈活但耦合性高 提供少量 REST API,用於監控與狀態管理、用戶端管理等。 缺乏代理訂閱、業務管理等功能和 API 提供少量佇列管理 REST API 等待
適用場景 優勢在於高併發連線與高吞吐訊息的服務能力,以及物聯網協定棧支援的完整性;擴充套件能力較強,無需過多開發 有一定高併發連線與高吞吐訊息的服務能力,物聯網協定棧的完整性較弱僅支援 MQTT 協定;缺乏開箱即用的功能外掛,功能必須編碼使用 基礎的併發連線與高吞吐訊息的服務能力,物聯網協定棧的完整性較弱僅支援 MQTT 協定;擴充套件能力較差,基礎的業務元件支援度不夠,商業成熟度不足客戶量較少,缺乏開箱即用的功能外掛 核心是訊息佇列系統,主要用於支援異構應用之間的訊息通訊,比如用於企業訊息匯流排等;後面支援了部分物聯網協定。ActiveMQ 比較適合系統既要支援傳統的異構應用之間需要通訊,也需要支援小型物聯網接入支援的使用者。 輕量簡便的 MQTT Broker,工控、閘道器或小規模接入專案

效能測試對比

MQTT Broker 效能測試對比,包含快速使用的測試工具。

  • MQTTBox 用戶端工具提供了一個 MQTT 連線與效能測試功能,但是這個是基於 JS 來做的且比較簡單,功能與效能都一般。
  • EMQ 提供了一個效能測試工具 emqtt-benck,採用 Erlang 編寫,在 MacBook 2015款上能跑出 2K 連線,10K訊息吞吐,把電腦壓榨到宕機,適合來做 MQTT Broker 效能測試。

    • 連線:指定連線數、連線速率,測試 MQTT Broker 的連線效能(速率、響應時間、錯誤數)
    • 訂閱:指定連線數、主題數、訂閱速率,QoS、測試 MQTT Broker 的訂閱效能(速率、響應時間、錯誤數)
    • 發佈:指定連線數、訊息發佈速率、訊息大小、QoS,測試 MQTT Broker 的訊息吞吐效能(速率、響應時間、錯誤數)
  • 開源效能測試框架 JMeter 也有 MQTT 效能測試的功能,基於此的 XMeter 提供效能測試商業服務。

效能測試場景

此處採用 HiveMQ 提供的 broker.hivemq.com 線上伺服器作爲測試 Broker,場景如下:

  • 訊息發佈吞吐:1000ms/10ms * 100 連線 = 10K/秒
  • 訊息轉發吞吐:100 連線 1 訂閱 10K/s = 1000K = 100W

下圖爲結果,HiveMQ 應該是做了相應的限制,PUB 測試會報錯,實際測試自己的 MQTT Broker 效能時應當按需調節。

image-20200623175355400

下載安裝測試工具

git clone https://github.com/emqx/emqtt-bench.git

cd emqtt-bench

./emqtt-bench sub --help

MQTT 連線效能測試

建立 100 個用戶端連線

./emqtt_bench conn -c 100 -h broker.hivemq.com

MQTT 訂閱效能測試

建立 100 個用戶端連線,每 10ms 建立一個連線,每個連線均訂閱 testtopic/# 主題,QoS 爲 2

./emqtt_bench sub -c 100 -i 10 -t testtopic/# -q 2 -h broker.hivemq.com

MQTT 發佈效能測試

建立 100 個用戶端連線,每 10ms 建立一個連線,每個連線 10ms 發佈一次訊息,每個連線均向 testtopic/${clientid} 主題發佈訊息,單條訊息尺寸爲 256 Bytes,訊息 QoS 爲 2

./emqtt_bench pub -c 100 -i 10 -I 10 -t testtopic/%i -s 256 -q 2 -h broker.hivemq.com

MQTT Broker 職責與需求

訊息佇列訊息中介軟體適用場景不一樣。

MQTT 與訊息佇列有一定的區別,佇列是一種先進先出的數據結構,訊息佇列常用於應用服務層面,實現參考如 RabbitMQ Kafka RocketMQ;

MQTT 是傳輸協定,絕大部分 MQTT Broker 不保證訊息順序(Queue),常用與物聯網、訊息傳輸等,MQTT Broker 的常見需求可參考:共用行業的分佈式 MQTT 設計

 

訊息佇列與MQTT異同

場景 部署端 MQTT 訊息佇列
裝置端上報狀態數據、裝置通訊 行動終端 ×
接收並處理分析裝置的上報數據 行動終端 ×
對多個裝置下發控制指令 伺服器 ×
直播、彈幕、聊天 App 收發訊息 應用 ×
伺服器端接收並分析聊天訊息 伺服器 ×
用戶端連線數   用戶端規模龐大,百萬甚至千萬級 一般伺服器規模較小,極少數萬級
單用戶端訊息量   單個用戶端需要處理的訊息少,一般定時收發訊息 單個用戶端處理訊息量大,注重吞吐量

EMQ X Docker 安裝

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8083:8083 -p 8084:8084 -p 18083:18083 emqx/emqx

啓動之後開啓 http://localhost:18083

EMQ X Dashboard 預設使用者名稱密碼:

使用者名稱:admin

密碼:public

HiveMQ Docker 安裝

docker run -p 8080:8080 -p 1883:1883 -p 8083:8083 hivemq/hivemq4

啓動之後開啓 http://localhost:8080

HiveMQ 預設使用者名稱密碼:

使用者名稱:admin

密碼:hivemq

VerneMQ Docker 安裝

docker run -p 1883:1883 -e "DOCKER_VERNEMQ_ACCEPT_EULA=yes" --name vernemq1 -d vernemq/vernemq

Mosquitto Docker 安裝

docker run -it --name=mosquitto -p 1883:1883 -p 9001:9001 -d eclipse-mosquitto

 

9001 是 Mosquitto WebSocket 埠。

全部 MQTT Broker 與 MQTT 服務列表