拋去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的消費線程，增加了一個固定長度的阻塞隊列和工作線程池進一步提高並行消費的能力
將消費數據與處理數據分離成兩個不同模塊，中間利用rpc框架或者sockect通信
知識補充：
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.訂閱主題的分區數發生變更