谈谈Kafka Consumer Group的Coordinator与Rebalance机制

前言

前段时间写了三个Spark Streaming程序,负责从Kafka订阅群和用户消息,并做舆情监控必须的ETL工作。它们消费的Topic各自不同,但是分配的group.id都相同。运行一段时间之后,发现偶尔抛出如下所示的异常。

ERROR [org.apache.spark.streaming.scheduler.JobScheduler] - Error generating jobs for time 1579570560000 ms
java.lang.IllegalStateException: No current assignment for partition my_dummy_topic-11
    at org.apache.kafka.clients.consumer.internals.SubscriptionState.assignedState(SubscriptionState.java:251)
    at org.apache.kafka.clients.consumer.internals.SubscriptionState.needOffsetReset(SubscriptionState.java:315)
    at org.apache.kafka.clients.consumer.KafkaConsumer.seekToEnd(KafkaConsumer.java:1170)
    at org.apache.spark.streaming.kafka010.DirectKafkaInputDStream.latestOffsets(DirectKafkaInputDStream.scala:192)
    at org.apache.spark.streaming.kafka010.DirectKafkaInputDStream.compute(DirectKafkaInputDStream.scala:209)
......

经过Google确定是由于我们使用的Spark Streaming 2.3版本无法处理Kafka Consumer Rebalance而引起的,见SPARK-22968及其对应的PR。我们通过进一步查看日志,确实发生了Rebalance。

那么本文就来说说Rebalance机制,先从执行Rebalance的主体——Consumer Group谈起。

Consumer Group

为了使得Consumer易于组织、可扩展以及更好地容错,Kafka将一个或多个Consumer组织为Consumer Group,即消费者组。Consumer Group的唯一标识就是group.id。Group内的所有Consumer共同消费已订阅的各个Topic的所有Partition,并且保证每个Partition只分配给该Group内的唯一一个Consumer。对Consumer Group的管理就是实现以下三个职责:

  • 分配并维护Consumer与Partition的消费对应关系,即"who owns what"。(重新)分配消费对应关系的过程就叫Rebalance
  • 记录并提交Consumer消费Partition的消费位点(Offset值),即"consumed up to where";
  • 维护Consumer Group的配置信息与Consumer元数据。

下面简单介绍Consumer Group的管理。

Group Coordinator

在0.9版本之前,Kafka强依赖于ZooKeeper实现Consumer Group的管理:

  • Group内每个Consumer通过在ZK内抢注节点来决定消费哪些Partition,并注册对Group和Broker相关节点的监听,以获知消费环境的变化(其他Consumer掉线、Broker宕机等),进而触发Rebalance;
  • Offset值也维护在ZK中,老生常谈了。

这种方式除了过于依赖ZK,导致ZK压力偏大之外,还有两个分布式系统中常见且严重的问题:

  • 羊群效应(herd effect)——一个被监听的ZK节点发生变化,导致大量的通知发送给所有监听者(即Consumer);
  • 脑裂(split brain)——ZK只保证最终一致性,不同的Consumer在同一时刻可能看到不同的Group和Broker状态,造成Rebalance混乱。

所以从0.9版本开始,Kafka重新设计了名为Group Coordinator的“协调者”服务负责实现上述职责,将这部分工作从ZK剥离开来。每个Broker在启动时,都会顺带启动一个Group Coordinator实例。每个Consumer Group在初始化时,都会分配给一个Group Coordinator实例来管理消费关系和Offset,如下简图所示。

https://img.hchstudio.cn/The%20Silver%20Bullet%20for%20Endless%20Rebalancing.pdf

Group Coordinator提交Offset时也不再是向ZK写,而是写入那个广为人知的特殊Topic——__consumer_offsets里。key是group-topic-partition格式的,value为Offset值。

那么该如何确定一个Consumer Group被分配给哪个Group Coordinator呢?Kafka根据groupId.hashCode() % offsets.topic.num.partitions取绝对值来得出该Group的Offset信息写入__consumer_offsets的分区号,并将Group分配给该分区Leader所在的Broker上的那个Group Coordinator。

上面粗略讲了Group Coordinator和它的第二个职责的实现方式,接下来仔细分析第一个职责,就是Rebalance的机制。

Rebalance触发条件与协议

我们已经知道,Rebalance就是一个Consumer Group内的所有Consumer分配消费各已订阅的Topic的各Partition的过程。Partition的分配有内置的三种算法实现(range、round-robin、sticky),用户也可以自定义分配规则,这个与本文关系不太大,就不再展开说。

那么有哪些条件会触发Rebalance呢?列举如下:

  • Group发生变更,即新的Consumer加入,或原有的Consumer离开。Consumer离开可以是主动的(退出),也可以是被动的(崩溃);
  • Partition发生变更,包含订阅的Topic被创建或删除,以及现有订阅Topic新增Partition等。

本文只考虑Group发生变更的情况。Kafka定义了一个简单的协议来处理这种情况下的Rebalance过程,包含以下4对请求/响应:

  • heartbeat:Group中的Consumer周期性地给Coordinator发送该心跳信号,表示自己存活;
  • join-group:Consumer请求加入Group的信号;
  • leave-group:Consumer主动退出Group的信号;
  • sync-group:Coordinator将已生成的Consumer-Partition消费对应关系分发给Consumer的信号。

下面三张图示出心跳超时(被动退出)、主动退出和加入Group的情况。

心跳超时——注意heartbeat.interval.ms与session.timeout.ms两个参数的作用
主动退出Group
加入Group

图中的红色叹号表示Coordinator感知到了变化,并触发Rebalance过程。

Rebalance过程

整个Rebalance分为两个大步骤:JOIN和SYNC。

JOIN

正如其名,在这一步中,所有Consumer都会向Coordinator发送join-group,请求重新加入Group(那些原本已经在Group内的也不例外),同时放弃掉已分配给自己的Partition。以有新的Consumer主动加入Group(即上一节中的第三种情况)为例,图示如下。

图中的sync. barrier线就是表示JOIN步骤与SYNC步骤之间的分界,即从发起Rebalance开始到接受最后一个join-group之间的超时。需要特别注意的是,Broker端和Consumer端判定这个阶段超时的标准是不同的,Broker端使用rebalance.timeout.ms,而Consumer端使用max.poll.interval.ms。所以当遇到不明原因的长时间Rebalance时,应考虑max.poll.interval.ms的设定。

SYNC

这一步需要做的事情是:

  • Coordinator在所有Consumer里选择一个担任Leader,并由Leader调用Partition分配规则来确定消费对应关系。
  • 各个Consumer发送sync-group请求。Leader发送的请求里包含有已经确定的消费分配信息,其他Consumer的请求为空。
  • Coordinator将消费分配信息原样封装在sync-group响应中,并投递给各个Consumer,最终使Group内所有成员都获知自己该消费的Partition。

图示如下,其中C1被选为Leader。SYNC步骤结束后,原有的1~6六个分区被分配给了C1~C3三个Consumer。Rebalance就完成了。

Rebalance的改进方案

上述Rebalance机制沿用了很长时间,但是它同样存在问题:

  • stop-the-world问题——需要收回(revoke)所有Partition再重新分配(reassign),在此时间内,所有Consumer都无法进行消费。如果Rebalance时间长,会造成lag。
  • back-and-forth问题——如果多次触发Rebalance,很有可能造成一个Consumer消费的Partition被分配给其他Consumer,然后又分配回来,做了无用功。

为了解决该问题,在2.4版本特别提出了Incremental(增量)Rebalance。顾名思义,就是Rebalance时不再让所有Consumer都放弃掉所有已分配的Partition,而是每次先记录,并转化成多次少量的Rebalance过程,且Consumer在此期间不会STW。简图如下所示。

关于该方案的细节,请参考KIP-429

The End

民那晚安。祝身体健康,百毒不侵。

推荐阅读更多精彩内容