3、MQTT Broker选型：Mosquitto、EMQX、VerneMQ对比，如何选择适合的Broker

说实话，选Broker这事儿，我见过太多人一上来就拍脑袋。

有人觉得Mosquitto轻量，直接上生产。结果设备一多，连接数一上去，Broker直接挂了。也有人迷信EMQX功能全，小项目也硬上，结果运维成本比业务本身还高。

今天我就把这三个主流Broker掰开揉碎讲清楚。你听完，心里就有谱了。

3.1 三款Broker的核心定位

先给个总览，方便你快速建立认知：

嗯，这张表你看完，基本能筛掉一半选项了。

3.2 Mosquitto：轻量级选手，但别太贪心

Mosquitto是我最早接触的Broker。那时候做智能家居原型，设备就几十个，用Mosquitto简直不要太爽。

它最大的优势就是轻。二进制文件几MB，内存占用几十MB，树莓派上都能跑。配置也简单，一个mosquitto.conf文件搞定。

# mosquitto.conf
listener 1883
allow_anonymous true
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log

但我要泼盆冷水。Mosquitto的单机瓶颈很明显。我有个朋友，用Mosquitto接了5000个设备，结果CPU飙到90%，消息延迟从毫秒级变成了秒级。

为什么会这样？因为Mosquitto是单线程模型，连接数一上去，上下文切换开销就爆炸了。

所以我的建议是：

• 适合场景：原型验证、设备数<1000、对高可用没要求
• 不适合场景：大规模生产、需要集群、消息可靠性要求高

3.3 EMQX：工业级选手，功能最全

EMQX是我目前最常用的Broker。说白了，它就是为物联网场景量身定做的。

它基于Erlang/OTP开发，天生就支持高并发和分布式。我记得第一次压测EMQX，单机跑到100万连接，CPU才用了40%。当时我就觉得，这玩意儿靠谱。

EMQX的亮点太多了，我挑几个关键的：

• 规则引擎：可以直接在Broker里做数据过滤、转换、转发。比如设备上报的温度数据，超过阈值直接触发告警，不用再写额外服务。
• 数据桥接：原生支持写入Kafka、InfluxDB、MySQL等。我有个项目，设备数据直接通过EMQX桥接到时序数据库，省掉了一个数据采集服务。
• 热更新：集群扩缩容、配置修改，不用重启。这在生产环境太重要了。

# 创建规则：当温度超过50度时，写入告警主题
SELECT
    payload.temp as temperature,
    clientid
FROM
    "devices/+/sensor"
WHERE
    payload.temp > 50
ACTION
    republish("alerts/high_temp", "application/json")

不过EMQX也不是没缺点。它的配置项太多了，新手容易懵。而且企业版要收费，社区版有些高级功能用不了。

3.4 VerneMQ：高可用场景的硬核选择

VerneMQ，说实话，用的人相对少一些。但它有个绝活——LevelDB持久化。

什么意思呢？就是消息持久化性能极强。我做过对比测试，同样100万条消息持久化，VerneMQ比EMQX快30%左右。

而且VerneMQ的集群架构很特别，它用的是分布式哈希表（DHT），节点之间没有单点故障。你想想看，如果一个节点挂了，其他节点自动接管，客户端几乎无感知。

但VerneMQ的运维门槛确实高。它的配置项比EMQX还多，而且文档写得比较简略。我刚开始用的时候，光是调优集群参数就折腾了两天。

我的建议是：

• 适合场景：对消息持久化要求极高、需要强一致性、运维团队有Erlang经验
• 不适合场景：团队小、运维能力弱、追求快速迭代

3.5 如何选择？我给你一个决策框架

别纠结了，直接按这个流程走：

1. 设备数 < 1000，原型阶段：选Mosquitto。轻量、简单、够用。
2. 设备数 1000~10000，中等规模：选EMQX社区版。功能全、稳定、社区活跃。
3. 设备数 > 10000，大规模生产：选EMQX企业版或VerneMQ。看团队能力，Erlang强就VerneMQ，否则EMQX。
4. 对消息持久化要求极高：优先VerneMQ。它的LevelDB持久化确实强。
5. 需要规则引擎、数据桥接：直接EMQX。这个功能VerneMQ没有。

好了，Broker选型这块就聊到这儿。下一章我们讲讲MQTT的QoS级别，那个坑更多，到时候我好好给你说道说道。