MQTT的会话保持，本质上是让Broker（消息服务器）替你保存订阅关系和未发送的消息；对于海量设备接入的场景，正确的做法是分层管理会话：按设备类型差异化设置心跳间隔，按业务重要性决定是否开启清理会话标志，再配合QoS级别控制消息积压，这样既能保证连接稳定，又不会拖垮服务器。
MQTT会话保持机制到底解决了什么问题
海量设备接入时,最先暴露出来的问题不是“消息发得慢”，而是“连接根本挂不住”，设备一多，网络抖动、弱网环境、服务器过载都会导致连接频繁掉落，如果每次掉线后，设备都要重新订阅主题、重新登记状态，那服务器就成了纯粹的“加解密机器”，数据还没转发出去，CPU先被握手请求打满了。
理解MQTT会话保持的三个核心概念
会话（Session）：客户端和Broker之间的一次逻辑连接状态，MQTT协议规定，从客户端发出CONNECT报文开始，到Broker收到DISCONNECT报文为止，这之间产生的订阅关系、未确认消息都属于会话的一部分，会话可以跨网络连接存在，也就是说，哪怕TCP断了，Broker依然可以把会话保存下来，等设备下次重连时直接恢复。
心跳（Keep Alive）：客户端在建立连接时必须协商一个心跳周期（单位是秒），在这个周期内，客户端至少要发送一次报文（哪怕是PINGREQ），Broker如果在5倍的心跳周期内没有收到任何报文，就判定连接已死，直接断开并清理资源。
遗嘱（Will Message）：客户端在连接时可以带上一条“遗言”，告诉Broker：“我如果异常掉线了，帮我给某个主题发这段话。”这在设备状态监控中非常实用，规则引擎可以据此判断设备下线了。
会话状态里到底存了什么
一个完整的MQTT会话状态,包含了这些内容：
- 客户端的订阅关系：订阅了哪些主题，用的什么QoS。
- QoS 1和QoS 2级别的未确认消息：设备掉线时还没发出去的确认消息，重连后继续补发。
- Broker待发往离线客户端的消息队列：设备离线期间，Broker暂时保管这些消息，等设备上线后推送。
这里有个容易踩坑的点：QoS 0的消息是即发即弃的，不管会话是否存在，Broker都不会替它缓存，如果业务要求“离线也能收到最新状态”，那么至少要用QoS 1，并保证会话标志是关闭清理的。
海量设备接入时，会话保持参数怎么配置
心跳时间的设置：从网络环境出发
海量设备接入时,心跳时间不能一刀切，一套参数走天下，必然会牺牲一大半设备的连接体验。
- 4G/5G移动网络环境下的设备（如共享充电宝、车载定位器），NAT映射表空闲超时时间一般在30秒到60秒之间，心跳间隔建议设置在15到30秒之间，既能保住NAT映射，又不至于让空包比例太高。
- 家庭宽带或企业专网环境下的设备（如智能家居网关、边缘计算盒子），网络稳定性较好，可以将心跳拉到
60秒甚至120秒
，大幅降低服务器的心跳报文处理压力。
业内专家指出,设备基数过万时，心跳报文几乎占到了服务器报文总量的六成。能调长一点就调长一点，前提是你要理解网络链路中间设备的淘汰机制。
cleanSession（清理会话）的选择策略
这个标志位决定了设备断线后,Broker是否保留会话状态，在海量设备场景下，粗暴地全选1或全选0都会出问题。
- cleanSession=1（清理会话）：设备每次连接都从零开始，省内存，但设备重连后必须重新订阅所有主题，在弱网环境下会造成频繁的流量放大。
- cleanSession=0（持久会话）：Broker保留订阅关系和离线消息队列，设备重连后只需要带相同的ClientID，Broker会自动恢复上下文。
建议这样分：交互频繁、对状态敏感的设备（如控制类设备、需要同步下发配置的网关）使用持久会话；上报型设备（如只定时发一次温湿度数据的传感器）使用清理会话，能显著降低Broker的内存压力。
QoS与消息堆积处理
QoS级别的选择,要跟会话保持一起看，用错级别，等于把会话保持变成定时炸弹。
| 场景 | 推荐QoS | 原因 |
|---|---|---|
| 环境监测数据上报 | QoS 0 | 丢几条数据无关紧要，还能省大量带宽 |
| 控制指令下发 | QoS 1 | 至少要保证Broker收到，且设备能收到一次 |
| 计费/告警消息 | QoS 2 | 绝对不允许重复，也不允许丢失 |
但要注意：持久会话 + QoS 1/2 意味着消息会在Broker的队列里“躺着”等待设备领取，如果设备长时间离线，Broker的消息积压会吃掉内存，应对措施是，在Broker端配置单会话最大消息积压数（超过则丢弃最早的），这个参数在EMQX里叫max_mqueue_len，在Mosquitto里叫max_queued_messages，线上跑批时，普遍设置为100到500条之间，避免一台离线设备拖垮整个节点。
MQTT会话保持的方案选型与成本对比
HTTP长轮询和MQTT会话保持怎么选
在对接海量设备时,不少团队会纠结：到底是用HTTP长轮询“凑合一下”，还是直接上MQTT，我们用一个真实场景来对比：一个充电桩运营商，需要同时接入两万台充电桩，每台桩每30秒上报一次充电状态。
- HTTP长轮询方案：连接没有状态，每次请求都要重新走一次鉴权和握手流程，两万台设备轮询一多，网关连接数瞬间被占满，而且服务器无法感知设备突发下线，充电桩的故障时间无法精确记录，后期对账容易扯皮。
- MQTT协议方案：一条TCP连接里同时跑多发多收，设备的状态，会话保持机制全给接住了，哪怕设备跟服务器断了几分钟，充电记录也能断点续传，无需设备端额外开发“补单接口”。
结论其实很清晰：设备需要频繁上下线，且有离线通知需求时，MQTT的会话保持优势是压倒性的
，HTTP作为边缘接口做鉴权和配置下发可以，但作为大规模设备接入的会话层，它不是合适的载体。
MQTT服务器价格是多少
MQTT服务器的价格,主要看你选开源自建，还是商业托管的模式。
- 开源方案：EMQX、Mosquitto、VerneMQ都是免费的，单机版支持几千到上万的连接数，入门完全够用，成本集中在服务器硬件和运维人力上。
- 商业服务：主流云厂商的MQTT接入产品，一般按连接数月峰值来计费，连接数从几千到千万跨度，费用自然也是几个量级，大规模场景下，商业版虽然贵，但胜在免运维，自带多活容灾。
如果你的量级在每秒千级消息以内,开源EMQX跑在4核8G的云服务器上，就是性价比最高的选项，用到万级设备、十万级设备，集群部署的复杂度会明显上升，这时候再考虑商业版或托管版也不迟。
海量设备接入选型要点
- 连接密度：单台Broker能承受多少并发连接，多数情况下，EMQX单节点扛住十万连接是可行的，但前提是消息量控制在每秒万条以内。
- 水平扩展能力：会话数据能否在集群间共享，用MQTT做海量接入时，任何一个节点宕机，如果会话没有持久化到分布式存储里，连接到该节点的设备全部要重来一遍，EMQX的集群模式默认支持会话路由，节点间会同步订阅关系，选型时务必确认这一点。
实操步骤：从轻量环境到海量接入的调整链路
如果你的项目还在开发和联调阶段,现在就可以按下面的链路做一轮健康检视。
第一步：预估连接峰值
统计设备总数、单台设备平均在线时长，乘以一个富余量系数，硬件和Broker配置都按峰值预留，而不是按平均值准备。
第二步：调整系统连接数限制
Linux服务器默认能开的文件描述符数量有限，海量连接必须要改内核参数。
修改/etc/security/limits.conf，调高大文件描述符限制：
soft nofile 1048576
hard nofile 1048576同时修改/etc/sysctl.conf：
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192执行sysctl -p使其生效，这一步不做，十万连接的目标就只是纸面数字。
第三步：按设备类型配置心跳和会话参数
| 设备类型 | 心跳间隔 | cleanSession | QoS |
| — | — | — | — |
| 控制类设备（插座、开关） | 30秒 | 0（持久会话） | 1 |
| 数据上报类设备（传感器、水表） | 60秒 | 1（清理会话） | 0 |
| 可穿戴设备（手表、手环） | 15秒 | 0（持久会话） | 1 |
第四步：客户端SDK的重连退避策略
设备断线后，切忌所有的设备都在同一秒发起重连这在行业内叫“重连风暴”，正确的做法是采用指数退避：第一次重连等2秒，第二次等4秒，第三次等8秒，并加上最大延迟上限（比如300秒），从几百台设备开始，到规模化接入，退避策略是缓解服务器瞬时压力的有利手段。
第五步：监控会话状态指标
至少要把这些指标捞出来看：当前连接数、会话总数、掉线率、消息堆积数，掉线率超过百分之五，就要回头检查心跳设置和网络链路；堆积数持续上涨，八成是消费端处理速度跟不上，需要补消费者，而不是加Broker。
断线重连中的常见误区和排障思路
为什么设备总是掉线，而服务器却显示没有踢人
这往往是运营商NAT超时导致的设备侧的TCP连接被中间的网关静默回收了，但设备自己完全不知道，服务器也没收到FIN包，所以会话还挂着呢。
此时手动让客户端发一次PINGREQ,如果服务器没回应，说明连接已经假死，解决思路：把心跳间隔设置成比NAT空闲超时时间更短，同时开启TCP keepalive（服务端和客户端都开），双保险。
Broker重启后，会话还在吗
分两种情况：Broker配置了会话持久化（消息存数据库或磁盘），重启后会话和离线消息可以恢复；默认内存模式，重启即清空，生产环境不仅要开持久化，还要把离线消息也落到存储后端，否则设备重连后发现“哎，会话呢？”还得从业务层做补偿。
设备时间戳不一致影响会话保持吗
完全不影响,MQTT协议里的会话状态不依赖设备时钟，只认ClientID，设备哪怕时间错到十年前，只要ClientID不变，Broker都能找到对应的会话，设备时间不准到底该不该修”的噪声，可以直接无视。
MQTT会话保持相关高频问题解答
Q1：MQTT会话保持需要单独收费吗
开源MQTT Broker不按“会话保持”收费，你花的钱主要在服务器资源和运维人力上，商业MQTT云服务一般按连接数和消息条数计费，会话保持功能是基础能力，已经包含在连接费用里，不会单独列一个“会话”收费项。
Q2：海量设备接入用什么方案稳定，是EMQX还是自研网关
如果团队没有消息中间件内核级别的研发能力,选EMQX这类成熟开源项目是更稳妥的方案，它在会话保持、节点集群、消息路由上已经经受过多轮大规模场景验证，自研网关的收益在于能深度定制协议，但从零做会话上下文、持久化和故障转移，周期普遍在半年以上，行业共识认为，连接规模低于五十万的场景，自研的投入产出比并不划算。
Q3：MQTT会话保持状态下，设备重连后还需要重新订阅吗
不需要,只要连接的cleanSession设置为0，并且设备使用相同的ClientID，重连后Broker会恢复之前的订阅关系，并将离线期间积累的QoS 1和QoS 2消息按规则推送给设备，你只需要在客户端代码里处理“收到消息”的回调，不必在每次重连后逐个执行订阅动作。
MQTT的会话保持不是一台服务器替你存会话存档就完事的,它是一个需要按设备分级、按网络环境调参、按成本做取舍的系统设计，先把会话参数和重连节奏管理好，海量设备接入就不会让服务器手忙脚乱。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/730364.html
