做IoT的人，几乎都要面对mqtt broker集群方案选型这一关。最近有好几个做设备接入的朋友都在问FreeMQTT plus，正好我把这个方案的集群实现，和EMQX、VerneMQ、Mosquitto这些主流通用选型放一起做了次完整对比。这篇文章不玩虚的，直接说清楚每个方案的核心机制、集群能力边界、运维成本和适合场景，帮你判断自己项目到底该选哪个。
先说清楚一件事：MQTT broker集群不是为了炫技，而是连接数、消息吞吐和可用性三者到了单机扛不住的时候，必须走的一条路。但集群不等于把多个broker进程扔在一起，也不等于搞个负载均衡放在前面就完事。如果拓扑、路由同步、会话迁移、消息去重这些底层机制没想明白，上线第一天很可能就是事故现场。
这篇文章适合三类人：一是正在做IoT平台选型的技术负责人，二是已经在跑MQTT服务但遇到单机瓶颈、准备上集群的运维和开发，三是对FreeMQTT plus好奇、想了解它和主流方案差异的架构师。我会从选型指标开始拆解，再逐步深入到每个方案的核心机制和实操细节。
1. 集群选型先想清楚这五个维度，再谈对比
1.1 集群到底解决什么问题
很多人对集群有误解，以为把MQTT broker部署成多副本、前端挂个负载均衡器就是集群。实际这里有两类问题要分开看：一类是解决连接接入的扩展问题，比如单机最多撑10万连接，现在要接50万个设备，需要把连接分散到多台机器上；另一类是解决消息处理的可靠性问题，比如某台机器宕机了，它上面挂着的设备和订阅关系不能全部丢，需要另一台机器接管。
这两类问题对应的集群设计思路是不同的。前者更像开多个收银台，每个台子独立服务一部分顾客，核心是分流；后者更像厨房里的炒菜师傅互为备胎，某个灶台坏了，其他灶台要把活接过去，核心是热备和状态共享。MQTT的集群方案通常要同时处理这两件事，既要转发客户端连接，又要在broker之间同步订阅关系和会话状态。如果在选型时没有把这两层需求拆开想清楚，后面一定会遇到要么扩展性不够、要么故障恢复时间太长的问题。
还要注意，集群引入了新的复杂性，至少包括节点间通信、状态一致性、数据去重和脑裂处理。这些开销在单机模式下是完全不存在的。所以先问自己一句：当前业务是真的需要集群，还是单机加少量调优就能满足？我在评估FreeMQTT plus和主流方案时，第一步永远是看连接规模、消息速率和可用性要求，而不是先选技术栈。这一步想清楚了，后面所有的对比才有意义。
1.2 选型时必须盯住的5个硬指标
实操中，我衡量一个MQTT broker集群方案是否靠谱，主要盯5个指标：连接规模、消息吞吐、可用性、扩展边界、运维成本。下面这个表格是我在选型时固定用的检查清单。
| 指标 | 含义 | 对选型的影响 |
|---|---|---|
| 连接规模 | 单节点和集群能支撑的最大并发TCP连接数 | 决定设备接入层的部署架构和服务器数量 |
| 消息吞吐 | 每秒能处理的发布/订阅消息数，尤其是QoS 1和QoS 2场景 | 决定业务高峰期会不会积压消息 |
| 可用性 | 节点宕机、网络分区时，服务能否继续、恢复耗时多长 | 决定故障对业务的影响面 |
| 扩展边界 | 集群能否横向扩容，扩容时需不需要停服 | 决定未来规模增长时的操作成本 |
| 运维成本 | 部署、监控、升级、排查问题的综合复杂度 | 决定需要多少人力和工具投入 |
连接规模是最容易比出差距的指标。Erlang生态的EMQX、VerneMQ在并发连接处理上有天然优势，单个节点可以撑几十万连接，集群能到百万级；FreeMQTT plus和Mosquitto这类轻量级方案，单节点连接数通常在几万到十几万级别，但在中小规模场景下完全够用。
消息吞吐是另一个容易踩坑的地方。很多方案在连接数上表现很好，但一旦消息体量大、发布频率高，转发链路就开始出现延迟抖动。这里要特别关注QoS 2的语义，因为QoS 2要求端到端的消息不重不漏，实现复杂度远高于QoS 0和QoS 1，集群模式下还需要跨节点去重，对吞吐的影响很明显。
可用性要看两个数字：RTO（恢复时间目标）和RPO（恢复点目标）。有的方案能做到秒级故障转移，但消息会丢一部分，RPO不为零；有的方案强调消息不丢，恢复时间却要几十秒甚至更久。这两者之间是直接权衡，没有十全十美的方案。我见过不少团队上线时只盯着吞吐量，把可用性指标抛在脑后，结果一次半夜宕机直接让全业务停了两个小时。
2. FreeMQTT plus 是怎么实现集群的
2.1 从单机到集群的设计思路
我第一次接触FreeMQTT plus是在一个边缘计算网关项目里，当时需要在一台配置不高的嵌入式服务器上跑轻量级MQTT服务，同时还要和另一台网关形成互备。传统方案EMQX对这种场景偏重，部署包和内存占用都比较大，FreeMQTT plus刚好踩中了这个需求点。
FreeMQTT plus在单机版基础上，主要增强了三个能力：节点间集群通信、会话和订阅信息的同步、以及消息转发路由。它的集群模式走的是去中心化设计，每个节点都是对等的broker，节点之间通过内部协议互相感知。这和EMQX早期的做法有些类似，但实现更轻量，底层不依赖Erlang虚拟机，部署起来简单得多。
它使用了raft协议来维护集群元数据和订阅关系的一致性。这里先解释一下raft，简单来说就是多个节点选出一个leader来负责状态变更，其他节点同步复制，当多数节点确认后这次变更才算成功。这种机制的好处是能保证一致性，坏处是写路径需要跨节点确认，订阅关系的变更响应会有一定的额外延迟。实际使用中，订阅关系变化的频率远低于消息发布的频率，所以这个延迟在绝大多数场景下完全可以接受。
FreeMQTT plus的消息转发不走raft通道，而是走节点间的数据平面直连，这样消息发布路径不会被一致性协议拖慢。也就是说，它把控制平面和数据平面做了分离：控制平面用raft保证订阅关系、会话信息、路由表的一致性；数据平面用高效的消息通道来完成实际的发布订阅转发。这个设计和目前主流分布式消息系统的思路是一致的，也是它能在轻量级前提下保持较好吞吐的原因。
2.2 FreeMQTT plus 的集群搭建实测
FreeMQTT plus的集群搭建是我见过的方案里比较省事的。它支持通过配置文件直接声明集群成员，不需要单独部署注册中心或发现服务。这个设计对中小团队特别友好，少了ZooKeeper或etcd这么一层额外组件，整个系统的运维复杂度一下子降下来了。
下面是一份简化后的集群节点配置参考。三个节点组成一个集群，每个节点配置文件里声明了自己的节点ID、监听地址和集群成员列表：
# 节点1配置示例 node: id: mqtt-node-1 listen: 0.0.0.0:1883 cluster: enabled: true listen: 0.0.0.0:7883 seeds: - mqtt-node-1:7883 - mqtt-node-2:7883 - mqtt-node-3:7883# 节点2配置 node: id: mqtt-node-2 listen: 0.0.0.0:1883 cluster: enabled: true listen: 0.0.0.0:7883 seeds: - mqtt-node-1:7883 - mqtt-node-2:7883 - mqtt-node-3:7883# 节点3配置 node: id: mqtt-node-3 listen: 0.0.0.0:1883 cluster: enabled: true listen: 0.0.0.0:7883 seeds: - mqtt-node-1:7883 - mqtt-node-2:7883 - mqtt-node-3:7883三个节点都配置了同一个seeds列表，启动后会自动发现彼此并尝试建立集群连接。当多数节点（这里是2个）都确认了彼此状态，集群就进入健康运行状态。客户端可以从任意节点接入，不需要区分哪个是入口节点。这个实操下来确实方便，我第一次部署从解压安装包到三节点集群正常收发消息，只用了不到半小时。
验证集群是否正常工作时，最简单的办法是分别从两个不同节点用MQTT客户端建立连接，一个订阅某个主题，另一个向同一主题发布消息，如果消息能正常收到，说明集群路由已经通了。还可以用FreeMQTT plus自带的命令行工具查看节点状态，它会展示每个节点的连接数、订阅数和集群健康状态。
2.3 部署中的注意事项
FreeMQTT plus集群模式部署时有几个细节必须注意。第一个是网络分区场景。raft协议要求多数节点可用才能提供一致性服务，假设三节点集群中有一个节点和其他两个节点网络断开，断开的节点会进入只读状态，不能处理订阅变更和客户端上线。这一点在跨机房部署时要特别小心，如果网络抖动频繁，客户端会不断掉线重连。
第二个细节是客户端会话的粘性问题。MQTT的会话状态分为clean session和persistent session两种。FreeMQTT plus在集群模式下，持久会话的状态会绑定到客户端首次接入的那个节点。如果这个节点宕机了，会话能从其他节点的同步数据中恢复，但恢复过程中客户端需要重新连接，这个切换会有短暂的不可用窗口。
第三个细节是升级顺序。FreeMQTT plus的版本迭代比较快，跨版本升级集群节点时，我建议先在测试环境验证新版本和旧版本的集群通信兼容性，再在线上逐个节点滚动升级。曾经有一次我直接在生产环境升级了其中一个节点，结果新版本的集群协议和旧版本不匹配，导致节点始终无法加入集群，排查了半个小时才发现是版本问题。
3. 主流 MQTT Broker 集群方案横向对比
3.1 四类技术栈的阵营划分
说实话，现在市面上能用于生产环境的MQTT broker集群方案，按底层技术栈划分大概有四个阵营。把这些阵营搞清楚了，选型思路基本就清晰了一半。
第一个阵营是Erlang生态，代表是EMQX和VerneMQ。Erlang天生适合高并发和分布式，进程模型非常轻量，所以这个阵营在连接规模上有天然优势。EMQX目前是社区活跃度最高的方案之一，集群能力成熟，插件生态丰富，国内很多IoT平台都在用它。VerneMQ在消息存储和复制上做过不少优化，但社区活跃度和文档完善程度比EMQX差一些。
第二个阵营是Go生态，FreeMQTT plus、Giotto这类方案都属于这个阵营。Go语言部署简单、并发处理也够用、内存占用低，适合资源受限的边缘场景。FreeMQTT plus算是这个阵营里比较有代表性的轻量级集群方案，尤其适合中小规模接入。
第三个阵营是C/C++生态，代表是Mosquitto和NanoMQ。Mosquitto是Eclipse基金会的项目，单机性能好，但它本身不提供集群功能，要做集群需要自己用负载均衡加共享存储的方式拼装，前提是要接受它相对简单的订阅同步机制。NanoMQ在边缘侧表现不错，资源占用极低，集群模式还在完善中。
第四个阵营是企业级商业方案，代表是HiveMQ。HiveMQ的集群能力很完善，支持大规模部署和跨机房容灾，但授权费用不低，一般中小企业不太会选它作为第一方案。
3.2 对照清单：FreeMQTT plus vs EMQX vs VerneMQ vs Mosquitto
下面这张表是我在多次测试和实际项目基础上整理的对比清单。注意里面有些数字会因硬件配置和测试方法不同而有出入，但相对差异是有参考价值的。
| 维度 | FreeMQTT plus | EMQX | VerneMQ | Mosquitto（自组集群） |
|---|---|---|---|---|
| 单节点连接数 | 5万~10万级 | 50万~100万级 | 50万级 | 1万~5万级 |
| 集群模式 | 内置，raft协议 | 内置，分布式Erlang | 内置，复制协议 | 无原生集群 |
| 消息存储 | 内存 + 可插拔后端 | 内置消息存储 | 内置消息存储 | 内存存储 |
| QoS 2支持 | 支持 | 支持 | 支持 | 支持 |
| 共享订阅 | 支持 | 支持 | 支持 | 需插件 |
| 最小部署节点数 | 3 | 1（单机非集群） | 2 | 需自行组装 |
| 部署包体积 | 小 | 较大 | 中等 | 小 |
| 运维门槛 | 低 | 中 | 中高 | 中（但集群方案复杂） |
| 可观测性 | 基础指标 | 丰富插件和API | 基础+Prometheus | 基础 |
| 跨机房容灾 | 有限支持 | 支持 | 支持 | 较难做 |
| 社区活跃度 | 中等 | 高 | 中 | 高 |
单节点连接数这里要特别说明一下。EMQX能做到百万级连接，主要得益于Erlang的进程模型，每个连接对应一个轻量级进程，内存开销极小。FreeMQTT plus用的是Go的goroutine，连接管理能力也在不断优化，但和Erlang这种为软实时而生的并发模型相比，在超高并发场景下仍然有差距。正常IoT项目做到几万到十几万连接已经很不少了，不需要盲目追求百万级。
消息存储方面，EMQX在4.x时代引入的内置数据库和5.x时代的增强存储机制，让它在消息持久化和重放方面能力更强。FreeMQTT plus走的是内存加可插拔后端的路线，对于需要大量消息落盘的场景会多一些工程工作。共用订阅这个功能很关键，它允许多个客户端实例共同消费同一个主题的消息，是实现负载均衡消费的必备能力。据我测试，FreeMQTT plus和EMQX的共享订阅都支持得不错，Mosquitto的共享订阅从2.0版本成为正式特性后才相对好用。
3.3 几个最容易被忽略的差异点
除了表格里的显性指标，有几个隐性差异点是真正会在生产环境里坑人的，值得单独拿出来说。
第一个是节点间消息转发的效率和去重机制。MQTT集群里，当客户端A连在节点1上，订阅了主题T，客户端B连在节点2上向主题T发布消息时，节点2需要把消息转发给节点1，再由节点1推送给A。这个跨节点转发的路径如果实现不高效，消息延迟和数据传输量都会明显增加。EMQX的分布式Erlang底层有成熟的节点通信机制，转发路径相对稳定；FreeMQTT plus的数据平面直连设计也够用，但在节点数量较多时，路由表和转发路径的管理会更复杂。
第二个是持久化会话的迁移策略。MQTT协议规定，持久会话在客户端断开后要保持消息和订阅状态。集群模式下这个状态放哪里、如何迁移，直接决定了客户端重连的体验。EMQX提供了会话的分布式存储能力，客户端从任意节点重连都能恢复会话；FreeMQTT plus采用绑定初始节点的策略，故障切换时会有短暂的重连窗口；Mosquitto的自组集群模式要处理持久会话，基本只能靠共享后端存储，而Mosquitto本身提供的会话状态同步能力很弱。
第三个是共享订阅的负载均衡策略。共享订阅支持轮询、随机、哈希等多种策略，不同策略对消息分配的影响很大。EMQX支持多种分配策略，并且可以在主题级别配置；FreeMQTT plus在共享订阅的灵活度上稍逊一筹，但基础的轮询和哈希都用得起。如果业务对消息消费顺序有严格要求，需要注意哈希策略能保证同一客户端ID的会话消息总是发给同一个订阅者，轮询则不保证。
第四个是权限和鉴权的集群统一管理。MQTT服务在规模上来之后，ACL（访问控制列表）和客户端认证信息需要跨节点统一。EMQX可以通过内置数据库或外部数据库统一维护ACL，FreeMQTT plus也支持集成外部数据库做集中认证，但配置步骤上会多一点工作。选型时一定要把权限管理方式问清楚，否则几十个节点各自维护一份ACL表，很快就乱套了。
4. 场景化选型：到底该用哪一个MQTT集群方案
4.1 设备量大、高并发场景优先看EMQX和VerneMQ
如果你的业务需要支撑的设备连接量在几十万甚至百万以上，比如大型车联网平台、智慧城市级别的物联网中台，选型重点应该放在连接能力和集群成熟度上。EMQX几乎是最稳妥的选择，它的百万连接、热升级、共享订阅、规则引擎都是经过大规模生产环境验证的。VerneMQ在连接规模上也不差，而且它对MQTT协议的实现很完整，尤其适合对消息吞吐有苛刻要求的团队，但它的社区生态和可观测性建设相对EMQX弱一些，排障时能参考的资料少。
这个场景下我不建议选FreeMQTT plus或Mosquitto自组集群。FreeMQTT plus的连接规模上限决定了它更适合中小场景，硬要往大规模上凑的话，可能需要部署多套集群，然后在上层做主题或设备维度的路由拆分，这个架构复杂度远高于直接上一套大集群。我自己见过一个团队用Mosquitto拼了个粗略的集群方案，上线初期没问题，到设备量涨到预期规模一半时，订阅同步带来的消息丢失和重复问题开始集中爆发，最后只能半夜紧急迁移到EMQX。这种推倒重来式的返工成本，比一开始选型多花一周时间要高得多。
4.2 边缘网关和嵌入式场景选Mosquitto或NanoMQ
在边缘网关、智能网关、工控设备、开发板这类资源受限的环境里，Mosquitto和NanoMQ仍然是最合适的选择。它们部署包极小、内存占用低，单机就能在小型设备上稳定跑很久。而且边缘节点通常不是集群的重点，因为边缘侧设备量小，一台网关扛几百上千个连接是常态，不需要为了连接规模去构建复杂集群。边缘节点如果要做高可用，一般是通过主备切换加虚拟IP的方式实现，而不是做分布式集群。
在这个场景里引入集群是完全没必要的。我见过有人在一台树莓派上部署了三节点的集群，跑起来之后内存直接爆掉，这就是典型的没有评估资源就盲目上复杂方案。边缘侧真正需要的是轻量、稳定、容易维护，FreeMQTT plus同样适合边缘侧部署，它的资源占用比Mosquitto高一些，但比EMQX低很多，用在性能稍好的边缘服务器上是完全可以的。如果你在边缘侧有多个节点需要互备，FreeMQTT plus的集群能力会是一个额外的加分项，因为它至少有一个原生方案能实现节点间状态同步。
4.3 中小型IoT平台优先考虑FreeMQTT plus
对绝大多数中小型IoT平台、智能硬件创业公司、工厂内部数据采集系统来说，FreeMQTT plus属于那种“配置刚刚好”的方案。假设你的设备量在几千到几万台之间，消息速率在每秒几百到几千条，需要2到3个节点组成高可用集群，同时团队没有专门的MQTT运维专家，FreeMQTT plus的低运维门槛优势会非常明显。
我团队做过一个实际项目，业务是工厂设备的实时状态采集，设备总量大概1.2万台，高峰时每秒钟产生1500条左右的消息。当时评估了EMQX和FreeMQTT plus两个方案，EMQX各项能力都更强，但部署和运维需要专门的Erlang知识背景；FreeMQTT plus三节点集群只花了一天就部署完，运行了大半年基本没出过需要人工介入的问题。消息端到端延迟在5毫秒以内，集群的CPU和内存占用也始终维持在一个很低的水平。
当然，选FreeMQTT plus就要接受它的一些局限，比如跨机房容灾能力有限、官方文档和社区资源不如EMQX丰富、扩展功能的生态还需要自己积累。但这些局限在中小场景下通常不会成为瓶颈。
4.4 企业级高合规需求选HiveMQ或EMQX企业版
最后一个场景是金融、能源、政务这类对合规、审计、SLA有硬性要求的企业级项目。这类项目的特点是不差钱，但对稳定性和支持服务要求极高。HiveMQ在企业级市场深耕多年，集群能力、安全机制、审计日志都很完善，还提供商业技术支持，选它基本不会出错。EMQX企业版在国内市场做得也不错，针对国产物联网场景有大量优化，团队响应速度快，而且支持国产化环境部署，这些都是很多央企和国企客户非常看重的点。
FreeMQTT plus和社区版EMQX在这个场景里会比较吃亏，主要缺少企业级的支持服务和严格的性能保障承诺。不是说社区方案技术不行，而是出了问题没有人给你兜底，也没有SLA赔付机制，这在企业采购流程里是硬伤。
4.5 选型决策的实操路径
我在选型时根据自己的经历设计了一套比较实用的决策路径，可以参考一下：先明确设备连接数和消息QPS的预期峰值；再梳理可用性要求，确定RTO/RPO指标；然后看团队已有的技术栈和运维能力；最后才是上手做POC（概念验证）测试。
其中POC这一步最容易偷懒，但也最不应该偷懒。我建议至少做三轮验证：第一轮用官方压测工具测吞吐量和连接数；第二轮模拟节点宕机，观察故障恢复耗时和消息丢失情况；第三轮跑一周稳定性测试，观察内存泄漏、CPU波动和日志输出情况。同一套测试流程跑完所有备选方案，用数据说话，而不是凭着网上的口碑和别人的经验做决定。把这三轮测试结果和运维门槛、商业成本放在一起一对比，选型结论基本就是水到渠成的事情。
5. 常见坑位与排查实录
5.1 客户端连接总被负载均衡踢掉的坑
不少团队用FreeMQTT plus集群时，会在前端加一台负载均衡器分发客户端连接。最常见的故障现象是客户端连接建立后，每隔一段时间就会被断开重连，表现像是被踢掉。排查一圈下来发现，问题出在负载均衡器的空闲超时时间上。MQTT连接建立之后如果客户端没有消息往来，连接处于空闲状态，此时负载均衡器默认的空闲超时机制会切断连接，而客户端没有及时感知，重新订阅就会失败。解决方案很简单，把负载均衡器针对MQTT端口的空闲超时时间调大，或者在客户端开启MQTT的心跳保活机制，并确保心跳间隔小于负载均衡器的超时时间。
这里要注意的是，MQTT的心跳协议是应用层的心跳，负载均衡器不一定能感知到。有些四层负载均衡器会把TCP层面的活动也看作连接活跃，有些则只看是否有数据包通过，不同产品的行为不一致。所以最好在部署环境里做一次长连接稳定性验证，连续跑24小时甚至48小时，观察有没有被踢掉的连接。
5.2 节点间状态不同步导致的重复消息
我在测试FreeMQTT plus集群时遇到过一个问题：客户端A订阅主题T，客户端B向主题T发布消息，正常情况下消息只应该被推送一次。但有时候订阅端的消费者会连续收到两条相同内容的消息。深入排查后发现，这是由于客户端A在连接断开后快速重连，而重连过程中节点间的订阅关系同步还没有完全收敛，导致新旧两个节点都认为自己是这个订阅关系的负责节点，同一份消息就被转发了两份。
这是分布式系统中比较典型的“脑裂”场景。解决的思路有两个方向：一是从客户端做幂等处理，消费者根据消息ID或业务主键去重；二是从服务端调整，确保客户端重连时，旧节点上的订阅关系能够被新节点正确接管并清理。FreeMQTT plus在后续版本中优化了会话迁移逻辑，但作为使用方，我们不可能完全依赖服务端，在消费端做幂等处理仍然是最稳妥的兜底方案。
5.3 集群节点掉线后不能自动恢复
另一个踩过的坑是集群中的一个节点因网络抖动和另外两个节点失联，网络恢复后它一直处于“重连中”状态，始终不能自动加入集群。排查发现是和节点ID相关的。FreeMQTT plus的集群依赖节点ID来识别成员，如果节点重启时ID发生了变化（例如某些虚拟化环境下主机名变化导致默认生成的ID改变），其他节点就会把它当作一个不认识的节点，拒绝它加入集群。
解决办法是给每个节点指定固定的节点ID，建议直接配置成有业务意义的名称，比如mqtt-node-01、mqtt-node-02，避免依赖自动生成。同时，迁移容器或虚拟机时要注意保留配置文件和持久化数据目录，否则节点ID变更会导致集群成员不识别。这类问题在EMQX集群里同样存在，EMQX的节点名机制也要求升级或迁移时保持一致。
5.4 网络分区的选择：可用性还是一致性
最后一个想重点谈的坑是网络分区时的行为差异。MQTT集群在跨机房部署时，最怕的就是两个机房之间的专线抖动，导致集群被分成两半。此时不同方案的表现差异很大。EMQX在默认配置下会尽可能保持服务的可用性，代价是可能出现消息冲突和需要之后的人工协调；FreeMQTT plus因为使用了raft协议，在分区场景下会倾向于保证一致性，只有多数派那一边的节点能继续正常服务，少数派节点虽然还能接受客户端连接，但无法处理订阅变更和持久会话建立，客户端连上去之后往往会发现什么都干不了。
这个选择本身没有绝对的对错，取决于业务诉求。如果业务更看重任何时候都能发布消息，要选偏向可用性的方案并处理好冲突；如果业务更看重消息不能错不能乱，FreeMQTT plus这种强一致性的做法反而更合适。关键是选型前要和业务方明确这个权衡，不要等到网络抖动发生了才发现两边预期不一致，那才是真正的灾难。
根据我个人经验，MQTT broker集群选型最怕的不是技术差距，而是需求定义不清楚。先把预期规模和可用性指标定下来，再用统一的方法做POC验证，同时一定要考虑到自己能投入的运维精力，最后选出来的方案不一定是参数最漂亮的，但一定是最适合自己的。FreeMQTT plus在中小规模高可用场景里表现超出了我的预期，尤其是它的低运维门槛和内置集群能力，让一个三人小组也能轻松维护一套生产级别的MQTT服务，这一点是很多大型方案反而不具备的优势。
