MQTT 客户端自动重连最佳实践｜构建可靠 IoT 设备连接

背景

MQTT 是一个基于 TCP 协议的发布/订阅模型协议，它被广泛应用于物联网、传感器网络和其他低带宽、不稳定网络环境中。在这些网络环境中，网络连接往往不稳定，可能会出现网络故障、信号弱化、丢包等问题，这可能会导致 MQTT 客户端与服务器之间的连接中断。物联网应用中，常见的触发断线重连的场景包括：

1. 网络环境恶劣或者断网，造成 MQTT 客户端连接超时断开。
2. 由于业务需要服务端升级切换，服务端主动关闭断开。
3. 设备重启或客户端重启，客户端主动重连。
4. 其他网络因素造成 TCP/IP 传输层断开导致 MQTT 连接重连。

为了确保 MQTT 客户端与服务器之间的稳定连接，MQTT 客户端需要实现重连逻辑，帮助 MQTT 客户端自动重新连接服务器，并恢复之前的订阅关系、保持会话等状态。

为什么 MQTT 客户端重连代码需要良好的设计

MQTT 设备重连是很多物联网应用中不可避免的情况。设计 MQTT 客户端重连逻辑时需要注意使用正确的事件回调方法，每次重连设置合理的随机退避时间，以保证客户端和服务端的长时间稳定运行，从而确保业务的正常开展。

不合理的重连逻辑设计可能会造成诸多问题：

1. 重连逻辑失效导致客户端静默不再接受 Broker 消息。
2. 客户端频繁重连，无重连退避时间导致形成 DDOS 攻击服务端 Broker。
3. 客户端频繁上下线导致 Broker 服务端资源过量不必要的消耗。

而合理的重连逻辑既可以提高 MQTT 客户端的稳定性和可靠性，避免因网络连接中断而导致的数据丢失、延迟等问题，还可以降低由于频繁连接对服务器端的压力。

如何设计一段 MQTT 客户端重连代码

在进行 MQTT 客户端重连代码设计时需要考虑以下几个方面：

• 设置正确的连接保活时间 MQTT 客户端的连接保活时间即 Keep Alive，负责检测当前连接的健康状态。Keep Alive 超时会触发客户端重连和服务端关闭客户端连接。该数值会影响到服务端和客户端检测到连接断开不可用的时长，用户需要根据自身网络状态，以及期望的最长等待时间来设置合理的 Keep Alive。
• 重连策略和退避 用户应该根据网络环境的不同，制定不同的重连策略。例如，当网络连接中断时，可以设置一个初始等待时间，并在每次重连尝试后逐渐增加等待时间，以避免网络连接中断导致的大量重连尝试。建议使用指数退避算法或随机 + 阶梯延时来留出足够的退避时隙。
• 连接状态管理 需要在客户端中维护连接状态，包括连接状态的记录、连接断开的原因、已订阅的主题列表等信息。当连接中断时，客户端应该记录下连接断开的原因，并进行相应的重连尝试。但如果使用会话保持功能，则不需要客户端自己保存这些信息。
• 异常处理 在连接过程中可能会发生各种异常情况，例如服务器不可用、认证失败、网络异常等。需要在客户端中添加异常处理逻辑，根据异常情况进行相应的处理。MQTT 5 协议提供了详实的此类断开连接原因，客户端可以根据这些信息记录异常日志、断开连接、再次重连等。
• 最大尝试次数限制：对于一些低功耗设备，为避免重连次数过多导致客户端资源消耗过大，有时候需要考虑限制最大重连尝试次数。当超过最大尝试次数后，客户端应该中止重连尝试进入休眠状态，避免无意义的重连。
• 退避算法：有两种常用的重连退避方法 ① 指数补偿算法 ② 随机退避。指数补偿算法是通过负反馈机制指数增加等待时间来找到合适的发送/连接速率。随机退避即通过设置等待时间的上下限，每次重连都等待随机的延时时间，由于其易于实现而有广泛使用。