4. 会话恢复（Session Recovery）原理：恢复流程、恢复条件、恢复后的状态同步
好，咱们进入本章的核心——会话恢复。说白了，就是客户端断线重连后，怎么把之前没干完的活儿续上。
我刚开始接触 MQTT 时，觉得会话恢复不就是重连一下嘛，有啥复杂的？后来在车联网项目里被狠狠教育了一回——设备断网 10 秒，重连后订阅全部丢失，平台下发指令直接石沉大海。嗯，从那以后我才真正重视起会话恢复的细节。
4.1 恢复流程：三步走
会话恢复的流程，我习惯拆成三步：发起恢复请求 → 服务端校验 → 状态同步。咱们一步步看。
- 发起恢复请求
客户端重连时，在 CONNECT 报文中设置Clean Start = 0，并带上之前分配的Client ID。服务端收到后，会去查这个 Client ID 对应的 Session 是否存在。 - 服务端校验
服务端检查 Session 是否过期（默认不过期，但可以设置Session Expiry Interval）。如果 Session 还在，就返回 CONNACK，其中Session Present = 1，告诉客户端：“嘿，你的老会话还在，咱们接着干。” - 状态同步
客户端收到Session Present = 1后，不需要重新订阅。服务端会继续推送之前未确认的 QoS 1/2 消息。双方开始同步未完成的报文流。
关键点：恢复流程的核心是 Clean Start = 0 + Session Present = 1。这两个标志位配合，才能实现无缝恢复。
4.2 恢复条件：不是所有断连都能恢复
我在项目中遇到过好几次，客户端重连后 Session Present = 0，订阅全没了。为什么会这样？因为恢复是有条件的。
| 条件 | 说明 | 个人经验 |
|---|---|---|
| Client ID 不变 | 恢复必须使用相同的 Client ID | 我见过有人每次重连随机生成 Client ID，结果 Session 永远恢复不了 |
| Session 未过期 | Session Expiry Interval 未超时 |
车联网项目里我设了 24 小时，防止设备长时间离线后丢失状态 |
| 服务端未重启 | 服务端重启后，内存中的 Session 会丢失（除非持久化） | 我曾经踩过这个坑——服务端半夜自动重启，第二天所有设备都重建了 Session |
| Clean Start = 0 | 客户端必须显式设置 Clean Start 为 0 | 有些客户端库默认 Clean Start = 1，需要手动改 |
避坑指南：我曾经在生产环境遇到过，客户端重连时忘了设置 Clean Start = 0，结果服务端直接创建了新 Session，旧 Session 被清理。所有未投递的消息全部丢失。那一次事故让我养成了一个习惯——在客户端初始化代码里，把 Clean Start 写死为 0。
4.3 恢复后的状态同步：服务端和客户端各自要做什么
恢复成功后，双方需要同步哪些状态？我列了个清单，你对照着看。
服务端侧的状态同步
- 重新投递未确认的 QoS 1/2 消息：服务端会从消息队列里取出未收到 PUBACK/PUBCOMP 的消息，重新发送。
- 恢复订阅关系：不需要客户端重新 SUBSCRIBE，服务端直接沿用之前的 Topic Filter 和 QoS 等级。
- 恢复遗嘱消息：如果客户端之前设置了 Will Message，服务端会保留，直到客户端主动清除或 Session 过期。
客户端侧的状态同步
- 重新处理未完成的报文：客户端需要准备好接收重复的 PUBLISH 报文，并根据 Packet ID 去重。
- 恢复本地缓存：如果客户端本地缓存了未确认的消息，重连后需要重新发送。
- 检查 Session Present 标志：如果收到
Session Present = 0，客户端需要重新订阅所有 Topic。
我的习惯：在客户端重连后，我会主动发一个 PINGREQ 来确认连接是否真的稳定了。然后再开始处理业务消息。这个小技巧帮我避免了不少“假重连”导致的数据混乱。
4.4 会话恢复流程图
下面这张图，是我根据实际项目经验画的。它展示了从断线到恢复的完整流程。
4.5 恢复后的常见问题与处理
恢复流程看起来简单，但实际项目中坑不少。我挑几个典型的说说。
- 重复消息：QoS 1/2 的消息在恢复后可能重复投递。客户端必须做好去重，比如维护一个已处理的 Packet ID 列表。
- 订阅丢失：如果服务端重启且未持久化 Session，恢复后
Session Present = 0。客户端需要重新订阅所有 Topic。 - 遗嘱消息误触发：如果客户端断线后服务端发送了 Will Message，但客户端又快速重连恢复了 Session，这时候 Will Message 已经发出去了。我建议在业务层做幂等处理。
重要提醒：会话恢复不是万能的。如果服务端宕机且没有持久化 Session，恢复就会失败。对于关键业务，我建议在客户端侧也做一层本地缓存，双重保险。
4.6 小结
会话恢复的核心就三件事：Clean Start = 0、Session Present = 1、状态同步。你只要记住这三个关键词，恢复流程就掌握了八成。
我个人习惯在项目初期就把会话恢复的测试用例写全——断线重连、服务端重启、Session 过期、Client ID 变更，每种情况都要覆盖。嗯，这样上线后才睡得安稳。