本文探讨了消息积压的处理方法，包括临时扩容、利用RabbitMQ的TTL特性防止数据丢失，以及在消息队列满时的应急措施。在数据丢失情况下，建议在业务低峰期进行数据重导。此外，还强调了快速消费和恢复原有架构的重要性。
消息积压处理办法1：临时紧急扩容
-
先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。新建一个topic，partition是原来的10倍，临时建立好原先10倍的queue数量。然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue。
-
接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据。这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据。等快速消费完积压数据之后，的恢复原先的部署的架构，重新用原先的consumer机器来消费消息
MQ中消息失效
假设你用的是RabbitMQ,RabbitMQ是可以设置过期时间,也就是TTL。如果消息在queue中积压超过一定的时间就会被RabbitMQ给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接丢失。
- 方案: 重导。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。加入1w个订单积压在mq里面，没有出来，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次
mq消息队列满了
如果消息积压在mq里，你很长时间都没有处理掉，此时导致mq都快写满了，咋办? 这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
