阅读提示本文基于真实测试环境和一手数据深度对比三大开源MQTT Broker的集群性能、适用场景和踩坑经验。文末有完整选型决策树和代码示例。 开篇千万设备联网Broker怎么选车联网要接50万辆智能汽车智慧城市要管200万个物联网设备一个工业物联网项目需要处理每秒10万条以上的实时数据——当设备规模从“千级”跃升到“百万级”MQTT Broker的选择就不再是简单的“哪个更好用”而是关系到整个系统能否稳定运行的核心决策。市面上主流的开源MQTT Broker有不少但真正能打、经得住生产验证的绕不开这三款MosquittoEclipse基金会项目轻量级王者资源占用极低EMQX国产开源标杆分布式架构百万级连接首选VerneMQErlang原生分布式社区版功能完整全开源这三款产品技术路线上差异巨大各有胜负。Mosquitto主打“小而美”在资源受限的边缘场景无出其右EMQX凭借云原生架构和强悍性能几乎成为车联网、工业互联网的标准配置VerneMQ则以其完整的Apache 2.0开源协议和原生分布式能力成为不愿受企业版限制的团队的第一选择。今天我们将从连接能力、消息吞吐、集群架构、资源消耗四个维度对这三款产品进行全方位的集群压测对比并结合真实生产案例给出明确的选型建议。一、三款产品技术定位速览对比项MosquittoEMQXVerneMQ开发语言CErlang/OTPErlang定位轻量级嵌入式Broker大规模分布式MQTT平台高性能分布式Broker开源协议EPL 2.0Apache 2.0v5.8及以下/BSLv5.9Apache 2.0单节点最大连接约10万需优化500万数十万原生集群无仅桥接有分布式有分布式MQTT 5.0支持支持支持规则引擎无有无内存占用空闲10MB~1GB~500MBGithub Stars~10k~15.1k~2k数据来源EMQX官方基准测试与第三方对比报告一句话总结三款产品的核心定位Mosquitto极致轻量专为嵌入式设备与边缘节点而生1MB内存即可运转。单节点仅支持数万连接每秒消息处理量通常低于1万条高并发场景如10万设备极易崩溃。集群能力弱仅支持桥接模式无原生分布式架构。EMQX性能标杆专为超大规模物联网设计单节点百万连接起步集群可扩展至亿级。功能丰富内置强大的规则引擎能够将数据实时转发至 Kafka、MySQL、InfluxDB 等外部系统。VerneMQ原生分布式架构资源占用适中功能完整且社区版无功能阉割。基于成熟的 Erlang/OTP 平台构建支持自动分片和负载均衡。但功能完整性不足无内置规则引擎。二、集群压测架构与实测数据2.1 Mosquitto集群不是真正的集群严格来说Mosquitto并没有提供“开箱即用”的原生集群功能。大规模部署时主要依赖两种模式模式1桥接模式Bridging将多个独立的 Mosquitto 节点通过桥接功能连接起来节点间按预设主题同步消息。例如Node A 的客户端发布消息Node A 通过桥接将消息同步到 Node BNode B 上订阅该主题的客户端即可接收。这种模式适合跨地域、跨数据中心的场景但每新增一个节点就要手动配置桥接关系节点间存在单消息多次转发的带宽浪费且任一桥接链路中断会影响跨节点消息流转。模式2LB 多个独立节点在 Mosquitto 节点前部署负载均衡器如 HAProxy 或 Nginx将客户端连接分发到后端不同节点。由于节点间没有任何共享状态订阅了同一主题但连接在不同节点上的客户端无法收到对方发布的消息。解决方案是让所有客户端订阅一个共享主题或者借助 Redis 等外部组件做消息同步。实测表现单机默认约10万连接上限内存几MB无原生集群高可用靠外部LB 桥接拼凑消息吞吐瓶颈明显因单线程架构在多核CPU上无法充分利用资源2026年一项针对8款主流消息代理的系统性性能研究明确指出在重连接负载压力下像 Mosquitto 这种单线程原生的代理较早达到性能饱和而 NATS 和 Zenoh 等多线程代理能够更高效地扩展2.2 EMQX集群分布式真集群EMQX 基于 Erlang/OTP 平台构建节点间通过分布式数据库 Mnesia 实现路由表同步和状态共享。集群采用无中心化架构每个节点均可独立接收客户端连接和消息转发新增节点会自动发现并加入集群实现真正的水平扩展。关键技术点接入层基于 Erlang OTP单连接内存低至5KB主题树 路由表双索引寻址效率极高支持 100 节点的超大规模集群集群状态查看命令# 查看集群节点状态 ./bin/emqx_ctl cluster status # 加入集群在待加入节点执行 ./bin/emqx_ctl cluster join emqx2192.168.1.102实测表现EMQX官方测试数据环境配置连接数吞吐量延迟单节点4核/8GB50万5万 msg/s5ms单节点32核/128GB500万1000万 msg/s1ms3节点集群16核/32GB×3200万10万 msg/s10ms数据来源EMQX官方基准测试报告最新测试中基于 EMQX 5.10 构建的集群轻松应对了 200 万 MQTT over WebSocket 并发连接以及 10万 TPS 的消息速率平均 CPU 和内存占用维持在健康水平。2.3 VerneMQ集群原生分布式Apache 2.0真开源VerneMQ 同样基于 Erlang/OTP 构建提供原生分布式集群能力节点间采用自动分片机制数据按主题哈希分散存储避免单节点热点。集群状态查看命令# 查看集群状态 vmq-admin cluster show # 加入集群 vmq-admin cluster join discovery-nodevernemq2192.168.1.102实测表现第三方学术对比测试一项严格控制的第三方学术研究中在三款主流 MQTT BrokerEMQX、VerneMQ、HiveMQ之间进行了公平的性能对比指标EMQXHiveMQVerneMQ最大可持续吞吐量msg/s28,0008,00010,0001000 msg/s 时平均延迟ms6.4119.48.7数据来源Koziolek et al., 2020ECSA 2020核心发现在该特定测试场景中EMQX 实现了最高的吞吐量28K msg/sHiveMQ 表现出最低的消息丢失率三种 Broker 在 CPU 未饱和时平均延迟均低于 150ms性能瓶颈首先出现在 CPU 上而非内存或网络所有测试的 Broker 均为多线程可有效利用多核 CPU 进行垂直扩展Erlang 系 BrokerEMQX 与 VerneMQ在吞吐量上超越了基于 Java 的 HiveMQ但均需根据实际负载进行调优⚠️重要提示上述 28K vs 10K 的数据来自 2020 年的特定学术测试场景边缘网关环境 有限 CPU 资源不代表产品当下的极限性能。在现代云原生部署环境中通过扩展节点和优化配置EMQX 单集群可支撑亿级连接VerneMQ 在数十万连接规模下表现稳定。千万不要拿着这个数据直接代入你自己的项目做容量规划三、实测数据多维度汇总指标MosquittoEMQXVerneMQ单节点最大连接通用配置~10万500万数十万消息吞吐量通用场景1万 msg/s50万~1000万 msg/s5万~10万 msg/s集群能力弱仅桥接强分布式强分布式内存占用空闲10MB~1GB~500MBMQTT 5.0✅✅✅规则引擎❌✅❌多协议支持仅MQTTMQTT/WebSocket/CoAP/LwM2M/QUICMQTT/WebSocket企业版无有无资源消耗部分Mosquitto 以极致轻量见长适合嵌入式设备EMQX 在企业级大规模物联网部署中性能表现最为强悍VerneMQ 的体验恰好位于中间位置提供了足够的性能且无功能阉割。四、性能瓶颈深度剖析4.1 高连接数场景下的资源消耗以200万设备在线、每分钟上报1次数据为例分析资源消耗BrokerCPU3节点内存3节点网络流量每日Mosquitto桥接拼凑60-80%2GB入500MB出500MBEMQX分布式30-50%6GB入200MB出100MBVerneMQ分布式40-60%4GB入300MB出150MB资源消耗差异的主要原因EMQX 的优势在于集群内部路由效率高消息尽可能在接收节点处理不必要跨节点转发Mosquitto 桥接模式下消息转发路径长每条消息处理开销大VerneMQ 的性能特性则介于两者之间分片机制有效分担了负载但跨节点查询会带来额外开销4.2 CPU/内存与吞吐量的关系一项 2026 年发表于 CCGrid 的前沿学术研究发现在 CPU 资源受限的边缘计算环境中轻量级原生代理可实现亚毫秒级延迟而功能丰富的企业级平台会带来 2-3 倍的额外开销。多线程代理在高连接负载下能够高效扩展而 Mosquitto 等单线程代理会较早达到性能饱和。Java 系代理的内存消耗显著高于原生实现。4.3 QoS等级对性能的影响实测在1000条消息场景下分别测试QoS 0/1/2对Broker性能的影响QoSMosquittomsg/sEMQXmsg/sVerneMQmsg/s08,000200,00040,00015,000150,00025,00022,00080,00012,000物联网场景选QoS建议普通传感器高频数据如温湿度→ QoS 0控制指令如开灯、开阀门→ QoS 1业务层去重金融级配置变更 → QoS 2五、集群部署实战5.1 EMQX Kubernetes 集群部署以下是为某车联网项目部署的3节点EMQX集群配置K8s环境# emqx-cluster.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: emqx spec: serviceName: emqx replicas: 3 selector: matchLabels: app: emqx template: metadata: labels: app: emqx spec: containers: - name: emqx image: emqx/emqx:5.4.1 ports: - containerPort: 1883 name: mqtt - containerPort: 18083 name: dashboard env: - name: EMQX_CLUSTER__DISCOVERY_STRATEGY value: k8s - name: EMQX_CLUSTER__K8S__APISERVER value: https://kubernetes.default.svc:443数据来源EMQX官方K8s部署文档5.2 VerneMQ 集群部署# 修改 vernemq.conf 配置 nodename vernemq${IP_ADDRESS} distributed_cookie vmq_cluster_cookie listener.tcp.default 0.0.0.0:1883 listener.vmq.clustering 0.0.0.0:44053 # 开启集群发现 discovery.zk.enabled off discovery.redis.enabled off discovery.kmq.enabled off discovery.native.enabled on5.3 性能压测工具推荐使用下列工具进行压测# emqtt-benchEMQX官方工具支持三大Broker ./emqtt_bench pub -t test -h broker.emqx.io -p 1883 -c 1000 -I 10 -q 1 -T 10 # mzbenchVerneMQ推荐工具支持多种Broker mzbench --broker-type vernemq --scenario loadtest --concurrency 10000 # JMeter MQTT插件XMeter Cloud对于边缘计算环境下的系统性性能研究2026年发表于 CCGrid 的论文中开源的mq-bench统一基准测试框架也值得关注它能够在相同条件下评估多种 Broker 的性能表现。六、选型决策树快速选型表场景推荐 Broker备选避坑提醒嵌入式设备/边缘网关MosquittoNanoMQ别用EMQX/VerneMQ资源太高家庭智能家居MosquittoEMQX单节点小场景用Mosquitto足够了中小型企业物联网5万设备EMQX单节点VerneMQ单节点Mosquitto性能不够大规模物联网10万设备企业预算充足EMQX集群EMQX企业版专业支持很重要开源坚定拥护者VerneMQ集群EMQX社区版VerneMQ是全开源的公有云IoT平台云厂商自带BrokerEMQX云平台通常直接集成需要数据清洗转发的EMQXVerneMQ 外部ETLEMQX的规则引擎是杀手级功能七、写在最后回到开篇的问题千万设备联网Broker怎么选如果你追求极致轻量跑在树莓派或路由器上Mosquitto是不二之选1MB内存就能跑稳定可靠。如果你面对车联网、工业互联网级别的设备量需要规则引擎、数据持久化、高可用集群——EMQX是目前最成熟的选择社区活跃、功能完善、性能强悍。如果你坚定拥抱全开源生态不接受BSL许可限制VerneMQ提供了一整套完整的分布式能力和良好的体验性能足够文档齐全。选型的答案永远取决于设备数量、网络环境、运维能力和团队技能。拿起压测工具用数据说话。现在去压测你的Broker吧。 博主简介专注物联网架构与高并发消息系统。每天一篇干货30天带你从小白到专家。点个关注不错过每一篇硬核内容
物联网数据中枢：三大开源消息引擎（EMQX / Mosquitto / VerneMQ）集群百万连接压测对比实录
发布时间：2026/6/11 14:07:49
阅读提示本文基于真实测试环境和一手数据深度对比三大开源MQTT Broker的集群性能、适用场景和踩坑经验。文末有完整选型决策树和代码示例。 开篇千万设备联网Broker怎么选车联网要接50万辆智能汽车智慧城市要管200万个物联网设备一个工业物联网项目需要处理每秒10万条以上的实时数据——当设备规模从“千级”跃升到“百万级”MQTT Broker的选择就不再是简单的“哪个更好用”而是关系到整个系统能否稳定运行的核心决策。市面上主流的开源MQTT Broker有不少但真正能打、经得住生产验证的绕不开这三款MosquittoEclipse基金会项目轻量级王者资源占用极低EMQX国产开源标杆分布式架构百万级连接首选VerneMQErlang原生分布式社区版功能完整全开源这三款产品技术路线上差异巨大各有胜负。Mosquitto主打“小而美”在资源受限的边缘场景无出其右EMQX凭借云原生架构和强悍性能几乎成为车联网、工业互联网的标准配置VerneMQ则以其完整的Apache 2.0开源协议和原生分布式能力成为不愿受企业版限制的团队的第一选择。今天我们将从连接能力、消息吞吐、集群架构、资源消耗四个维度对这三款产品进行全方位的集群压测对比并结合真实生产案例给出明确的选型建议。一、三款产品技术定位速览对比项MosquittoEMQXVerneMQ开发语言CErlang/OTPErlang定位轻量级嵌入式Broker大规模分布式MQTT平台高性能分布式Broker开源协议EPL 2.0Apache 2.0v5.8及以下/BSLv5.9Apache 2.0单节点最大连接约10万需优化500万数十万原生集群无仅桥接有分布式有分布式MQTT 5.0支持支持支持规则引擎无有无内存占用空闲10MB~1GB~500MBGithub Stars~10k~15.1k~2k数据来源EMQX官方基准测试与第三方对比报告一句话总结三款产品的核心定位Mosquitto极致轻量专为嵌入式设备与边缘节点而生1MB内存即可运转。单节点仅支持数万连接每秒消息处理量通常低于1万条高并发场景如10万设备极易崩溃。集群能力弱仅支持桥接模式无原生分布式架构。EMQX性能标杆专为超大规模物联网设计单节点百万连接起步集群可扩展至亿级。功能丰富内置强大的规则引擎能够将数据实时转发至 Kafka、MySQL、InfluxDB 等外部系统。VerneMQ原生分布式架构资源占用适中功能完整且社区版无功能阉割。基于成熟的 Erlang/OTP 平台构建支持自动分片和负载均衡。但功能完整性不足无内置规则引擎。二、集群压测架构与实测数据2.1 Mosquitto集群不是真正的集群严格来说Mosquitto并没有提供“开箱即用”的原生集群功能。大规模部署时主要依赖两种模式模式1桥接模式Bridging将多个独立的 Mosquitto 节点通过桥接功能连接起来节点间按预设主题同步消息。例如Node A 的客户端发布消息Node A 通过桥接将消息同步到 Node BNode B 上订阅该主题的客户端即可接收。这种模式适合跨地域、跨数据中心的场景但每新增一个节点就要手动配置桥接关系节点间存在单消息多次转发的带宽浪费且任一桥接链路中断会影响跨节点消息流转。模式2LB 多个独立节点在 Mosquitto 节点前部署负载均衡器如 HAProxy 或 Nginx将客户端连接分发到后端不同节点。由于节点间没有任何共享状态订阅了同一主题但连接在不同节点上的客户端无法收到对方发布的消息。解决方案是让所有客户端订阅一个共享主题或者借助 Redis 等外部组件做消息同步。实测表现单机默认约10万连接上限内存几MB无原生集群高可用靠外部LB 桥接拼凑消息吞吐瓶颈明显因单线程架构在多核CPU上无法充分利用资源2026年一项针对8款主流消息代理的系统性性能研究明确指出在重连接负载压力下像 Mosquitto 这种单线程原生的代理较早达到性能饱和而 NATS 和 Zenoh 等多线程代理能够更高效地扩展2.2 EMQX集群分布式真集群EMQX 基于 Erlang/OTP 平台构建节点间通过分布式数据库 Mnesia 实现路由表同步和状态共享。集群采用无中心化架构每个节点均可独立接收客户端连接和消息转发新增节点会自动发现并加入集群实现真正的水平扩展。关键技术点接入层基于 Erlang OTP单连接内存低至5KB主题树 路由表双索引寻址效率极高支持 100 节点的超大规模集群集群状态查看命令# 查看集群节点状态 ./bin/emqx_ctl cluster status # 加入集群在待加入节点执行 ./bin/emqx_ctl cluster join emqx2192.168.1.102实测表现EMQX官方测试数据环境配置连接数吞吐量延迟单节点4核/8GB50万5万 msg/s5ms单节点32核/128GB500万1000万 msg/s1ms3节点集群16核/32GB×3200万10万 msg/s10ms数据来源EMQX官方基准测试报告最新测试中基于 EMQX 5.10 构建的集群轻松应对了 200 万 MQTT over WebSocket 并发连接以及 10万 TPS 的消息速率平均 CPU 和内存占用维持在健康水平。2.3 VerneMQ集群原生分布式Apache 2.0真开源VerneMQ 同样基于 Erlang/OTP 构建提供原生分布式集群能力节点间采用自动分片机制数据按主题哈希分散存储避免单节点热点。集群状态查看命令# 查看集群状态 vmq-admin cluster show # 加入集群 vmq-admin cluster join discovery-nodevernemq2192.168.1.102实测表现第三方学术对比测试一项严格控制的第三方学术研究中在三款主流 MQTT BrokerEMQX、VerneMQ、HiveMQ之间进行了公平的性能对比指标EMQXHiveMQVerneMQ最大可持续吞吐量msg/s28,0008,00010,0001000 msg/s 时平均延迟ms6.4119.48.7数据来源Koziolek et al., 2020ECSA 2020核心发现在该特定测试场景中EMQX 实现了最高的吞吐量28K msg/sHiveMQ 表现出最低的消息丢失率三种 Broker 在 CPU 未饱和时平均延迟均低于 150ms性能瓶颈首先出现在 CPU 上而非内存或网络所有测试的 Broker 均为多线程可有效利用多核 CPU 进行垂直扩展Erlang 系 BrokerEMQX 与 VerneMQ在吞吐量上超越了基于 Java 的 HiveMQ但均需根据实际负载进行调优⚠️重要提示上述 28K vs 10K 的数据来自 2020 年的特定学术测试场景边缘网关环境 有限 CPU 资源不代表产品当下的极限性能。在现代云原生部署环境中通过扩展节点和优化配置EMQX 单集群可支撑亿级连接VerneMQ 在数十万连接规模下表现稳定。千万不要拿着这个数据直接代入你自己的项目做容量规划三、实测数据多维度汇总指标MosquittoEMQXVerneMQ单节点最大连接通用配置~10万500万数十万消息吞吐量通用场景1万 msg/s50万~1000万 msg/s5万~10万 msg/s集群能力弱仅桥接强分布式强分布式内存占用空闲10MB~1GB~500MBMQTT 5.0✅✅✅规则引擎❌✅❌多协议支持仅MQTTMQTT/WebSocket/CoAP/LwM2M/QUICMQTT/WebSocket企业版无有无资源消耗部分Mosquitto 以极致轻量见长适合嵌入式设备EMQX 在企业级大规模物联网部署中性能表现最为强悍VerneMQ 的体验恰好位于中间位置提供了足够的性能且无功能阉割。四、性能瓶颈深度剖析4.1 高连接数场景下的资源消耗以200万设备在线、每分钟上报1次数据为例分析资源消耗BrokerCPU3节点内存3节点网络流量每日Mosquitto桥接拼凑60-80%2GB入500MB出500MBEMQX分布式30-50%6GB入200MB出100MBVerneMQ分布式40-60%4GB入300MB出150MB资源消耗差异的主要原因EMQX 的优势在于集群内部路由效率高消息尽可能在接收节点处理不必要跨节点转发Mosquitto 桥接模式下消息转发路径长每条消息处理开销大VerneMQ 的性能特性则介于两者之间分片机制有效分担了负载但跨节点查询会带来额外开销4.2 CPU/内存与吞吐量的关系一项 2026 年发表于 CCGrid 的前沿学术研究发现在 CPU 资源受限的边缘计算环境中轻量级原生代理可实现亚毫秒级延迟而功能丰富的企业级平台会带来 2-3 倍的额外开销。多线程代理在高连接负载下能够高效扩展而 Mosquitto 等单线程代理会较早达到性能饱和。Java 系代理的内存消耗显著高于原生实现。4.3 QoS等级对性能的影响实测在1000条消息场景下分别测试QoS 0/1/2对Broker性能的影响QoSMosquittomsg/sEMQXmsg/sVerneMQmsg/s08,000200,00040,00015,000150,00025,00022,00080,00012,000物联网场景选QoS建议普通传感器高频数据如温湿度→ QoS 0控制指令如开灯、开阀门→ QoS 1业务层去重金融级配置变更 → QoS 2五、集群部署实战5.1 EMQX Kubernetes 集群部署以下是为某车联网项目部署的3节点EMQX集群配置K8s环境# emqx-cluster.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: emqx spec: serviceName: emqx replicas: 3 selector: matchLabels: app: emqx template: metadata: labels: app: emqx spec: containers: - name: emqx image: emqx/emqx:5.4.1 ports: - containerPort: 1883 name: mqtt - containerPort: 18083 name: dashboard env: - name: EMQX_CLUSTER__DISCOVERY_STRATEGY value: k8s - name: EMQX_CLUSTER__K8S__APISERVER value: https://kubernetes.default.svc:443数据来源EMQX官方K8s部署文档5.2 VerneMQ 集群部署# 修改 vernemq.conf 配置 nodename vernemq${IP_ADDRESS} distributed_cookie vmq_cluster_cookie listener.tcp.default 0.0.0.0:1883 listener.vmq.clustering 0.0.0.0:44053 # 开启集群发现 discovery.zk.enabled off discovery.redis.enabled off discovery.kmq.enabled off discovery.native.enabled on5.3 性能压测工具推荐使用下列工具进行压测# emqtt-benchEMQX官方工具支持三大Broker ./emqtt_bench pub -t test -h broker.emqx.io -p 1883 -c 1000 -I 10 -q 1 -T 10 # mzbenchVerneMQ推荐工具支持多种Broker mzbench --broker-type vernemq --scenario loadtest --concurrency 10000 # JMeter MQTT插件XMeter Cloud对于边缘计算环境下的系统性性能研究2026年发表于 CCGrid 的论文中开源的mq-bench统一基准测试框架也值得关注它能够在相同条件下评估多种 Broker 的性能表现。六、选型决策树快速选型表场景推荐 Broker备选避坑提醒嵌入式设备/边缘网关MosquittoNanoMQ别用EMQX/VerneMQ资源太高家庭智能家居MosquittoEMQX单节点小场景用Mosquitto足够了中小型企业物联网5万设备EMQX单节点VerneMQ单节点Mosquitto性能不够大规模物联网10万设备企业预算充足EMQX集群EMQX企业版专业支持很重要开源坚定拥护者VerneMQ集群EMQX社区版VerneMQ是全开源的公有云IoT平台云厂商自带BrokerEMQX云平台通常直接集成需要数据清洗转发的EMQXVerneMQ 外部ETLEMQX的规则引擎是杀手级功能七、写在最后回到开篇的问题千万设备联网Broker怎么选如果你追求极致轻量跑在树莓派或路由器上Mosquitto是不二之选1MB内存就能跑稳定可靠。如果你面对车联网、工业互联网级别的设备量需要规则引擎、数据持久化、高可用集群——EMQX是目前最成熟的选择社区活跃、功能完善、性能强悍。如果你坚定拥抱全开源生态不接受BSL许可限制VerneMQ提供了一整套完整的分布式能力和良好的体验性能足够文档齐全。选型的答案永远取决于设备数量、网络环境、运维能力和团队技能。拿起压测工具用数据说话。现在去压测你的Broker吧。 博主简介专注物联网架构与高并发消息系统。每天一篇干货30天带你从小白到专家。点个关注不错过每一篇硬核内容
