截止 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 效能測試對比,包含快速使用的測試工具。
EMQ 提供了一個效能測試工具 emqtt-benck,採用 Erlang 編寫,在 MacBook 2015款上能跑出 2K 連線,10K訊息吞吐,把電腦壓榨到宕機,適合來做 MQTT Broker 效能測試。
開源效能測試框架 JMeter 也有 MQTT 效能測試的功能,基於此的 XMeter 提供效能測試商業服務。
此處採用 HiveMQ 提供的 broker.hivemq.com 線上伺服器作爲測試 Broker,場景如下:
下圖爲結果,HiveMQ 應該是做了相應的限制,PUB 測試會報錯,實際測試自己的 MQTT Broker 效能時應當按需調節。
git clone https://github.com/emqx/emqtt-bench.git
cd emqtt-bench
./emqtt-bench sub --help
建立 100 個用戶端連線
./emqtt_bench conn -c 100 -h broker.hivemq.com
建立 100 個用戶端連線,每 10ms 建立一個連線,每個連線均訂閱 testtopic/# 主題,QoS 爲 2
./emqtt_bench sub -c 100 -i 10 -t testtopic/# -q 2 -h broker.hivemq.com
建立 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 與訊息佇列有一定的區別,佇列是一種先進先出的數據結構,訊息佇列常用於應用服務層面,實現參考如 RabbitMQ Kafka RocketMQ;
MQTT 是傳輸協定,絕大部分 MQTT Broker 不保證訊息順序(Queue),常用與物聯網、訊息傳輸等,MQTT Broker 的常見需求可參考:共用行業的分佈式 MQTT 設計
場景 | 部署端 | MQTT | 訊息佇列 |
---|---|---|---|
裝置端上報狀態數據、裝置通訊 | 行動終端 | √ | × |
接收並處理分析裝置的上報數據 | 行動終端 | × | √ |
對多個裝置下發控制指令 | 伺服器 | × | √ |
直播、彈幕、聊天 App 收發訊息 | 應用 | √ | × |
伺服器端接收並分析聊天訊息 | 伺服器 | × | √ |
用戶端連線數 | 用戶端規模龐大,百萬甚至千萬級 | 一般伺服器規模較小,極少數萬級 | |
單用戶端訊息量 | 單個用戶端需要處理的訊息少,一般定時收發訊息 | 單個用戶端處理訊息量大,注重吞吐量 |
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
docker run -p 8080:8080 -p 1883:1883 -p 8083:8083 hivemq/hivemq4
啓動之後開啓 http://localhost:8080
HiveMQ 預設使用者名稱密碼:
使用者名稱:admin
密碼:hivemq
docker run -p 1883:1883 -e "DOCKER_VERNEMQ_ACCEPT_EULA=yes" --name vernemq1 -d vernemq/vernemq
docker run -it --name=mosquitto -p 1883:1883 -p 9001:9001 -d eclipse-mosquitto
9001 是 Mosquitto WebSocket 埠。