记录一次优化MQ消息处理性能瓶颈（临时版）

写博客的时间比较少，所以今天一下写两篇，这篇先写个大概，后面再慢慢补全。

• 问题描述：

  • 前段时间在生产环境上，一家客户向我们反馈，当天的客流数据全部为空。 先看日志，发现该公司设备一直在上报客流数据。公司生产环境上使用的rabbitmq，然后进入管理页，发现客流数据的队列堆积了将近60W数据没有消费。再仔细观察日志，发现当前消费的数据还是将近15小时前的数据，当天的数据肯定就没有了。

• 问题排查：

  • 刚开始第一反应觉得应该是分布式锁出问题了，一直没有释放掉，后来经过检查并没有。 再观察发现，每条消息处理的时间将近1s/条，发现处理的真的是太慢了，正好这件事发生的前几天，有新客户接入平台，并且客户有大量的客流设备，导致超过了平台处理的性能瓶颈。
    处理客流数据的业务，主要就是三个地方非常耗时:
    1.是分布式锁，大约耗时10ms，
    2.是客流数据上来后需要和两个不同的业务服务交互，取一些字段，然后插入es中。与两个服务交互走rest接口，耗时接近200ms。
    3.MQ配置有问题，没有配置队列的消费线程数量，导致一直是一个线程在消费。然后代码里使用的是手工ack的方式，配置却没有配置

• 解决方案：
  1.增加客流服务实例。
  2.每个实例开启2个线程消费数据
  3.优化业务逻辑。
  经过优化后，每条消息处理速度为180-190ms，提升了4倍左右，等晚上升级上线，成功消费掉了堆积数据，后续到现在并没有出现性能瓶颈。

其实这里的优化处理很常规，后面再有客户接入大量客流设备的时候，也不能每次都单纯的靠加服务器去解决，后来我考虑到了另一个服务治理框架dubbo，dubbo服务间是使用rpc协议通信，而目前我们的项目是使用的spring cloud，服务间通信是feign的伪rpc通信，实际上还是http通信。并且考虑到我们的项目处理客流数据最大的瓶颈就是服务间通信的耗时，所以我个人觉得此处有两种修改方式，第一种方案是非常适合改为rpc通信，集成rpc通信框架，优化性能。第二种方案是对请求结果做缓存。不过目前向上面反应了优化方案，看起来积极性不高，所以后面有时间我会在自己的项目上搭建一个试一下，这个才是我觉得这次问题处理收获最大的地方。