问题本质都在于你的消费端可能出了问题，不消费或消费的太慢！更可怕的是由于积压时间太长，导致如果起初还设置了 TTL 后失效了怎么办？

消息积压

其实数据积压的问题是架构设计不合理。

丢失的数据是通过日志找回来,如果日志也找不到了 那就没招了

一般这时，只能操作临时紧急扩容了，具体操作步骤和思路如下：

1. 先修复 consumer，确保恢复消费速度，然后将现有 cnosumer 都停掉

2. 新建一个 topic，partition 是原来 10 倍，临时建立好原先 10 倍或者 20 倍的 queue

3. 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue

4. 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据

5. 这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据

6. 等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的 consumer 机器来消费消息

消息丢失

假设用 rabbitmq，可设置 TTL，积压超时后消息就没了，数据也就丢了。注意此时，并非数据大量积压在 MQ，而是大量数据直接搞丢了。

可以采取批量重导，就是大量积压时，就直接丢弃数据，然后等高峰期后，比如半夜，将丢失的那批数据，写个程序查出来，然后重新灌入 MQ，把白天丢的数据补回来。