设备连接mqtt集群被异常断开
以下是查找问题过程和思考过程
- 固件同学提出这个问题后，先在线上mqtt-broker的控制台查看该设备的日志信息，日志显示，设备连接上broker以后，一分钟时间就被断开连接，原因是
closed,第一想法就是被broker的超时机制给断开了连接。 - 心中还是有一丝疑虑，设备心跳时间设置的是60s，broker是1.5倍心跳时间算超时，然后就开始查找broker配置，看看是不是这个倍数填错了。
- 确认broker超时时间。
emqx.conf配置的确实是0.75（超时时间=心跳时间 * 0.75 * 2），那是否生效了呢？broker启动后会把所有的配置文件合并到一个大的配置文件中，检查该文件配置的也是正确的，那就奇怪了，但我还是觉得broker配置的问题，于是把线上的所有emqx相关的配置全都下载到了本地，和正确的配置文件进行比较，但还是没发现什么问题，即使有不一样的地方，也是确定不会出问题的地方。 - 我陷入了深深地思考，现在大致确定和broker的配置没有什么关系，而且从broker日志来看，设备连接上来后，broker没有收到心跳，连接就被断开，但是我的客户端，30s的心跳，却可以收到，进一步判断不是broker的问题。那只有一个可能了，线上和预上线的区别除了集群，配置，就是线上还配置了代理。
- 线上使用
haproxy来做的tcp代理，此时心中还有两个怀疑方向，一个是haproxy超时,或者haproxy没有转发心跳包，而且更有可能是前者，因为30s的心跳还是可以转发的。 - 于是在本地搭建
haproxy用于在本地复现问题，成功代理后，确实可以复现，我看线上的haproxy代理1883端口的地方没有设置超时时间，所以在运维同学那确认了一下，默认超时时间是60s，这一刻，我已经有百分之九十的把握确定就是这个时间。在本地设置更短的时间10s后，客户端确实在10s的时候就断开了，到此，这个问题可以画上句号了。
总结
从发现问题到解决，花了一天多的时间，其实开始的时候怀疑过代理层的超时时间问题，向运维小姐姐确认了下，是不是有什么超时时间，小姐姐发了一个全局的默认配置截图，我看上面没有60s相关的设置，就转移了注意力。
排查问题，首先还是要清楚整条数据链路，一个一个环节排除。这其中很关键的办法就是找不同，找正确的环境，和错误环境之间的差异，很多次排查问题，这个思路数次把我从困局中解决出来。反思自己的问题，自己不清楚
haproxy怎么配置，怎么使用，其实也是第一次接触，如果知道监听端口的位置，默认超时时间为60s的话，那首先就会验证这个地方，就不至于走弯路浪费了那么久的时间了。最后，感谢运维小姐姐的积极配合
网友评论