消息积压

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

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

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

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

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

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

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

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

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

消息丢失

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

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