一、kafka的rebalance機制
在Kafka中，當有新消費者加入或者訂閱的Topic數發生變化時，會觸發Rebalance(再均衡：在同一個消費者組當中，分區的所有權從一個消費者轉移到另外一個消費者)機制，Rebalance顧名思義就是重新均衡消費者消費。Rebalance的過程如下：
第一步：所有消費成員都向Coordinator發送請求，請求入Consumer Group。一旦所有成員都發送了請求，Coordinator會從中選擇一個Consumer擔任Leader的角色，並把組成員信息以及訂閱信息發給Leader。
第二步：Leader開始分配消費方案，指明具體哪個Consumer負責消費哪些Topic的哪些Partition。一旦完成分配，leader會將這個方案發給Coordinator。Coordinator接收到分配方案之後會把方案發給各個Consumer，這樣組內的所有成員就都知道自己應該消費哪些分區了。
所以對於Rebalance來說，Coordinator起着至關重要的作用
二、rebalance可能發生的時機
1、分區個數的增加
2、對Topic的訂閱發生變化
3、消費組成員的加入或離開（這個是我們最常遇到）
三、rebalance的影響
Rebalance對我們數據的影響主要有以下幾點：
1、可能重複消費: Consumer被踢出消費組，可能還沒有提交offset，Rebalance時會Partition重新分配其它Consumer,會造成重複消費，雖有冪等操作但耗費消費資源，亦增加集羣壓力
2、集羣不穩定：Rebalance擴散到整個ConsumerGroup的所有消費者，因爲一個消費者的退出，導致整個Group進行了Rebalance，並在一個比較慢的時間內達到穩定狀態，影響面較大
3、影響消費速度：頻繁的Rebalance反而降低了消息的消費速度，大部分時間都在重複消費和Rebalance
四、避免rebalance措施
1、業務需要不可避免
（1）針對分區個數的增加， 一般不會常有，是需要增加的時候都是業務及數據需求，不可避免
（2）對Topic的訂閱增加或取消亦不可避免
2、合理設置消費者參數
下邊是我們遇到的，要格外關注及重視
（1）未能及時發送心跳而Rebalance
session.timeout.ms 一次session的連接超時時間
heartbeat.interval.ms 心跳時間，一般爲超時時間的1/3，Consumer在被判定爲死亡之前，能夠發送至少 3 輪的心跳請求
（2）Consumer消費超時而Rebalance
max.poll.interval.ms 每隔多長時間去拉取消息。合理設置預期值，儘量但間隔時間消費者處理完業務邏輯，否則就會被coordinator判定爲死亡，踢出Consumer Group，進行Rebalance
max.poll.records 一次從拉取出來的數據條數。根據消費業務處理耗費時長合理設置，如果每次max.poll.interval.ms 設置的時間較短，可以max.poll.records設置小點兒，少拉取些，這樣不會超時。
總之，儘可能在max.poll.interval.ms時間間隔內處理完max.poll.records條消息，讓Coordinator認爲消費Consumer還活着
參考：《深入理解Kafka:核心設計與實踐原理》朱忠華