一.背景介绍
项目上进行算法调度的需求，打算采用kafka作为消息中间件，通过将多个算法消费者加入到同一个group中并行的处理算法请求，从而达到高效处理的目的。但是算法处理的时间较长，多则几十分钟，短的几分钟。测试的结果是算法时间过长的消费者会引发kafka的rebalance，消费者无法再消费到新数据。
二.rebalance机制介绍
为了弄懂上述问题，还需要了解relance的机制。由于rebalance机制资料较多，在此只进行简单介绍。
Kafka保证同一groupId的consumer只会消费某条消息（即不重复消费也不漏数据），rebalance划分同一groupId的消费者与topic的分区的一一对应关系。因此每当有消费者加入或是退出时，必定会发生一次rebalance。在rebalance完成之前，消费者是拿不到任何数据的。
三.参数调整
简单了解rebalance后，再进行kafka的参数调整。此次调整涉及参数如下：
props.setProperty("enable.auto.commit", "false");
props.setProperty("auto.offset.reset", "earliest");
props.put("max.poll.records", "1");
props.put("max.poll.interval.ms",180000000);//5小时
props.put("heartbeat.interval.ms","2000");
参数说明：
1. "enable.auto.commit"设置为false后，消费后数据后需要手动调用consumer.commitAsync(),以保证将偏移量信息提交至kafka服务端。"enable.auto.commit"也可设置为true，便不必再手动调用consumer.commitAsync()；
2.props.put ("session.timeout.ms",”1800000”),该条参数使用默认值即可，建议不要调整。测试时将该参数调大后，会引发groupId再次消费时无效的问题。
3."heartbeat.interval.ms"->"2000"，测试时心跳时使用默认值或是调整2秒均可，理论值应该为"session.timeout.ms"的1/3，但是建议不要调整。
4. props.put("max.poll.records", "1")，每次poll拉取数据的最大条数。测试环境是一条kafka数据，对应一个算法任务，算法处理时间较长，因此测试时设置为1。
5. props.put("max.poll.interval.ms",180000000)，该参数时间一定要设置大点，超过消费处理的最大时间开销。如果该参数较小，消费者处理时间超过该参数后，会引发两个现象。一个是偏移量提交会报错。一个是groupId会被移出消费组，再使用该groupId时无法正常
拿到数据。
四、调整后的问题。
按上述参数调整后，多个算法消费者均可以正常消费kafka数据了，但是碰到新的问题。
如果有2个算法消费者正在处理，一个算法需要3分钟，另一个算法需要20分钟。当加入一个新的算法消费者后会触发一次rebalance,触发rebalance完成后所有消费者还必须要等待那个处理20分钟的算法消费者调用consumer.poll()接口后，所有消费者才能正常接收数据。
Rebalance之后，会划分完消费者与分区对应关系，空闲的分区所对应的消费者理论上应该在rebalance之后可以直接消费数据。至于为什么非要等待所有消费者执行consumer.poll()接口后才能拿到数据，暂不知其中的原因。
五、总结
Kafka适用于吞吐量高，消费者处理能力高的场景，不太适用消费者处理能力低的场景。如果消费者处理能力低，可以使用其他的中间件，比如：rabbitmq。