拋去cpu、記憶體等機器原因，在每個分割槽皆分配一個程序消費的情況下，利用擴機器來提高kafka消費速率已無能為力

此時發現，在實際洪峰時段的消費速率元達不到先前壓測時的消費速率

原因思考：

1.洪峰時段大量資料流來臨，導致部分consumer崩潰，觸發rebalance，從而導致消費速率下降；

2.洪峰時段consumer從broker中一次取出資料量太大，導致consumer在session.timeout.ms時間之內沒有消費完成，則consumer coordinator會由於沒有接受到心跳而結束通話，自動提交offset失敗，觸發rebalance，此外由於自動提交offset失敗，導致重新分配了partition的客戶端又重新消費之前的資料流，然後consumer重新消費，再次超時，無限迴圈；

3.上游kafka限速；

拋去原因1與原因3，針對原因2，可以採取策略為：

提高了partition的數量，從而提高了consumer的並行能力，從而提高資料的消費能力

對於單partition的消費執行緒，增加了一個固定長度的阻塞佇列和工作執行緒池進一步提高並行消費的能力

知識補充：

rebalance

rebalance本質上是一種協議，規定了一個consumer group下的所有consumer如何達成一致來分配訂閱topic的每個分割槽。比如某個group下有20個consumer，它訂閱了一個具有100個分割槽的topic。正常情況下，Kafka平均會為每個consumer分配5個分割槽。這個分配的過程就叫rebalance。Kafka提供一種角色：coordinator來執行對於consumer group的管理。

rebalance觸發條件

rebalance的觸發條件有三種：

1.組成員發生變更(新consumer加入組、已有consumer主動離開組或已有consumer崩潰了)

2.訂閱主題數發生變更——這當然是可能的，如果你使用了正則表示式的方式進行訂閱，那麼新建匹配正則表示式的topic就會觸發rebalance

3.訂閱主題的分割槽數發生變更