如何解决消息队列的延时以及过时失效问题？消息队列满了之后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

面试题

如何解决消息队列的延时以及过时失效问题？消息队列满了之后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

面试官心理分析

你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，致使好比 RabbitMQ 设置了消息过时时间后就没了怎么办？

因此就这事儿，其实线上挺常见的，通常不出，一出就是大 case。通常常见于，举个例子，消费端每次消费以后要写 mysql，结果 mysql 挂了，消费端 hang 那儿了，不动了；或者是消费端出了个什么岔子，致使消费速度极其慢。

面试题剖析

关于这个事儿，咱们一个一个来梳理吧，先假设一个场景，咱们如今消费端出故障了，而后大量消息在 mq 里积压，如今出事故了，慌了。

大量消息在 mq 里积压了几个小时了还没解决

几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是咱们真实遇到过的一个场景，确实是线上故障了，这个时候要否则就是修复 consumer 的问题，让它恢复消费速度，而后傻傻的等待几个小时消费完毕。这个确定不能在面试的时候说吧。

一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。因此若是你积压了几百万到上千万的数据，即便消费者恢复了，也须要大概 1 小时的时间才能恢复过来。

通常这个时候，只能临时紧急扩容了，具体操做步骤和思路以下：

• 先修复 consumer 的问题，确保其恢复消费速度，而后将现有 consumer 都停掉。
• 新建一个 topic，partition 是原来的 10 倍，临时创建好原先 10 倍的 queue 数量。
• 而后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费以后不作耗时的处理，直接均匀轮询写入临时创建好的 10 倍数量的 queue。
• 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种作法至关因而临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
• 等快速消费完积压数据以后，得恢复原先部署的架构，从新用原先的 consumer 机器来消费消息。

mq 中的消息过时失效了

假设你用的是 RabbitMQ，RabbtiMQ 是能够设置过时时间的，也就是 TTL。若是消息在 queue 中积压超过必定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。

这个状况下，就不是说要增长 consumer 消费积压的消息，由于实际上没啥积压，而是丢了大量的消息。咱们能够采起一个方案，就是批量重导，这个咱们以前线上也有相似的场景干过。就是大量积压的时候，咱们当时就直接丢弃数据了，而后等过了高峰期之后，好比你们一块儿喝咖啡熬夜到晚上12点之后，用户都睡觉了。这个时候咱们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，而后从新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。

假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

mq 都快写满了

若是消息积压在 mq 里，你很长时间都没有处理掉，此时致使 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉全部的消息。而后走第二个方案，到了晚上再补数据吧。