MQTT断连、丢包经验总结

MQTT作为一个IOT领域常用的通信框架，本身是基于TCP的，有丢包重传、流量控制、拥塞检测等机制，算是比较稳定的。但实际开发过程中，由于代码逻辑问题或者对MQTT本身机制不够了解了解导致的断连、丢包等问题屡见不鲜。本人在实际开发中也遇到了一些相关问题，这里记录下来以供他们参考

一、断连问题

1.clientId 重复

对于MQTT来说，是不允许多个连接使用同一个 clientId的，如果使用了同一个，会强制断开旧的连接。因此在使用mqtt 框架的时候，最好是用单例封装一下，保证外部调用时不会实例化多个连接，同时内部也要注意在单例初始化的时候就要创建好连接对象，避免发起连接时再创建连接对象从而导致重复。

2. 证书失效

对于使用了SSL的MQTT连接来说，需要特别注意证书的有效性，本人之前做的项目SSL证书是动态生成的，因此在APP启动、登陆等环节都要去更新一下证书，以避免证书失效导致的连接断开。

3. 权限问题

本人之前使用的是AWS的MQTT服务，对于每个topic的发布和订阅都有权限管理，因此如果连不上，需要查看下是否权限配置正确了。对于动态添加的权限，还需要更新证书和重新建立连接来保证权限可用。

二、丢包问题

1. 订阅消息过多

订阅过多的主题会降低服务器性能，导致消息处理不及时而丢弃或延迟，因此最好在业务不需要的时候取消订阅那些可有可无的主题

2. QOS 设置不合理

QOS 有三个级别，最常用的是0（最多发送一次）和1 （最少发送一次），一般出于性能考虑能用0的尽量用0 ，但对于特别重要的消息，最好使用1或2（只发送一次）。有些服务器不支持QOS2 的，就只能用1.

3. 建立连接前或连接已断开

这个时候显然是无法发送和接收消息的，所以在订阅和发布前应判断当前连接的状态，如果是未连接或已断开，则需要先建立连接再发送和订阅消息。