抛去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.订阅主题的分区数发生变更