近日，有使用者反饋kafka有topic出現某個消費組消費的時候，有幾個分割槽一直不消費訊息，訊息一直積壓（圖1）。除了一直積壓外，還有乙個現象就是消費組一直在重均衡，大約每5分鐘就會重均衡一次。具體表現為消費分割槽的owner一直在改變（圖2）。
（圖1）
（圖2）
業務側沒有報錯，同時kafka服務端日誌也一切正常，同事先將消費組的機器滾動重啟，仍然還是那幾個分割槽沒有消費，之後將這幾個不消費的分割槽遷移至別的broker上，依然沒有消費。
還有乙個奇怪的地方，就是每次重均衡後，不消費的那幾個分割槽的消費owner所在機器的網路都有流量變化。按理說不消費應該就是拉取不到分割槽不會有流量的。於是讓運維去拉了下不消費的consumer的jstack日誌。一看果然發現了問題所在。
從堆疊看，consumer已經拉取到訊息，然後就一直卡在處理訊息的業務邏輯上。這說明kafka是沒有問題的，使用者的業務邏輯有問題。consumer在拉取完一批訊息後，就一直在處理這批訊息，但是這批訊息中有若干條訊息無法處理，而業務又沒有超時操作或者異常處理導致程序一直處於消費中，無法去poll下一批資料。又由於業務採用的是autocommit的offset提交方式，而根據原始碼可知，consumer只有在下一次poll中才會自動提交上次poll的offset，所以業務一直在拉取同一批訊息而無法更新offset。反映的現象就是該consumer對應的分割槽的offset一直沒有變，所以有積壓的現象。
至於為什麼會一直在重均衡消費組的原因也很明了了，就是因為有消費者一直卡在處理訊息的業務邏輯上，超過了max.poll.interval.ms（預設5min），消費組就會將該消費者踢出消費組，從而發生重均衡。
讓業務方去查證業務日誌，驗證了積壓的這幾個分割槽，總是在迴圈的拉取同一批訊息。
臨時解決方法就是跳過有問題的訊息，將offset重置到有問題的訊息之後。本質上還是要業務側修改業務邏輯，增加超時或者異常處理機制，最好不要採用自動提交offset的方式，可以手動管理。
kafka消費分割槽策略
在 kafka 實際生產過程中，每個 topic 都會有 多個 partitions。1.多個partitions有什麼好處？1 多個 partition 能夠對 broker 上的資料進行分片，通過減少訊息容量來提公升 io 效能 2 為了提高消費端的消費能力，一般情況下會通過多個 conusme...
kafka 消費者分割槽策略
分割槽分配策略 當消費者組中的消費者增多或減少會觸發分割槽分配策略 乙個consumer group中有多個consumer，乙個topic有多個partition，所以必然會涉及到partition 的分配問題，及確定那個partition由哪個consumer來消費。kafka中有兩種分配策略，...
MySQL使用分割槽時出現的若干問題
1 a primary key must include all columns in the table s partitioning function 如果使用分割槽的表包含主鍵或唯一索引，在建立分割槽時必須使用該欄位 反之，表沒有任何唯一索引，則可以使用可用的任一字段。2 constant,r...