物联网数据中枢：三大开源消息引擎（EMQX / Mosquitto / VerneMQ）集群百万连接压测对比实录

💡 阅读提示：本文基于真实测试环境和一手数据，深度对比三大开源MQTT Broker的集群性能、适用场景和踩坑经验。文末有完整选型决策树和代码示例。

🚨 开篇：千万设备联网，Broker怎么选？

车联网要接50万辆智能汽车，智慧城市要管200万个物联网设备，一个工业物联网项目需要处理每秒10万条以上的实时数据——当设备规模从“千级”跃升到“百万级”，MQTT Broker的选择就不再是简单的“哪个更好用”，而是关系到整个系统能否稳定运行的核心决策。

市面上主流的开源MQTT Broker有不少，但真正能打、经得住生产验证的，绕不开这三款：

• Mosquitto：Eclipse基金会项目，轻量级王者，资源占用极低

• EMQX：国产开源标杆，分布式架构，百万级连接首选

• VerneMQ：Erlang原生分布式，社区版功能完整，全开源

这三款产品技术路线上差异巨大，各有胜负。Mosquitto主打“小而美”，在资源受限的边缘场景无出其右；EMQX凭借云原生架构和强悍性能，几乎成为车联网、工业互联网的标准配置；VerneMQ则以其完整的Apache 2.0开源协议和原生分布式能力，成为不愿受企业版限制的团队的第一选择。

今天，我们将从连接能力、消息吞吐、集群架构、资源消耗四个维度，对这三款产品进行全方位的集群压测对比，并结合真实生产案例，给出明确的选型建议。

一、三款产品技术定位速览

数据来源：EMQX官方基准测试与第三方对比报告

一句话总结三款产品的核心定位：

• Mosquitto：极致轻量，专为嵌入式设备与边缘节点而生，1MB内存即可运转。单节点仅支持数万连接，每秒消息处理量通常低于1万条，高并发场景（如10万+设备）极易崩溃。集群能力弱，仅支持桥接模式，无原生分布式架构。

• EMQX：性能标杆，专为超大规模物联网设计，单节点百万连接起步，集群可扩展至亿级。功能丰富，内置强大的规则引擎，能够将数据实时转发至 Kafka、MySQL、InfluxDB 等外部系统。

• VerneMQ：原生分布式架构，资源占用适中，功能完整且社区版无功能阉割。基于成熟的 Erlang/OTP 平台构建，支持自动分片和负载均衡。但功能完整性不足，无内置规则引擎。

二、集群压测：架构与实测数据

2.1 Mosquitto集群：不是真正的集群

严格来说，Mosquitto并没有提供“开箱即用”的原生集群功能。大规模部署时，主要依赖两种模式：

模式1：桥接模式（Bridging）

将多个独立的 Mosquitto 节点通过桥接功能连接起来，节点间按预设主题同步消息。例如，Node A 的客户端发布消息，Node A 通过桥接将消息同步到 Node B，Node B 上订阅该主题的客户端即可接收。这种模式适合跨地域、跨数据中心的场景，但每新增一个节点就要手动配置桥接关系，节点间存在单消息多次转发的带宽浪费，且任一桥接链路中断会影响跨节点消息流转。

模式2：LB + 多个独立节点

在 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 emqx2@192.168.1.102

实测表现（EMQX官方测试数据）：

数据来源：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-node="vernemq2@192.168.1.102"

实测表现（第三方学术对比测试）：

一项严格控制的第三方学术研究中，在三款主流 MQTT Broker（EMQX、VerneMQ、HiveMQ）之间进行了公平的性能对比：

数据来源：Koziolek et al., 2020（ECSA 2020）

核心发现：

• 在该特定测试场景中，EMQX 实现了最高的吞吐量（28K msg/s），HiveMQ 表现出最低的消息丢失率

• 三种 Broker 在 CPU 未饱和时平均延迟均低于 150ms

• 性能瓶颈首先出现在 CPU 上，而非内存或网络

• 所有测试的 Broker 均为多线程，可有效利用多核 CPU 进行垂直扩展

• Erlang 系 Broker（EMQX 与 VerneMQ）在吞吐量上超越了基于 Java 的 HiveMQ，但均需根据实际负载进行调优

⚠️重要提示：上述 28K vs 10K 的数据来自 2020 年的特定学术测试场景（边缘网关环境 + 有限 CPU 资源），不代表产品当下的极限性能。在现代云原生部署环境中，通过扩展节点和优化配置，EMQX 单集群可支撑亿级连接，VerneMQ 在数十万连接规模下表现稳定。千万不要拿着这个数据直接代入你自己的项目做容量规划！

三、实测数据多维度汇总

资源消耗部分，Mosquitto 以极致轻量见长，适合嵌入式设备；EMQX 在企业级大规模物联网部署中性能表现最为强悍；VerneMQ 的体验恰好位于中间位置，提供了足够的性能且无功能阉割。

四、性能瓶颈深度剖析

4.1 高连接数场景下的资源消耗

以200万设备在线、每分钟上报1次数据为例，分析资源消耗：

资源消耗差异的主要原因：

• EMQX 的优势在于集群内部路由效率高，消息尽可能在接收节点处理，不必要跨节点转发

• Mosquitto 桥接模式下消息转发路径长，每条消息处理开销大

• VerneMQ 的性能特性则介于两者之间，分片机制有效分担了负载，但跨节点查询会带来额外开销

4.2 CPU/内存与吞吐量的关系

一项 2026 年发表于 CCGrid 的前沿学术研究发现：在 CPU 资源受限的边缘计算环境中，轻量级原生代理可实现亚毫秒级延迟，而功能丰富的企业级平台会带来 2-3 倍的额外开销。多线程代理在高连接负载下能够高效扩展，而 Mosquitto 等单线程代理会较早达到性能饱和。Java 系代理的内存消耗显著高于原生实现。

4.3 QoS等级对性能的影响实测

在1000条消息场景下，分别测试QoS 0/1/2对Broker性能的影响：

物联网场景选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 = on

5.3 性能压测工具

推荐使用下列工具进行压测：

# emqtt-bench（EMQX官方工具，支持三大Broker） ./emqtt_bench pub -t test -h broker.emqx.io -p 1883 -c 1000 -I 10 -q 1 -T 10 # mzbench（VerneMQ推荐工具，支持多种Broker） mzbench --broker-type vernemq --scenario loadtest --concurrency 10000 # JMeter + MQTT插件（XMeter Cloud）

对于边缘计算环境下的系统性性能研究，2026年发表于 CCGrid 的论文中开源的mq-bench统一基准测试框架也值得关注，它能够在相同条件下评估多种 Broker 的性能表现。

六、选型决策树

快速选型表：

七、写在最后

回到开篇的问题：千万设备联网，Broker怎么选？

如果你追求极致轻量，跑在树莓派或路由器上，Mosquitto是不二之选，1MB内存就能跑，稳定可靠。

如果你面对车联网、工业互联网级别的设备量，需要规则引擎、数据持久化、高可用集群——EMQX是目前最成熟的选择，社区活跃、功能完善、性能强悍。

如果你坚定拥抱全开源生态，不接受BSL许可限制，VerneMQ提供了一整套完整的分布式能力和良好的体验，性能足够，文档齐全。

选型的答案永远取决于设备数量、网络环境、运维能力和团队技能。拿起压测工具，用数据说话。

现在，去压测你的Broker吧。

👨‍💻 博主简介：专注物联网架构与高并发消息系统。每天一篇干货，30天带你从小白到专家。点个关注，不错过每一篇硬核内容！