项目背景:

       在 Spring Boot + MQTT 5.0 环境中，RTU设备向SpringBoot平台发送心跳数据、业务监控数据。同时SpringBoot平台可以向RTU设备下发指令，RTU在执行完指令之后向平台发送响应数据。

        问题一、SpingBoot平台发送指令给RTU设备，RTU设备能够收到指令也能回复信息到相应的主题。SpringBoot平台也订阅该主题，但是没有收到信息。

        在遇到这个问题的时候，我发现控制台的打印出了一个ERROR日志：

2025-03-06 11:11:31.652 [MQTT Rec: TerminalB] ERROR o.s.i.m.i.MqttPahoMessageDrivenChannelAdapter:362 - Lost connection: 已断开连接; retrying...

排查思路：

1.首先需要明确哪些因素会导致出现断开连接。因为收不到消息同时伴随着ERROR日志的打印。

•  检查网络连接

         确保你的设备与MQTT服务器之间的网络连接是稳定的。你可以尝试ping服务器地址或使用网络工具检查连接质量。

•  检查MQTT服务器状态

        确认MQTT服务器正在运行且没有遇到任何问题。如果可能，尝试连接到服务器的其他客户端（例如另一个设备或应用程序）以验证服务器是否可用。

•  检查MQTT客户端配置            

•     主机名和端口：确保客户端配置中的MQTT服务器地址和端口号是正确的。

•     客户端ID：每个客户端都应该有一个唯一的ID。确保没有两个客户端使用相同的ID连接至同一服务器。

•     用户名和密码：如果服务器启用了认证，确保提供了正确的用户名和密码。

•     清洁会话：根据你的需求设置cleanSession。如果是true，它将删除之前的会话信息；如果是false，它将保留会话信息。

•   检查防火墙和安全组设置

        确保没有防火墙或安全组规则阻止客户端与MQTT服务器之间通信。这包括入站和出站规则。

2、SpringBoot平台订阅了很多主题的消息，比如心跳主题，业务监控主题等，之前是不会出现信息订阅不到。说明主机名和端口、用户名密码，是正确的。

3、现在还剩下三项没有排除，客户端ID、清洁会话、防火墙。因为心跳是正常的，所以说清洁会话和防火墙是没问题的，如果这两个有问题那心跳主题的信息我们平台也是收不到的。

4、目前只剩下客户端ID这个因素。现在已经大致明确了是因为这个因素导致，接下来我们需要分析一下为什么出现这个问题，之前是正常的。通过回忆实际操作，我发现SpingBoot平台订阅不到消息之前，我通过SpringBoot平台向某一台RTU设备发送了一个修改频率的指令。然后我又分析日志信息，发现当我发送消息之后，控制台出现了断开连接的错误。好，现在我把所有的操作和具体的报错信息联系在一起，问题就比较清晰了。我发送了一个指令，控制台报错：断开连接，然后RTU执行指令，然后RTU向响应主题发送消息，我们SpingBoot平台收不到了。

        再把上述的问题精简一下对于SprintBoot平台其实就是两个操作，一个是平台利用MQTT发送消息，另一个就是平台利用MQTT订阅消息。当我发送完消息，平台订阅不到消息，同时出现断开连接。这个时候我就明确了错误所在，发布是一个客户端行为，订阅也是一个客户端行为，但是我们在代码里面把订阅ID和发送ID设置成了相同的，如下：

    subClientId: adminpubClientId: admin

        也就是平台发送指令的时候把订阅的连接顶掉了，这个时候出现了订阅断开连接的错误日志。然后RTU发送响应消息到订阅主题，但是这个时候平台的订阅已经断开链接，所以说平台一直收不到响应消息。以上就是我分析这个问题的具体思路，在此仅作个人记录，如有分析错误的地方，欢迎大家留言指导。

问题二、SpingBoot平台在启动之后，一直在重复打印一条消息，而且RTU设备并没有发送任何消息到MQTT的服务器，通过观察该消息是间隔固定的时间重复打印。

        排查思路：

1、我先排查这一条消息的出处到底在哪里来的。通过对比发现，这一条是昨天RTU的消息，并不是今天的，所以说很奇怪。

2、MQTT通讯中我的平台也是一个客户端，客户端本身不存储消息，只有可能是服务器端存储。

3、前边几篇文章分析的有消息重复接受的原因，主要是消息质量为1的时候，MQTT协议本身重发导致。还有就是tcp的重发，但是在这里不存在tcp重复的因素。那只能是消息质量为1的时候，协议本身导致。

4、现在分析出主要是消息质量为1的时候导致，那就说明broker给平台发送消息的时候可能存在两种情况，第一就是broker收到多次重复消息，导致broker也给平台发送多次消息。第二、就是平台收到broker消息，但是平台没有给broker发送回复消息。

5、如果是第一种情况，那我平台正常启动，就能消费订阅的信息，就不会出现我现在这种不断重复打印的情况，所以说第一种情况排除。

6、那现在肯定是第二种情况，平台没有给broker发送响应消息。现在开始回顾代码，为什么没有发送响应消息。仔细观察代码发现，我订阅的时候使用通配符订阅了所有消息，恰好没有对RTU执行代码之后发送消息的主题进行代码处理，导致broker一直收不到我的平台反馈，所以说broker一直不断地给平台发送信息。

7、综上所述这就是我重复消息不停输出的原因。