消息隊列技術解析(5)-消息大量積壓怎麼辦？（下）

消息積壓，如何處理

還有種消息積壓，日常系統正常運轉時，沒有積壓或隻有少量積壓很快就消費了，但某個時刻，突然開始積壓消息且積壓持續上漲。

這種情況下需要你在短時間内找到消息積壓原因，迅速解決問題才不至于影響業務。

突然積壓原因多種多樣，不能一概而論。但排查消息積壓原因，有相對固定且有效方法。

積壓突然增加，最粗粒度的原因，隻有兩種

• 要麼發送變快
• 要麼是消費變慢

大部分消息隊列都内置了監控的功能，隻要通過監控資料，很容易确定是哪種原因。如果是機關時間發送消息增多，比如說是趕上搶購，短時間内不太可能優化消費端代碼提升性能，唯一方法通過擴容消費端執行個體數提升總體消費能力。

如果短時間沒足夠伺服器資源擴容，将系統降級，通過關閉一些不重要業務，減少發送方發送資料量，最低限度讓系統還能正常運轉，服務一些重要業務。

kafka不僅是擴容時候，隻要是consumer和partition有一方的數量變化，都會觸發reblance。

還有種不太常見的，通過監控發現，無論是發送消息速度還是消費消息速度和原來都沒什麼變化，這時需檢查消費端，是不是消費失敗導緻的一條消息反複消費，也會拖慢整個系統消費速度。

如果監控到消費變慢，你需要檢查消費執行個體，分析一下是什麼原因導緻消費變慢。優先檢查一下日志是否有大量消費錯誤，如果沒有錯誤，可通過列印堆棧資訊，看消費線程是不是卡在什麼地方不動，比如觸發死鎖或卡在等待某些資源。

如果消費者消費異常，即使多次消費也無法成功處理（如消息格式異常），導緻一直無法成功ack此條消息，這種場景一般要怎麼處理？

有的MQ提供了“死信隊列”的功能，它會自動把這種反複消費都失敗的消息丢到一個特殊的死信隊列中，避免一條消息卡主隊列情況。

總結

消息積壓處理：

1、發送端優化，增加批量和線程并發兩種方式處理

2、消費端優化，優化業務邏輯代碼、水準擴容增加并發并同步擴容分區數量

檢視消息積壓的方法：

1、消息隊列内置監控，檢視發送端發送消息與消費端消費消息的速度變化

2、檢視日志是否有大量的消費錯誤

3、列印堆棧資訊，檢視消費線程卡點資訊

1.無法提升消費業務效率（僅受消費業務自身邏輯影響），但可以提高mq中堆積消息消費的整體吞吐量（批推比單推mq耗時較短）。

2.資料增量同步，監控資訊采集。（非核心業務的穩定大資料流操作）。

3.批處理意味資料積累和大資料傳輸，這會讓單次消費的最長時延變長。同時批量操作為了保證目前批量操作一緻性，在個别失敗的情況下會引發批量操作重試。

消費端是否可以通過同步消費提升消費性能呢？

消費端進行批量操作，感覺和上面的先将消息放在記憶體隊列中，然後在并發消費消息，如果機器當機，這些批量消息都會丢失，如果在資料庫層面，批量操作在大事務，會導緻鎖的競争，并且也會導緻主備的不一緻。如果是一些不重要的消息如對日志進行備份，就可以使用批量操作之類的提高消費性能，因為一些日志消息丢失也是可以接受的。