背景現象
1.20晚上8點業務線開始切換LBS相關流量，在之後的1個小時時間內，積壓量呈上升趨勢，一路到達50W左右，第二天的圖沒貼出具體是50W數字，以下是第一天晚上的貼圖部分。
現象一：
現象二：
當時現場圖後來就找不回來了，憑印象說明了一下數字。
簡要說明一下上述兩個圖
圖一：其實很明顯，明顯看出，消費者消費速度明顯跟不上生產者的傳送速度，導致出現積壓情況。
圖二：圖二就有點意思了，因為上游通過Kafka訊息佇列傳送訊息給我，topic對應的分割槽數是20個。由於我的應用消費組內消費者例項是17個，所以從巨集觀上分析，勢必會有3個消費者會承擔多消費一個分割槽的情況。這個倒也容易理解。但為什麼會積壓這麼多。個人分析了一下，主要還是跟消費者本身消費的消費業務邏輯有關。因為我的消費業務邏輯是要呼叫下游一個LBS地圖服務的，通過裝置上報的WIFE內容經過公司LBS平臺介面換取裝置當前地理位置座標資訊，但這個地理位置服務，R通過命令：thread-n3-i 500 : 列出500毫秒內最忙的3個執行緒棧，其中就有兩個屬於呼叫地理位置服務的執行緒。
通過命令：thread-n3-i 500(阿里開源診斷工具Arthas：thread命令) : 列出500毫秒內最忙的3個執行緒棧，其中就有兩個屬於呼叫地理位置服務的執行緒。
原因分析
分析了具體原因具體是兩個層面
- HMS-Client(公司自己封裝的呼叫訊息佇列的SDK)層面
根據圖一，其實想說明一點的是，在本應用呼叫下游服務延遲高的場景下，從圖一的現象看出，消費者的利用率其實不高，topic有20個分片，消費組17個容器例項，14個例項基本對應一個分割槽，有三個例項對應2個分割槽，導致資源利用率其實很低，而我們其實是希望在下游服務相應慢的情況下,最好有更多執行緒參與去消費任務，增加吞吐率，提高處理效率（IO密集型應用，儘量提高處理執行緒數）。而我們的處理執行緒數是5個，即最高5個執行緒會去處理任務，其他都會等待進入
這兩個引數，當下應用設定了5個，但我的機器配置是8核16G，引數設定是不合理的。這個引數主要是從其他專案中拷貝過來，沒過多關注他，在高併發應用場景下，想不多卻成為瓶頸，特別是消費執行緒內如果涉及到RT很高，QPS上不去的下游服務，就有講究了。
- 呼叫下游服務響應延遲高
這個我上述圖二已經有詳細描述了
解決方案
- 調整Client 消費執行緒數，從原來的5調整到20個執行緒
- 增加KAFKA的分片數，臨時方案，目前已經讓中介軟體從原來的分片數20調整到60，積壓下降的明顯。因為消費組內的消費者例項一個承擔了基本3-4個分割槽訊息數。