公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

星巴克男孩 發表於 2022-01-23
Kafka

背景現象

1.20晚上8點業務線開始切換LBS相關流量,在之後的1個小時時間內,積壓量呈上升趨勢,一路到達50W左右,第二天的圖沒貼出具體是50W數字,以下是第一天晚上的貼圖部分。

現象一:

公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

 

現象二:

當時現場圖後來就找不回來了,憑印象說明了一下數字。

公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

 

 

簡要說明一下上述兩個圖

 

圖一:其實很明顯,明顯看出,消費者消費速度明顯跟不上生產者的傳送速度,導致出現積壓情況。

圖二:圖二就有點意思了,因為上游通過Kafka訊息佇列傳送訊息給我,topic對應的分割槽數是20個。由於我的應用消費組內消費者例項是17個,所以從巨集觀上分析,勢必會有3個消費者會承擔多消費一個分割槽的情況。這個倒也容易理解。但為什麼會積壓這麼多。個人分析了一下,主要還是跟消費者本身消費的消費業務邏輯有關。因為我的消費業務邏輯是要呼叫下游一個LBS地圖服務的,通過裝置上報的WIFE內容經過公司LBS平臺介面換取裝置當前地理位置座標資訊,但這個地理位置服務,R通過命令:thread-n3-i 500 : 列出500毫秒內最忙的3個執行緒棧,其中就有兩個屬於呼叫地理位置服務的執行緒。

公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

 

 

通過命令:thread-n3-i 500(阿里開源診斷工具Arthas:thread命令) : 列出500毫秒內最忙的3個執行緒棧,其中就有兩個屬於呼叫地理位置服務的執行緒。

公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

 

 

原因分析

 

分析了具體原因具體是兩個層面

  1. HMS-Client(公司自己封裝的呼叫訊息佇列的SDK)層面

根據圖一,其實想說明一點的是,在本應用呼叫下游服務延遲高的場景下,從圖一的現象看出,消費者的利用率其實不高,topic有20個分片,消費組17個容器例項,14個例項基本對應一個分割槽,有三個例項對應2個分割槽,導致資源利用率其實很低,而我們其實是希望在下游服務相應慢的情況下,最好有更多執行緒參與去消費任務,增加吞吐率,提高處理效率(IO密集型應用,儘量提高處理執行緒數)。而我們的處理執行緒數是5個,即最高5個執行緒會去處理任務,其他都會等待進入

公司內部一次關於kafka訊息佇列消費積壓故障覆盤分享

 

 

這兩個引數,當下應用設定了5個,但我的機器配置是8核16G,引數設定是不合理的。這個引數主要是從其他專案中拷貝過來,沒過多關注他,在高併發應用場景下,想不多卻成為瓶頸,特別是消費執行緒內如果涉及到RT很高,QPS上不去的下游服務,就有講究了。

  1. 呼叫下游服務響應延遲高

這個我上述圖二已經有詳細描述了

 

解決方案

  • 調整Client 消費執行緒數,從原來的5調整到20個執行緒
  • 增加KAFKA的分片數,臨時方案,目前已經讓中介軟體從原來的分片數20調整到60,積壓下降的明顯。因為消費組內的消費者例項一個承擔了基本3-4個分割槽訊息數。