Kafka什么时候进行rebalance？

1.topic下分区的数量增加了或者减少了。(这个一般是我们手动触发的) 2.消费者的数量发生了改变，例如新增加了消费者或者有消费者挂掉了。 Kafka有一个session.timeout.ms，最大会话超时时间，最长是10s。就是如果broker与消费者之间的心跳包超过10s还没有收到回应，就会认为消费者掉线了。以及还有一个max.poll.interval.ms参数，消费者两次去broker拉取消息的间隔，默认是5分钟。如果消费者两次拉取消息的间隔超过了5分钟，就会认为消费者掉线了。 一旦发生rebalance了，有可能会导致重复消费的问题，就是消费者A拉取了100条消息，消费时间超过了5分钟，被broker认定下线，就会进行rebalance，把这个分区分配给其他消费者消费，其他消费者就会进行重复消费。 怎么解决rebalance带来的重复消费问题呢？ 1.可以减少每批消息的处理时间，让每条消息的处理时间减少，或者是修改max.poll.records，减小每次拉取消息的数量。 2.可以自行在MySQL或者Redis里面存储每个分区消费的offset，然后消费者去一个新的分区拉取消息时先去读取上次消费的offset。 3.为消息分配一个唯一的消息id，通过消息id来判定是否重复消费了。 ### kafka 1.1的优化 新版本新增了group.initial.rebalance.delay.ms参数。空消费组接受到成员加入请求时，不立即转化到PreparingRebalance状态来开启reblance。当时间超过group.initial.rebalance.delay.ms后，再把group状态改为PreparingRebalance（开启reblance），这样可以避免服务启动时，consumer陆续加入引起的频繁Rebalance。 ### Kafka2.3对reblance的优化 但对于运行过程中，consumer超时或重启引起的reblance则无法避免，其中一个原因就是，consumer重启后，它的身份标识会变。简单说就是Kafka不确认新加入的consumer是否是之前挂掉的那个。 在Kafka2.0中引入了静态成员ID，使得consumer重新加入时，可以保持旧的标识，这样Kafka就知道之前挂掉的consumer又恢复了，从而不需要Reblance。这样做的好处有两个： 降低了Kafka Reblance的频率 即使发生Reblance，Kafka尽量让其他consumer保持原有的partition，减少了重分配引来的耗时、幂等等问题