生产环境做工业物联网消息中枢——设备量大、要高可用集群、要规则引擎自动入库，EMQX 是开源 MQTT broker 的首选（9.0分）；只是边缘网关本地少量设备转发，Mosquitto 更轻；不采 PLC、只做 AMQP 复杂路由或流处理，选 RabbitMQ / Kafka。
01 软件定位与适用场景
EMQX是什么：EMQ（映云科技）旗下的开源分布式MQTT消息服务器，用Erlang/OTP开发，全球开源MQTT broker市场份额领先（约60%+）。单机支持100万+连接，10万+消息/秒，延迟<1ms；分布式集群支持亿级设备连接，自动故障转移，高可用。内置规则引擎（SQL-like语法，数据过滤/转换/聚合）和20+数据集成（MySQL/PostgreSQL/TDengine/InfluxDB/MongoDB/Redis/Kafka/Webhook等）。云原生架构（Docker/K8s Operator/Helm），是工业物联网、车联网、智能家居、智慧城市等场景的消息中间件首选。与Neuron同属EMQ技术栈，Neuron采集+EMQX消息+TDengine存储+Grafana展示是工业物联网全栈最佳实践。
核心设计哲学：①"高可用"——Erlang/OTP的高并发+分布式集群+自动故障转移，电信级可靠性；②"高性能"——单机100万连接，10万消息/秒，延迟<1ms，为IoT海量连接设计；③"云原生"——Docker/K8s/Operator/Helm，适合云原生部署和弹性伸缩；④"万物互联"——MQTT 3.1/3.1.1/5.0全协议支持，QoS 0/1/2，保留消息，遗嘱消息，会话持久化，适合各种IoT设备；⑤"数据集成"——规则引擎+20+连接器，消息可以直接写入数据库/发HTTP/转发Kafka，不用自己写消费端。
- 工业物联网（设备数据采集/远程运维/预测性维护）
- 大规模IoT平台（>1万设备，需要集群/高可用）
- 车联网（T-Box/车机通信/车辆远程控制）
- 智能家居（设备控制/状态上报/场景联动）
- 智慧城市（传感器网络/环境监测/智能照明）
- 实时消息推送（App/小程序/网页实时通知）
- 微服务间异步通信（事件驱动架构/解耦）
- 边缘计算（边缘消息转发/边缘规则引擎）
- 不需要消息队列的简单系统（直接HTTP调用就行，增加复杂度）
- 超小系统（<10设备）——用Mosquitto更轻量，EMQX有点重
- 需要复杂消息路由/编排（主题交换/死信队列/延迟队列）——用RabbitMQ
- 需要事务性消息（分布式事务/消息不丢不重且有序）——用RabbitMQ或RocketMQ
- 大数据/日志/流处理（极高吞吐量/事件溯源/批处理）——用Kafka
- 需要JMS标准（Java消息服务）——用ActiveMQ/RocketMQ
- 对Erlang运维不熟悉且没有企业版支持——出问题可能搞不定
- 需要消息持久化到文件系统——EMQX消息默认内存，持久化需要企业版或外部数据库
02 丁丁的实战体验
用了多久：24个月（2024年10月开始，从EMQX 4.4升级到5.7，经历了5.x大版本重构）
用在哪些项目：
- 设备远程运维（200+设备）：20个工厂，Neuron边缘采集→EMQX消息中转→TDengine存储→Grafana远程监控，EMQX是核心消息总线
- 30台冲床监控：ThingsGateway采集→EMQX→TDengine→Grafana，EMQX做消息解耦（采集层和存储层分离）
- 安灯系统：异常告警通过EMQX实时推送到车间大屏和管理人员手机，EMQX做实时消息推送
- 条码追溯：扫码数据MQTT上报→EMQX规则引擎→写入MySQL，EMQX+规则引擎省去了写消费端的工作
整体感受：EMQX确实是MQTT broker的首选——性能极强（单机100万连接无压力，我们最多用到20万连接，CPU才40%）、稳定性极高（生产环境连续运行半年不重启，没出过一次故障）、功能丰富（规则引擎/数据集成/管理控制台都很好用）、云原生友好（Docker/K8s部署方便）、与Neuron无缝集成（同一家公司，Neuron+EMQX+TDengine全栈方案很成熟）。Dashboard管理界面友好，配置简单，文档完善（中文文档很全，对国内开发者友好）。社区活跃（GitHub 13k+ Star，国内用户多，问题响应快）。
但也有需要注意的地方：规则引擎的SQL语法有学习成本（不是标准SQL，有特殊函数）、QoS 1消息会重复（消费端必须做去重）、集群部署需要注意脑裂问题（要开autoheal+奇数节点）、4.x升级5.x配置不兼容（大版本升级要谨慎）、大量连接时需要调优Linux内核参数（文件句柄/端口/连接跟踪表）。我的经验是：EMQX适合做"消息传输层"，是工业物联网架构的核心基础设施——Neuron/ThingsGateway做采集层，EMQX做消息层，TDengine做存储层，Grafana做展示层，Node-RED做业务流程层，分层架构各司其职，EMQX在中间做消息总线，解耦上下游，是整个架构的"咽喉"。EMQX的评分我给9.0（6款里最高），因为它确实是最成熟、最稳定、最不可或缺的——其他5款都可以有替代，但EMQX在MQTT消息层几乎没有对手（大规模场景下）。
👍 优点
- 全球市场份额领先——开源MQTT broker市场占有率约60%+，社区最大最活跃
- 性能极强——Erlang/OTP开发，单机100万+连接，10万+消息/秒，延迟<1ms
- 分布式集群——多节点自动发现，水平扩展，单集群支持亿级设备连接
- 高可用——自动故障转移，会话持久化，消息队列，生产环境连续运行半年不重启
- 规则引擎强大——SQL-like语法，数据过滤/转换/聚合，内置20+数据集成
- 云原生友好——Docker/K8s Operator/Helm Chart，适合云原生部署和弹性伸缩
- 与Neuron无缝集成——同一家公司（EMQ），Neuron采集+EMQX消息+TDengine存储全栈
- 管理控制台友好——Dashboard可视化监控连接/订阅/主题/规则，REST API完整
👎 缺点
- 规则引擎SQL语法有学习成本——不是标准SQL，有特殊函数和语法，初期写的规则不生效
- MQTT QoS 1消息重复——QoS 1是"至少一次"，网络抖动时重复投递，消费端必须做去重
- 集群脑裂问题——网络分区时集群分裂，两个节点都认为自己是主，需正确配置防脑裂
- 4.x升级5.x配置不兼容——配置文件格式大变，升级后配置全失效，需要重新配置
- 大量连接时Linux端口耗尽——单机10万+连接时，默认端口范围不够，需要调大内核参数
- Erlang虚拟机调优需要经验——VM参数/进程数/缓冲区配置不当会影响性能
- 开源版缺少部分企业功能——数据持久化原生支持/LDAP集成/专业报表在企业版
- 5.x的Dashboard与4.x差异大——老用户需要重新学习，部分功能位置变了
03 核心功能演示
MQTT 3.1 / 3.1.1 / 5.0 全版本支持
QoS 0: 最多一次（可能丢，性能最高）
QoS 1: 至少一次（不丢，可能重复，最常用）
QoS 2: 恰好一次（不丢不重，性能开销大）
保留消息（Retained）: 新订阅者立即收到最新消息
遗嘱消息（Will）: 客户端异常断开时自动发布
会话持久化（Session）: 客户端离线时缓存消息
共享订阅（Shared Subscription）: 多客户端负载均衡消费
TCP: 1883 WebSocket: 8083 SSL/TLS: 8883基于Erlang分布式协议
多节点自动发现（static/dns/etcd/k8s）
水平扩展，单集群亿级连接
自动故障转移，客户端自动重连
会话/路由/订阅自动同步
autoheal: 网络分区恢复后自动愈合
奇数节点: 3/5/7节点，防脑裂
负载均衡: Nginx/HAProxy/NLB分发连接规则引擎三段式:
SQL（SELECT+FROM+WHERE）
→ 动作（Action）
→ 否则动作（Else Action，可选）
SQL示例:
SELECT payload.temperature as temp, clientid
FROM "t/device/+/data"
WHERE payload.temperature > 80
内置变量: clientid/topic/payload/username
常用动作: MySQL/PostgreSQL/TDengine/InfluxDB
MongoDB/Redis/Kafka/HTTP/republish认证方式:
内置数据库: 用户名密码存在EMQX
JWT: Token认证，适合App/小程序
MySQL/PostgreSQL/Redis: 外部数据库
LDAP: 企业LDAP认证（企业版）
HTTP API: 调用外部接口认证
授权（ACL）:
内置ACL: 配置发布/订阅权限
默认策略: deny（白名单，推荐）
每个设备用独立用户名密码
生产环境开启TLS加密04 5个真实踩坑（每个都花了时间和钱）
05 性能实测数据（官方基准+项目验证）
- 官方基准：4核8G服务器，Erlang VM调优，payload 256字节，QoS 0
- 项目验证：设备远程运维项目，4核8G，20万连接，5万消息/秒，CPU约40%，内存约8GB
- 连接数：单机100万+连接需要调优Linux内核参数（文件句柄/端口/连接跟踪表）和Erlang VM参数
- 吞吐量：QoS 0约10万+/秒，QoS 1约5万+/秒，QoS 2约2-3万/秒（QoS越高吞吐量越低）
- 延迟：局域网QoS 0平均<1ms，P99<5ms；公网延迟取决于网络质量（通常20-100ms）
- 集群：3节点集群支持300万+连接，水平扩展近线性（增加节点连接数近似线性增加）
- 结论：EMQX的性能在开源MQTT broker里是顶级的，单机20万连接+5万消息/秒对大多数项目绰绰有余，超过这个规模可以加节点做集群。我们的项目最多用到20万连接，非常稳定，没出过性能问题。
06 vs Mosquitto / RabbitMQ / Kafka 深度对比（10个维度）
| 对比维度 | EMQX | Mosquitto | RabbitMQ | Kafka | 胜出 |
|---|---|---|---|---|---|
| 定位 | 分布式MQTT消息服务器 | 轻量MQTT broker | 多协议消息代理（AMQP为主） | 分布式流平台 | 各有侧重 |
| 开发语言 | Erlang/OTP（高并发） | C语言（极轻量） | Erlang/OTP | Java/Scala | 看场景 |
| 最大连接数 | 100万+（单机） | 1万+（单机） | 10万+（单机） | 不直接支持MQTT | EMQX |
| 消息吞吐量 | 10万+/秒 | 1万+/秒 | 5万+/秒 | 100万+/秒 | Kafka |
| 延迟 | <1ms（极低） | <1ms | 1-5ms | 10-100ms | EMQX/Mosquitto |
| 集群支持 | 强（分布式，亿级） | 无（单节点） | 中（镜像/仲裁队列） | 强（分布式，分区） | EMQX/Kafka |
| 规则引擎 | 强（SQL+20+集成） | 无 | 弱（插件） | 强（Kafka Streams） | EMQX |
| 资源占用 | 中（8-12KB/连接） | 极低（<1MB内存） | 高（Erlang+Mnesia） | 高（JVM+页缓存） | Mosquitto |
| 协议支持 | MQTT 3/5+WebSocket | MQTT 3/5 | AMQP+MQTT+STOMP | Kafka协议（需代理转MQTT） | RabbitMQ |
| 社区规模 | 极大（全球60%+份额） | 大（Eclipse基金会） | 大（Pivotal/VMware） | 极大（Apache顶级） | EMQX/Kafka |
📊 对比总结
EMQX胜出的维度（4项）：最大连接数、规则引擎（IoT场景）、集群+连接数综合、社区规模（MQTT领域）
Mosquitto胜出的维度（2项）：资源占用（极轻量）、延迟（和EMQX并列）
RabbitMQ胜出的维度（2项）：协议支持（AMQP为主+MQTT）、复杂路由/事务
Kafka胜出的维度（2项）：消息吞吐量、大数据/流处理生态
丁丁的结论：这四个不是替代关系，而是不同场景的不同选择：大规模IoT/工业物联网选EMQX（高连接+MQTT+规则引擎），嵌入式/小规模选Mosquitto（极轻量，<100设备），微服务/复杂消息路由选RabbitMQ（AMQP+事务+死信队列），大数据/日志/流处理选Kafka（极高吞吐+事件溯源）。在工业物联网场景，EMQX几乎是唯一选择——Mosquitto撑不住大规模，RabbitMQ的MQTT是插件性能不行，Kafka不直接支持MQTT。我们的项目全用EMQX，非常稳定，没后悔过。
07 选型建议（什么场景选什么）
- 大规模IoT（>1万设备，需要集群/高可用）
- 工业物联网（设备采集/远程运维/预测维护）
- 需要规则引擎/数据集成（消息直接写数据库）
- 云原生部署（Docker/K8s/Operator）
- 车联网/智能家居/智慧城市（海量设备）
- 实时消息推送（App/小程序/网页通知）
- 微服务间异步通信（事件驱动/解耦）
- 需要中文文档和国内社区支持
- 嵌入式/资源受限环境（ARM/<256MB内存）
- 小规模部署（<100设备，不需要集群）
- 只需要基础MQTT转发（不需要规则引擎）
- 边缘网关本地消息中转（配合云端EMQX桥接）
- 测试/开发环境（快速启动，零配置）
- 对内存占用极度敏感（Mosquitto<1MB）
- 不需要管理控制台（命令行配置就行）
- 项目预算为零且不需要企业功能
- RabbitMQ：需要AMQP协议（微服务间通信）
- RabbitMQ：复杂消息路由（主题交换/路由键/headers）
- RabbitMQ：需要事务性消息/死信队列/延迟队列
- RabbitMQ：团队已有Erlang/Java运维经验
- Kafka：大数据/日志/流处理（极高吞吐量）
- Kafka：事件溯源/CQRS/事件驱动架构
- Kafka：需要消息长期存储（天/周级别）
- Kafka：流计算（Kafka Streams/Flink/Spark）
08 部署要点（6步上手指南）
安装EMQX
Docker部署（推荐）：docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 18083:18083 -v emqx-data:/opt/emqx/data -v emqx-etc:/opt/emqx/etc --restart=always emqx/emqx:5.7。端口：1883（MQTT TCP）、8083（MQTT WebSocket）、8084（MQTT WSS）、18083（Dashboard）。二进制部署：从官网下载对应平台安装包，解压后./bin/emqx start。APT/YUM安装：添加EMQ的APT/YUM源。K8s部署：用EMQX Operator或Helm Chart。默认Dashboard账号admin/public，首次登录强制改密码
基础配置
①修改管理员密码——Dashboard登录后（http://服务器IP:18083），系统设置→用户→修改密码；②配置监听器——emqx.conf里配置listeners.tcp.default.bind = 0.0.0.0:1883（MQTT TCP）、listeners.ws.default.bind = 0.0.0.0:8083（WebSocket），生产环境建议开启TLS；③配置集群——单节点不用配，多节点配置cluster.name = emqx-cluster、cluster.discovery_strategy = static（静态节点列表）或dns（DNS发现）；④开启autoheal——cluster.autoheal = true（网络分区恢复后自动愈合，防脑裂）；⑤配置日志——log.level = warning（生产环境，减少日志量）；⑥备份配置——emqx.conf和data目录定期备份
配置认证授权
①内置认证（最简单）——Dashboard→访问控制→认证→创建→选择"内置数据库"→密码哈希方式（sha256/salt）→保存，然后在"用户"里添加用户名密码；②JWT认证（适合App/小程序）——创建认证→选择"JWT"→配置JWT密钥或公钥→配置Token来源→保存；③外部数据库认证——创建认证→选择"MySQL/PostgreSQL/Redis"→配置数据库连接→配置查询SQL→保存；④ACL权限控制——访问控制→授权→创建→配置ACL规则（谁可以发布/订阅哪些主题），默认策略建议设为deny（白名单模式，更安全）；⑤测试认证——用MQTT客户端工具（如MQTTX/mosquitto_pub）测试连接，确认认证和ACL都生效
配置规则引擎
①理解规则引擎三段式——SQL（SELECT字段+FROM事件+WHERE条件）→ 动作（Action，如写入数据库/发HTTP/republish）→ 否则动作（可选）；②创建规则——Dashboard→数据集成→规则→创建→输入SQL→添加动作（如"数据到TDengine"，配置连接器和表映射）→保存；③SQL测试——规则创建页面有"SQL测试"功能，输入模拟的clientid/topic/payload，看执行结果；④常用动作——数据到MySQL/PostgreSQL/TDengine/InfluxDB/MongoDB/Redis、发送HTTP请求、republish、console（调试用）、Kafka生产；⑤规则调试——规则列表里可以看规则的执行统计（命中次数/成功次数/失败次数）；⑥性能优化——规则引擎的SQL尽量简单，动作尽量批量（数据集成支持批量写入）
高可用集群部署
①节点规划——生产环境至少3节点（奇数，防脑裂），节点之间网络延迟<10ms（同机房或同城），不要跨地域部署集群；②节点发现——用static（静态节点列表，在每个节点的emqx.conf里配置cluster.static.seeds）或dns（DNS A记录），生产环境用static最稳定；③负载均衡——客户端连接用负载均衡（Nginx/HAProxy/AWS NLB），把1883端口的TCP连接分发到3个节点，负载均衡器配置健康检查；④会话持久化——EMQX默认会话持久化在内存（节点重启会话丢失），生产环境可以配置会话持久化到外部数据库（如Redis）；⑤脑裂防护——开启cluster.autoheal = true，奇数节点部署，网络双网卡冗余，监控集群节点数；⑥滚动升级——集群升级时逐个节点升级，不要同时升级所有节点
性能调优与运维
①Linux内核调优——文件句柄（ulimit -n 1048576，systemd的LimitNOFILE也要改）、本地端口范围（net.ipv4.ip_local_port_range = 1024 65535）、连接跟踪表（nf_conntrack_max = 1048576）、TCP缓冲区（rmem_max/wmem_max = 16MB）；②Erlang VM调优——emqx.conf里设置node.max_ports = 1048576、node.process_limit = 2097152（进程数上限）、node.fullsweep_after = 1000（GC频率）；③EMQX参数——listeners.tcp.default.max_connections = 1024000（单监听器最大连接数）、zone.external.max_inflight = 32（每个连接最大未确认消息数）；④监控——用EMQX Dashboard或Prometheus（emqx_exporter）+Grafana做可视化监控，关键指标设告警（接入钉钉/邮件）；⑤日志——生产环境日志级别设为warning，日志按天轮转，保留7天；⑥备份——emqx.conf配置文件、data目录定期备份（每天一次，保留7天），升级前必须备份
09 用到EMQX的真实方案
常见问题 FAQ（工程师最常问）
Q：EMQX 是什么？主要用来做什么？
A：EMQ（映云科技）开源的分布式 MQTT 消息服务器，用 Erlang/OTP 开发。主要做工业物联网、车联网、智能家居的海量设备消息接入、转发、规则处理和数据集成，单机支持 100 万以上连接。
Q：EMQX 是免费的吗？开源版和企业版有什么区别？
A：开源，Apache 2.0 协议，可免费商用，核心功能（集群、规则引擎、数据集成）都有。企业版增加 LDAP/SSO 集成、原生数据持久化、专业报表和原厂技术支持。
Q：EMQX 和 Mosquitto 怎么选？
A：大规模、要集群高可用、要规则引擎自动入库，选 EMQX；边缘网关本地、几十到几百设备、资源受限，选 Mosquitto（内存不到 1MB）。
Q：EMQX 单机最多支持多少连接？
A：官方基准为 100 万以上，4核8G 调优后可稳定支持；生产建议单机 10-50 万连接，更多用集群水平扩展。
Q：MQTT QoS 1 消息重复怎么解决？
A：QoS 1 是“至少一次”，网络抖动会重发。消费端做幂等（用唯一 ID 去重），或数据库加唯一索引（INSERT IGNORE）；关键业务用 QoS 2。
Q：EMQX 集群怎么搭？怎么防止脑裂？
A：生产用 3/5/7 奇数节点，静态或 DNS 发现，开启 autoheal（网络恢复后自动重启少数派），节点间用双网卡冗余。
Q：EMQX 能直接把消息写入数据库吗？
A：可以，用规则引擎（SQL 选字段）+ 数据集成动作，支持 MySQL、PostgreSQL、TDengine、InfluxDB、Kafka 等 20 多种，不用自己写消费端。
Q：小项目有必要上 EMQX 吗？
A：单机几十点、不要求集群，用 Mosquitto 或直接写库更简单；但预期会扩展、要规则引擎，EMQX 空闲内存也只有几十 MB，一步到位也可。
🎉 6款核心软件深度评测系列收官！
TDengine（存储）+ Node-RED（流程）+ Grafana（展示）+ ThingsGateway（采集）+ Neuron（高性能采集）+ EMQX（消息），覆盖工业数据采集全链路。需要全栈方案设计/部署/优化/咨询，联系丁丁。
联系丁丁咨询 →