- 线上有时因为发送方发送消息速度过快，或者消费方处理消息过慢，可能会导致broker积压大量未消费消息。
解决方案：此种情况如果积压了上百万未消费消息需要紧急处理，可以修改消费端程序（增加或者修改一个消费者），让其将收到的消息快速转发到其他topic(可以设置很多分区)，然后再启动多个新的消费者同时消费新主题的不同分区。如图所示： 
- 由于消息数据格式变动或消费者程序有bug，导致消费者一直消费不成功，也可能导致broker积压大量未消费消息。
解决方案：此种情况可以将这些消费不成功的消息转发到其它队列里去(类似死信队列)，后面再慢慢分析死信队列里的消息处理问题。
延时队列存储的对象是延时消息。
所谓的“延时消息”是指消息被发送以后并不想让消费者立刻获取，而是等待特定的时间后消费者才能获取这个消息进行消费。延时队列的使用场景有很多， 比如 ： 1.在订单系统中， 一个用户下单之后通常有 30 分钟的时间进行支付，如果 30分钟之内没有支付成功，那么这个订单将进行异常处理，这时就可以使用延时队列（延时队列的消费者）来处理这些订单了。
2.订单完成1小时后通知用户进行评价。
kafka没有提供延时消息功能，可以用rocketmq、rabbitmq都做延时消息。
如果一定要用kafka实现延时消息呢？
实现思路： 发送延时消息时先把消息按照不同的延迟时间段发送到指定的队列中（topic_1s，topic_5s，topic_10s，…topic_2h，这个一般不能支持任意时间段的延时），然后通过定时器进行轮询消费这些topic，查看消息是否到期，如果到期就把这个消息发送到具体业务处理的topic中，队列中消息越靠前的到期时间越早，具体来说就是定时器在一次消费过程中，对消息的发送时间做判断，看下是否延迟到对应时间了，如果到了就转发，如果还没到这一次定时任务就可以提前结束了（还是建议用rabbitMQ）。
消息回溯
如果某段时间对已消费消息计算的结果觉得有问题，可能是由于程序bug导致的计算错误，当程序bug修复后这时可能需要对之前已消费的消息重新消费，可以指定从多久之前的消息回溯消费，这种可以用consumer的offsetsForTimes、seek等方法指定从某个offset偏移的消息开始消费完成消息的回溯消费！