生产环境MQTT消息响应缓慢的故障排查

原始地址
　　生产环境的充电桩项目一直运行平稳，用户在H5页面上操作，扫描充电桩，而后可以支付，进入对应的界面可以控制该充电桩的放电、停电。

具体的控制流程为，用户在页面通过HTTPS协议与服务器进行交互，服务器接收到请求后，组装参数，发送消息到mqtt服务器（RabbitMQ），而后充电桩的Mqtt客户端即可收到该条消息。充电桩对页面的消息反馈刚好是一个相反的过程。

该项目上线后，消息的发送到硬件响应平均时间基本在2s左右（视当地的4G网络信号）。但一天下午，小区的客户反馈，整个过程变得特别慢，下单后放电成功，但页面迟迟不会跳转到放电展示的界面，而且点击页面停电按钮，也不会生效。

首先，查看服务器上的H5模块的日志，发现但凡是传入该模块Mqtt消息的，服务器上都已经成功处理，没有延迟的情况。所以怀疑是当地充电桩硬件的信号问题（此前不久曾发生某小区大规模4G无信号、弱信号的情况）。为了保险，在办公室里调试并安装了一套硬件设备，模拟线上的情况，发现下发，响应很及时，没有出现延迟的情况。所以当即让现场人员检查，但现场人员经过十几分钟测试，反应4G信号没有问题。

没办法，只能再次多次的在办公室进行问题复现，现场也有人员进行配合测试。结果确实发现有消息漏传到服务器的情况。即，上传成功的消息，服务器都处理成功，没有上传成功的，服务器没有处理，页面只能处于等待状态并进入后续的等待处理流程。此时，为了验证充电桩是否真的漏传消息，还是因为什么别的原因服务器没有处理该条消息，开启了一个Mqtt客户端，并设置好环境，连上生产环境的服务器后，调到对应的topic并开启消费端，结果发现，充电桩的所有消息上传是正常的，但服务器这边确实没有接收到。此时，想到会不会是有多个程序，设置了相同的clientid，同时在消费生产环境的消息。经过各个服务器（允许连入生产环境IP）的排查，发现确实有一个消费端，与生产环境的MQTT消息消费模块分享了所有消息。将该消费端的进程kill掉，生产环境立即恢复正常。

其实，这个问题之前已多次发生，但每次都会以