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

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

• 问题描述：

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

• 问题排查：

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

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

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