【通用行业开发部】记一次rocketMq的踩坑经历

※技术组件：阿里云RocketMq
※业务场景：上游系统A将商家变更后数据，通过rocketMq消息通知我项目进行同步更改
※时间背景：项目上线后连续平稳运行一段时间的某天晚上
※异常发现：收到钉钉机器人的告警信息：topicxxx的消息堆积量已达xxx条。登录阿里云mq的控制台，显示topic状态异常，消息堆积状态。
※异常排查：
1、首先怀疑服务问题，紧急检查ECS服务器状态-->全部正常
2、检查mq消费者微服务所在pod状态-->全部正常
3、检查生产环境服务运行日志-->正常
4、搜索告警topic的近期消费日志-->正常
排查到这里其实就已经有点头大了，业务检查没有任何异常，mq的控制台又不能展示具体堆积的消息详情。
抓耳挠腮好一会儿之后，既然不能通过服务发现问题，就索性走一遍流程，看能不能复现问题。于是趁着夜深人静打开pod节点实时日志，然后通过mq的控制台手动发送了一条测试消息，结果！竟然！日志打印了！ mq消费没问题！emm，这就TM的离谱，看着控制台上红色的消息堆积状态，我陷入了深深的沉思...
确认服务消费没问题就好办了，第二天直接提了个阿里云工单咨询，结果工单小哥也没遇见过这种问题，历经许久并且用掉了一次技术专家答疑，才最终得到了
原因：死分区与假堆积，通俗点说就是某个节点长时间没有消息生产和消费，rocketMq会不能准确的监测到这个节点的状态，进而给出虚假的消息堆积告警。
※问题修复：
1、根据业务场景和生产日志，梳理出可能存在长时间没有消息消费的节点
2、针对这些节点增加定时发送消息（心跳）的逻辑。
※总结：
1、还是有必要了解选用技术一些可能隐藏的坑，不至于遇到问题时候手忙脚乱
2、技术选型和技术方案还是要根据业务和功能来确定，像本案例其实是不适用mq的（应该设计之初是有mq的通道，不愿再增加一种新的交互方式）