2. Broker 选型：Mosquitto、EMQX、NanoMQ、VerneMQ 对比与适用场景

选 Broker 这件事，说实话比选语言框架还让人头疼。我见过不少团队，一上来就奔着“功能最全”的去，结果部署后发现资源吃紧，运维成本还高。也有团队图省事用轻量级的，业务一膨胀就扛不住了。

今天我把市面上最主流的四个 MQTT Broker——Mosquitto、EMQX、NanoMQ、VerneMQ——掰开揉碎讲清楚。你想想看，选对了 Broker，后面做主题授权和策略配置才能事半功倍。

2.1 四款 Broker 的定位速览

先给个全景图，方便你快速建立认知。

2.2 Mosquitto：轻量级单机首选

Mosquitto 是 Eclipse 基金会下的老牌 Broker，C 语言实现，体积极小。我个人习惯在开发环境或原型验证阶段用它，编译完才几百 KB，跑起来内存占用也就十几 MB。

核心特点：

• 支持 MQTT 3.1.1 和 5.0 协议
• 基于文件的密码认证和 ACL 授权
• 单线程事件驱动模型
• 不支持集群

它的授权配置非常直观，直接改 mosquitto.conf 就行：

# 开启密码认证
password_file /etc/mosquitto/passwd
# 开启 ACL 文件
acl_file /etc/mosquitto/acl
# 禁止匿名访问
allow_anonymous false

ACL 文件写法也很简单：

# 用户 sensor1 可以发布到 sensors/temperature
user sensor1
topic write sensors/temperature

# 用户 admin 可以订阅所有以 admin/ 开头的主题
user admin
topic read admin/#

适用场景：

• 开发测试环境
• 智能家居网关（连接设备数 < 1000）
• 树莓派等嵌入式设备

2.3 EMQX：企业级高可用标杆

EMQX 是目前国内用得最多的 MQTT Broker，Erlang/OTP 实现。我参与过的几个车联网项目，无一例外都选了它。为什么？因为它把“高可用”和“可扩展”做到了极致。

核心特点：

• 原生支持集群，水平扩展无上限
• 内置强大的规则引擎和钩子系统
• 支持基于 SQL 的动态主题授权
• 丰富的认证方式：JWT、LDAP、HTTP、MySQL、Redis、MongoDB
• 企业版支持热配置和热升级

它的授权配置非常灵活，可以通过 Dashboard 或 API 动态管理。举个例子，用 HTTP 认证插件实现动态授权：

# emqx.conf 中配置 HTTP 认证
auth.http.auth_req = http://192.168.1.100:8080/auth
auth.http.auth_req.method = post
auth.http.auth_req.params = clientid=%c,username=%u,password=%P

# 授权请求
auth.http.acl_req = http://192.168.1.100:8080/acl
auth.http.acl_req.method = get
auth.http.acl_req.params = clientid=%c,username=%u,topic=%t,action=%a

后端返回 {"result": "allow"} 或 {"result": "deny"} 即可。这种模式的好处是——授权逻辑完全由业务系统控制，可以实现非常复杂的策略。

适用场景：

• 物联网平台（百万级设备接入）
• 车联网（TSP 平台）
• 工业互联网（SCADA 数据采集）
• 金融、能源等对可用性要求极高的场景

2.4 NanoMQ：边缘计算的轻骑兵

NanoMQ 是 EMQ 公司推出的边缘侧 Broker，C 语言实现，目标是“在资源受限的设备上跑出高性能”。我第一次看到它的 benchmark 时还挺惊讶的——在树莓派上能跑到 10 万 TPS。

核心特点：

• 极致轻量：二进制不到 1MB，内存占用 5MB 起步
• 支持 MQTT 5.0、WebSocket、HTTP
• 内置规则引擎和桥接功能
• 支持与 EMQX 云端无缝对接
• 支持 DDS 协议转换（工业场景）

它的授权配置风格和 Mosquitto 类似，但更灵活：

# nanomq.conf
auth.allow_anonymous = false
auth.password_file = /etc/nanomq/passwd
auth.acl_file = /etc/nanomq/acl.conf

# ACL 规则支持通配符和变量
acl {
  permission = allow
  action = subscribe
  topic = "device/${clientid}/#"
}

适用场景：

• 边缘计算网关
• 工业 PLC 数据采集
• 车载 T-Box
• 智能楼宇控制器

2.5 VerneMQ：高并发多租户利器

VerneMQ 也是 Erlang 实现，但它和 EMQX 的定位不太一样。EMQX 强在“平台级”的完整生态，VerneMQ 则更专注于“消息中间件”本身，尤其在高并发和多租户隔离方面做得非常出色。

核心特点：

• LevelDB 作为消息持久化引擎，写入性能极高
• 原生支持多租户隔离（通过 mountpoint 机制）
• 支持在线配置修改（不需要重启）
• 内置分布式会话存储
• 支持 Live Upgrade（热升级）

它的多租户授权配置很有意思：

# vernemq.conf
# 开启多租户模式
allow_multiple_sessions = on

# 每个租户使用独立的 mountpoint
mountpoint = /tenants/${tenant_id}/

# 授权使用 VMQ 的 ACL 链
plugins.vmq_acl = on
plugins.vmq_acl.file = /etc/vernemq/acl

ACL 文件支持层级和变量：

# 租户 A 只能操作自己的主题空间
[tenant_a]
topic read /tenants/tenant_a/#
topic write /tenants/tenant_a/#

# 管理员可以操作所有租户
[admin]
topic read /tenants/#
topic write /tenants/#

适用场景：

• SaaS 物联网平台（多租户）
• 消息中间件（高吞吐量消息分发）
• 金融交易系统（低延迟、高可靠）
• 需要热升级的 7x24 小时服务

2.6 横向对比：一张表说清楚

维度	Mosquitto	EMQX	NanoMQ	VerneMQ
实现语言	C	Erlang	C	Erlang
二进制大小	~500KB	~50MB	~1MB	~40MB
内存占用（1K 连接）	~20MB	~100MB	~10MB	~80MB
单机吞吐量	~50K TPS	~500K TPS	~100K TPS	~300K TPS
集群支持	❌	✅ 原生	✅ 桥接	✅ 原生
动态授权	❌ 文件静态	✅ HTTP/DB/API	✅ 文件+变量	✅ 文件+API
多租户隔离	❌	✅ 规则引擎	❌	✅ mountpoint
运维复杂度	低	中高	低	中
协议支持	MQTT 3.1.1/5.0	MQTT+CoAP+HTTP+WebSocket	MQTT+WebSocket+DDS	MQTT+WebSocket

2.7 我的选型建议

说了这么多，到底怎么选？我根据实际项目经验，给你几个参考路径：

• 个人学习 / 原型验证：Mosquitto，零成本上手，ACL 配置简单直接。
• 边缘设备 / 资源受限：NanoMQ，轻量且功能完整，还能和云端 EMQX 桥接。
• 企业级物联网平台：EMQX，生态最完善，授权策略最灵活，运维工具也最成熟。
• 高并发消息中间件 / 多租户 SaaS：VerneMQ，LevelDB 的写入性能和 mountpoint 隔离机制是杀手锏。