MQTT高并发接入需专用网关而非通用TCP代理，核心是终结TCP连接、解析MQTT报文、维护会话状态（含遗嘱、QoS重传、订阅关系），并协同Broker集群实现负载均衡与会话局部性。
配置TCP代理支持MQTT高并发接入，核心不是简单加一层反向代理，而是构建一个能承载海量设备长连接、维持会话状态、并兼容MQTT协议语义的接入层。普通HTTP代理（如Nginx默认配置）无法直接代理MQTT，因其基于TCP流而非请求-响应模型，且需透传CONNECT、SUBSCRIBE等二进制报文。实际方案中，“TCP代理”通常指MQTT网关或代理前置组件，而非传统Web代理。
明确代理角色：用MQTT Gateway替代通用TCP代理
物联网平台中所谓“TCP代理”，实质是专为MQTT设计的接入网关（MQTT Gateway），它工作在OSI第四层以上，具备协议识别与会话管理能力。它不转发原始TCP字节流，而是：
- 终结设备TCP连接，解析MQTT CONNECT报文，完成身份认证（如accesskey + accesscode校验）
- 维护每个客户端的Session状态（包括遗嘱消息、QoS 1/2重传队列、订阅关系）
- 将设备逻辑连接映射到后端MQTT Broker集群，实现负载均衡与故障隔离
- 支持TLS卸载、IP限速、连接数配额等安全控制
关键配置项与参数调优
以主流开源方案（如EMQX、VerneMQ或自研网关）为例，需重点配置以下参数：
-
监听器配置：启用TCP和SSL/TLS双监听，端口建议8883（MQTTS）或1883（非加密，仅内网）。设置最大连接数（如emqx.conf中
zone.external.max_connections = 1000000） - 连接保活（Keep Alive）：建议设为120–300秒；网关需主动检测心跳超时，并清理僵尸连接
- 会话管理：启用持久化会话（clean session = false），配置会话存储后端（如Redis或内置ETS表），避免Broker重启导致订阅丢失
- QoS分级处理：对QoS 0数据走内存直转，QoS 1/2启用本地确认队列，避免阻塞高吞吐链路
-
主题路由优化：预编译通配符（如
sensors/+/temperature），避免每次SUBSCRIBE都做字符串匹配
与后端Broker协同部署
网关本身不处理消息路由逻辑，需与高可用Broker集群配合：
- 采用集群模式部署Broker（如EMQX Cluster或Mosquitto桥接），节点间同步订阅元数据
- 网关通过一致性哈希或权重轮询，将同一clientid固定分发至某Broker节点，保障会话局部性
- 使用共享存储（如etcd或ZooKeeper）协调集群拓扑变更，确保网关感知节点上下线
- 对百万级设备，建议引入消息流中间件（如Kafka/Pulsar）解耦网关与业务系统，避免Broker直连应用服务
安全与可观测性必须内建
高并发场景下，安全与监控不是附加功能，而是接入层基础能力：
- 强制TLS 1.2+，禁用弱密码套件；支持双向mTLS认证（设备证书由平台CA签发）
- 按产品/设备组配置ACL规则，限制Topic发布/订阅权限（例如只允许
/productA/${deviceName}/event发布） - 暴露Prometheus指标：当前连接数、每秒新建连接、消息吞吐量、P95延迟、认证失败率
- 集成日志审计，记录CONNECT来源IP、clientid、认证结果、首次/末次上线时间
