目录
1.为什么要设计分布式扩展?
随着 IoT 设备数量的增加,单个服务器处理能力是有限的。如果继续用单机架构来应对高并发,服务器可能会出现 瓶颈,影响稳定性、性能。
解决方案:通过 分布式架构,将设备负载分散到多台服务器,使用合适的 负载均衡 和 路由策略,确保系统能随着设备量增加水平扩展!
2.设计目标
目标 | 描述 |
高可用(HA) | 任一节点宕机不影响设备通信 |
高并发(Million Level) | 支持百万级设备稳定在线,消息并发处理 |
可横向扩展 | 按需扩容 Broker、消息处理、状态存储等 |
状态一致性强 | 实时感知设备上线/离线,状态同步及时 |
延迟低、吞吐高 | 毫秒级响应,百万条/秒数据收发能力 |
3.分布式扩展的核心设计要素
(1)负载均衡 将设备请求按某种方式分配到多台服务器,避免单个服务器过载。
(2)设备ID路由 设备请求需要根据设备ID进行分配,让同一个设备的请求总是路由到同一个服务器。
(3)状态同步 设备与服务器的状态需要在多节点间同步,比如设备是否在线、设备的心跳状态等。
(4)高可用与容错 如果某台服务器挂掉,其他服务器可以接管任务,确保无单点故障。
4.系统架构概览
+-----------------------------+
| Load Balancer |
+-----------------------------+
|
+----------------+----------------+
| | |
+-----------+ +-----------+ +-----------+
| Broker A | | Broker B | | Broker C | ← MQTT / TCP 网关集群
+-----------+ +-----------+ +-----------+
| | |
| | |
+-------------------------------------------------+
| Message Bus (Kafka/NATS) |
+-------------------------------------------------+
| | |
+-------------+ +--------------+ +---------------+
| SessionMgr | | DataWorker | | ControlWorker | ← 消息异步处理服务集群
+-------------+ +--------------+ +---------------+
|
+---------------------------+
| Redis / MySQL / MongoDB | ← 状态存储、消息持久化
+---------------------------+
5.通信层(MQTT/TCP 网关)
5.1 推荐使用:
-
EMQX、Mosquitto、VerneMQ(支持集群,百万连接稳定)
-
或自研 Netty-based TCP/MQTT Server,具备连接层负载能力
5.2 扩展策略:
项目 | 推荐配置 |
Broker 节点 | 每台 Broker 支持 5W~10W 设备连接 |
节点数量估算 | 100 万设备需部署 20~40 个节点 |
LB层 | 使用 Nginx/HAProxy + |