收到某業務組的小夥伴發來的反饋，具體問題如下：
專案中某 kafka 訊息組消費特別慢，有時候在 kafka-manager 控制台看到有些消費者已被踢出消費組。
從服務端日誌看到如下資訊：
該消費組在短時間內重平衡了 600 多次。
從 cat 檢視得知，每條訊息處理都會有 4 次資料庫的互動，經過一番溝通之後，發現每條訊息的處理耗時大概率保持在 200ms 以上。
kafka 發生重平衡的有以下幾種情況：
消費組成員發生變更，有新消費者加入或者離開，或者有消費者崩潰；
消費組訂閱的主題數量發生變更；
消費組訂閱的分割槽數發生變更。
在第 2、3 點都沒有發生的情況下，那麼就是由消費組成員發生了變化導致 kafka 發生重平衡。
在檢視 kafka 客戶端日誌，發現有很多如下日誌：
日誌的描述得知，消費者被被剔除的原因是呼叫 poll() 方法消費耗時太久了，其中有提到 max.poll.interval.ms 和 max.poll.records 兩個引數，而且還會導致提交
max.poll.interval.ms 表示消費者處理訊息邏輯的最大時間，對於某些業務來說，處理訊息可能需要很長時間，比如需要 1 分鐘，那麼該引數就需要設定成大於 1分鐘的值，否則就會被 coordinator 剔除訊息組然後重平衡， 預設值為 300000；
max.poll.records 表示每次預設拉取訊息條數，預設值為 500。
我們來計算一下：
200 * 500 = 100000 < max.poll.interval.ms =300000，
前面我也講了，當每條訊息處理時間大概率會超過 200ms。
結論：本次出現的問題是由於客戶端的訊息消費邏輯耗時太長，如果生產端出現訊息傳送增多，消費端每次都拉取了 500 條訊息進行消費，這時就很容易導致消費時間過長，如果超過了 max.poll.interval.ms 所設定的時間，就會被消費組所在的 coordinator 剔除掉，從而導致重平衡，kafka 重平衡過程中是不能消費的，會導致消費組處於類似 stop the world 的狀態下，重平衡過程中也不能提交位移，這會導致訊息重複消費從而使得消費組的消費速度下降，導致訊息堆積。
解決辦法：
根據業務邏輯調整 max.poll.records 與 max.poll.interval.ms 之間的平衡點，避免出現消費者被頻繁踢出消費組導致重平衡。
一次kafka堆積問題解決
我們從kafka獲取資料，如下圖，有兩步，第一步是從dmq獲取出來放到乙個佇列裡 第二步是我們消費執行緒從佇列裡獲取內容。對第一步，業務作為dmq客戶端，啟動n個連線去連線dmq，連線數由配置項mq.consumer.connections指定，一般模組都沒配置 目前小組內框架設定的預設值是2 對第...
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
一次快取效能問題排查
以下分享的都跳過了很多坑，包括redis tomcat環境配置 機器硬體配置等等問題 與線上保持一致，或者硬體效能減配係數，例如線上 8c16g，壓測 4c8g，係數簡單相差2倍 直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽 通過對某直播 頁面進行高併發壓測，在apm pinpoint 監控中發現...