什麼時機觸發Rebalance
0.10kafka的rebalance條件
條件1：有新的consumer加入
條件2：舊的consumer掛了
條件3：coordinator掛了，集羣選舉出新的coordinator（0.10 特有的）
條件4：topic的partition新加
條件5：consumer調用unsubscrible()，取消topic的訂閱
寫的非常好：
線上Kafka突發rebalance異常，如何快速解決
如何避免不必要的Rebalance
kafka的Rebalance問題分析
除開consumer正常的添加和停掉導致rebalance外，在某些情況下，Consumer 實例會被 Coordinator 錯誤地認爲 “已停止” 從而被“踢出”Group，導致rebalance，這種情況應該避免。
第一類非必要 Rebalance 是因爲未能及時發送心跳，導致 Consumer 被 “踢出”Group 而引發的。這種情況下我們可以設置 session.timeout.ms 和 heartbeat.interval.ms 的值，來儘量避免rebalance的出現。（以下的配置是在網上找到的最佳實踐，暫時還沒測試過）
設置 session.timeout.ms = 6s。
設置 heartbeat.interval.ms = 2s。
要保證 Consumer 實例在被判定爲 “dead” 之前，能夠發送至少 3 輪的心跳請求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。
將 session.timeout.ms 設置成 6s 主要是爲了讓 Coordinator 能夠更快地定位已經掛掉的 Consumer，早日把它們踢出 Group。
第二類非必要 Rebalance 是 Consumer 消費時間過長導致的。此時，max.poll.interval.ms 參數值的設置顯得尤爲關鍵。如果要避免非預期的 Rebalance，你最好將該參數值設置得大一點，比你的下游最大處理時間稍長一點。
快速處理方法：
最主要的方法：
一個是增加session.timeout.ms的時間,
一個是設置不要自動提交(enable.auto.commit=false).
增加 max.poll.interval.ms處理時長，默認300s
減少 max.poll.records （每次拉取消息的條數）默認500
設置 session.timeout.ms = 30s。
設置 heartbeat.interval.ms = 10s。
session.timeout.ms 這個是消費者維護session的最大時間，如果在這個時間內消費者沒有上報狀態則認爲消費者已經斷開，max.poll.interval.ms這個是拉取的最大時間間隔，如果你一次拉取的比較多，建議加大這個值，heartbeat.interval.ms這個是通知消費者重新連接的間隔時間，這個值要比session.timeout.ms小，最好不要超過最好不要超過heartbeat.interval.ms的三分之一，在我們環境中我們把超時時間修改成60s後rebalance問題得到解決，這些參數都是針對具體場景設置，不要盲從！
大概的意思是消費者的消費速度小於生產者的產生速度,所以導致了消息堆積,但是通過之前的測試可以知道.消費者的速度其實是遠大於生產者的. 那麼是什麼原因呢? 真相只有一個:重複消費!
consumer在堆積的消息隊列中拿出部分消息來消費,但是這個拿取是隨機的(不確定,目前看來是),如果生產者一次產生的數據量過大,1秒鐘5W條,那麼consumer是有可能在規定的時間內(session.timeout.ms)消費不完的.
如果設置的是自動提交(enable.auto.commit),就會出現提交失敗的情況,提交失敗就會回滾,這部分數據就相當於沒有被消費過,然後consumer繼續去拿數據如果還沒消費完就還是回滾,這樣循環下去.(但是我發現有時候數據還是會被消費的,比如說數據小於兩萬條/次,所以我說取得數量是隨機的,應該可以設置).
https://www.cnblogs.com/muxi0407/p/11697709.html
一個是增加session.timeout.ms的時間,
一個是設置不要自動提交(enable.auto.commit=false).
最後我採取的方案是不要自動提交,因爲如果隨着我增加session.timeout.ms的時間,取得數據量也增加了那還是會超時(而且我也不知道怎麼設置每次取得數量)
最後成功解決問題.