- 線上有時因爲發送方發送消息速度過快，或者消費方處理消息過慢，可能會導致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偏移的消息開始消費完成消息的回溯消費！