问题描述
在公司做文件中心，业务方上传文件之后，需要调用发送转码接口。因为转码需要的时间比较长，所以这块是使用的mq做了异步处理。
在这个背景下，今天测试环境的mq积压了6000w条转码记录。这个现象是非常不正常的，产线的转码都不会这么频繁。
这里贴一个当时发生挤压时候的控制台截图：
问题发现
- 根据mq里面的消息，找到调用转码接口的业务方
- 整理调用链路，发现产生问题的原因
- 重置我这边的消费者的消费进度，在控制台直接操作重置。
- 修复转码数据。从数据库里面捞转码失败的，重新发起转码
根因分析
产生这次问题的根本原因是降本增效之后，本来两个集群的mq，迁移到同一个集群，造成之前为了兼容单集群服务做的mqtrans重复消费并调用单集群服务的接口。
这里大概再贴一下当时分析问题画的流程图。
正常流程：
降本增效之后的流程：
问题反思
这个问题其实已经发生过一次了，上次的处理逻辑是直接把用来多集群转发的mqtrans服务停掉，停掉之后，中台的同学并没有考虑到降本增效大背景下面，运维每天晚上缩容和早上扩容的情况。导致在第二天上班的时候，运维直接将该服务重新拉起，造成了mq的循环消费。
针对这种反复出现的问题，中台同学应该认真反思一下，处理问题需要严谨一些，虽然不是产线环境，但是tf环境也经常跑一些比较重要的测试，造成的影响很大。
另外就是我自身服务的监控做的还是不到位，这种循环消息造成的mq挤压超过6000w的巨量消息竟然没有报警，说明系统的健壮性还是有很大的提升空间。后面会逐步完善好基础服务的监控。