MQTT版本升级过程及源码解析

　　首先说一下为什么要写这篇文章呢，在我发现网上对MQTT的文章介绍实在太少了，可能也是使用这个的频率比较低吧！还有对问题的定位以及解决的方式和办法也太少了，所以特意写这篇文章希望能作出一些贡献，帮助到一些需要的人。

　　主要记录一下MQTT在原先1.2.0版本使用过程中出现的问题，排查问题到升级1.2.1版本过程中出现的问题，通过源码一步步排查出最后的问题点，直到符合预期目标。

　

<!-- https://mvnrepository.com/artifact/org.eclipse.paho/org.eclipse.paho.client.mqttv3 -->
<dependency>
    <groupId>org.eclipse.paho</groupId>
    <artifactId>org.eclipse.paho.client.mqttv3</artifactId>
    <version>1.2.1</version>
</dependency>

　　MQTT的搭建及SSL认证可以参考这个博客：https://www.cnblogs.com/yueli/p/7490453.html 在这不仔细阐述

---

 　Qos介绍　

　　在开头先了解一下Qos的一些含义，也是这个问题为导火线

• Qos = 0  最多一次的传输

　　  　  发布者PUBLISH消息到服务器（broker），发送即丢弃。没有确认消息，也不知道对方是否收到。网络层面，传输压力小

• Qos = 1  至少一次的传输

　　 发布者发布消息保存消息，服务器（broker）接收到消息，服务器（broker）PUBLISH到订阅者，服务器（broker）回一个PUBACK信息到发布者让删除消息，然后订阅者接收消息后PUBACK给服务器让删除消息。如果失败了，在一段时间确认信息没有收到，发送方都会将消息头的DUP设置为1，然后再次发送消息，消息最少一次到达服务。例如网络延迟等问题，发布者重复发送消息，订阅者多次订阅重复消息 

• Qos = 2  只有一次的传输

　　其实Qos = 2 只是在 1 的基础上做了改掉的赶脚，在发布者PUBLISH到服务器之后多了消息的确认以及多了消息msgID的缓存，重复信息的去重。在服务器PUBLISH到订阅者之后也多了消息的确认。

　　三种情况的区别

　　 0 没有保存message，没有重发机制，啥事也不知道，1和2 的发布者和服务器有保存message，发布者有重发机制，服务器都有PUBLISH之后的PUBACK的确认机制，但是2的服务器多了缓存msgID的一项功能，提供了去重功能，防止了消息的重复发送，以及消息的接收的确认机制。订阅者这边不过多的介绍，感兴趣再去了解。

---

 MQTT1.2.1版本出现的问题　

　　问题的描述：因为项目中使用MQTT通信的地方比较多，一般都是以Qos = 0 的形式，这段时间发现会时常提醒报错Too many publishes in progress (32202)，看了一下源码报错地方