Kafka Reblance

蓝星 2020年04月06日 239次浏览

对于Kafka来说,当consumer变化或者partion变化时,会触发partion的reblance,使得partion的分配再次平衡。

reblance的时机

一般来说,出现以下情况kafka会进行reblance |时机|场景| |-------|-------| |消费者(consumer)实例发生变化|当消费者进行上下线,新消费者加入,或者宕机时,消费者数量会发生变化,导致partion的重分配(reblance)| |分区(partition)数量发生变化|消息数量太多,对partion进行扩容,会触发partion的重新分配|

reblance步骤

一、FIND_COORDINATOR(寻找协调器) 消费者向集群中的某个节点(负载最小的节点)发送FindCoordinator请求,并同步当前的消费位移,查找对应的GroupCoordinator(每个消费者组维护一个Coordinator,负责消费者和partion的在均衡操作) 二、JOIN_GROUP(加入消费组) 当找到GroupCoordinator时,消费者向Coordinator发送JoinGroupRequest,请求加入消费组。加入消费组后会进行一些列的操作

  1. 选举leader:选举消费组中的leader,选举策略:如果当前消费者有leader,则不再进行选举,如果没有,则最早加入的选举为leader。
  2. 选举分区策略:获取所有消费者都支持的分区策略,然后每个消费者进行投票,得票最多的分区策略选定为当前的分区策略

三、SYNC_GROUP(同步分配方案) leader消费组选举出分区策略后,通过Coordinator将分区策略同步给各个消费者,同时将各个消费者对应的分区信息同步给消费者。 四、HEART_BEAT(同比心跳) 经过前三步,partion已经再次Rebalance,消费组内的所有消费者都已经就绪,准备进行消息消费。

应用发布过程中频繁reblance解决方案

当应用频繁上下线时,会导致频繁的reblance,导致资源的浪费。一般来说有几个参数可以控制Coordinator进行reblance

  • heartbeat.interval.ms:表示消费者心跳间隔时间,一般超过这个时间仍未检测到心跳,则认为消费者下线,会触发Rebalance
  • session.times.out:session超时时长
  • max.pull.interval.ms:指定消费者管理poll()最大的间隔时间,也就是消费者调用poll()的最常间隔,当超过这个时间消费者仍未调用poll()时,则会进行再次分配。

一般来说,我们可以通过适当延长session.time.out和max.pull.interval.ms,只要我们重新发布机器时间小于设置的值就不会再次进行Rebalance。