📚 课程目录第4章集群架构设计

4. 集群架构设计

核心原理：三种集群模式的本质差异

MQTT 集群架构设计的首要任务是回答“节点之间如何协作”。根据消息存储与转发方式的不同，主流方案可归纳为三种模式：主从模式（Master-Slave）、镜像模式（Mirror/Replication）与分布式模式（Distributed/Sharding）。理解它们的本质差异，是后续选型的基础。

主从模式：仅一个主节点（Master）负责处理客户端连接与消息路由，从节点（Slave）作为热备或冷备。主节点故障时，从节点提升为新主节点。此模式实现简单，但集群整体写入吞吐受限于单节点，且故障切换期间存在短暂不可用窗口。
镜像模式：每个节点都保存完整的主题树与消息副本（或至少保存同一份会话状态）。任意节点均可处理订阅与发布，节点间实时同步会话与 retained 消息。此模式读扩展性好，但写放大明显——每条消息需广播至所有镜像节点。
分布式模式：按主题（Topic）或客户端 ID 哈希将消息路由到特定分片节点，每个节点只负责一部分主题的存储与转发。此模式扩展性最佳，但需要引入路由层或使用支持原生分片的 Broker（如 EMQX 的集群分区策略）。

下图直观展示了三种模式在“消息存储位置”与“客户端连接方式”上的核心区别：

方法流程：从需求到架构选型

设计集群架构时，建议按以下流程逐步决策，避免直接套用模板：

量化规模与延迟目标：统计设备连接数、消息 TPS（每秒消息数）、单条消息大小、允许的最大端到端延迟。例如：10 万设备、峰值 5 万 TPS、延迟 < 100ms。
评估一致性要求：是否允许消息丢失？是否要求会话状态严格一致？若允许少量丢失且追求低延迟，分布式模式更合适；若必须严格一致（如指令下发场景），镜像模式更稳妥。
选择集群模式：连接数 < 5 万且对成本敏感，可选用主从 + 负载均衡；连接数 > 10 万且消息量随业务线性增长，优先考虑分布式分片；若业务以广播为主（如车联网向全车队下发指令），镜像模式能提供更好的读扩展。
设计负载均衡策略：在集群前端部署负载均衡器（如 Nginx、HAProxy 或云负载均衡），需支持 MQTT 的 TCP 长连接与 WebSocket 升级。常用策略包括：轮询（简单但无法感知节点负载）、最少连接数（适合长连接场景）、IP 哈希（保证同一客户端固定连接到同一节点，便于会话保持）。
规划高可用切换机制：对于主从模式，需配置健康检查与自动故障转移（如 Keepalived + VIP）；对于镜像/分布式模式，需依赖 Broker 自带的集群脑裂检测与自动恢复机制。

负载均衡配置示例（HAProxy 前端代理 MQTT 流量）

frontend mqtt_frontend
    bind *:1883
    mode tcp
    default_backend mqtt_servers

backend mqtt_servers
    mode tcp
    balance leastconn
    option tcp-check
    server node1 192.168.1.11:1883 check inter 3s fall 2 rise 2
    server node2 192.168.1.12:1883 check inter 3s fall 2 rise 2
    server node3 192.168.1.13:1883 check inter 3s fall 2 rise 2

案例/场景：车联网平台集群设计

某车联网平台需接入 20 万辆网联汽车，每辆车每秒上报一次 GPS 与电池状态（约 200 字节），同时支持云端向指定车辆下发远程控制指令。业务特点为：高并发写入（车辆数据上报）、低频精准下发（控制指令）、需要保留车辆最新状态（retained 消息）。

最终架构采用分布式分片 + 镜像混合方案：

将车辆按 VIN 码哈希 分为 4 个分片，每个分片由一对主从节点组成（主节点负责写入，从节点实时备份）。
车辆上报数据直接写入所属分片的主节点，从节点异步复制，保证数据不丢失。
控制指令通过负载均衡器转发到对应分片的主节点，确保指令顺序与实时性。
每个分片内部使用 retained message 存储车辆最新状态，客户端订阅时直接获取。

该设计将消息压力分散到 4 个分片，单分片 TPS 约 1.25 万，远低于单节点瓶颈；同时主从备份保证了任一节点宕机时，从节点可在 5 秒内完成切换，业务无感知。

误区/复盘：常见设计陷阱

误区一：盲目追求“全镜像”导致写放大

曾有一个智慧城市项目，初期采用 5 节点全镜像模式，每条消息需复制 5 份。当消息量增长到 3 万 TPS 时，网络带宽被同步流量占满，消息延迟飙升至 2 秒以上。复盘发现，业务中 80% 的消息是单设备遥测数据，根本不需要全量复制。改为按主题前缀分片后，写放大系数从 5 降为 1.2，延迟恢复至 50ms 以内。

误区二：忽略负载均衡层的会话保持

某项目使用轮询策略分发 MQTT 连接，但未开启会话保持。客户端频繁重连到不同节点，导致 Broker 反复重建会话、同步遗嘱消息，集群 CPU 飙升。正确做法是采用 IP 哈希 或 一致性哈希，确保同一客户端固定访问同一节点，除非该节点故障。

复盘要点：集群设计不是“选一个模式”就结束，而是需要结合消息特征（广播 vs 点对点）、一致性要求、扩展预期综合权衡。建议上线前用 mqtt-benchmark 工具模拟真实流量，分别测试主从切换时间、镜像同步延迟、分片均衡度三个关键指标。

高可用设计清单

层级	关键措施	验证方法
网络层	负载均衡器双机热备（Keepalived + VIP）	手动 kill 主 LB，观察 VIP 漂移时间
Broker 节点	主从自动故障转移 / 分片副本自动提升	停掉一个节点，验证客户端重连与消息恢复
数据层	retained 消息与 session 数据持久化到磁盘	重启节点后检查 retained 消息是否完整
客户端侧	客户端配置多个 Broker 地址，自动重连	断网 30 秒，观察客户端自动切换

高可用设计的核心是消除单点，但也要避免过度冗余带来的成本与复杂度。建议每季度进行一次故障演练，记录实际切换时间，持续优化健康检查参数与超时阈值。