Consumer 加入&离开 Group详解(九)

图片看不到可以看我的CSDN的博客:
https://blog.csdn.net/u013332124/article/details/83548706

一、GroupCoordinator 概念

GroupCoordinator是运行在Broker上的一个服务,用来管理Consumer Group的member和各个partition的消费进度,这里的member指的是我们的KafkaConsumer实例。

broker在启动的时候会启动一个GroupCoordinator实例。一个集群可能有多个broker,那么怎么确定一个新的Consumer要和哪个broker上的GroupCoordinator交互呢?

这就和kafka上的一个内部使用的topic __consumer_offsets有关系了。

__consumer_offsets

consumer_offsets是kafka内部使用的一个topic,专门用来存储group具体消费的情况,默认情况下,这个topic有50个partition,每个partition有3个副本。我们进入某个broker的日志目录,一般都能看到该topic对应的partition目录,如下图:

在这里插入图片描述

Consumer如何找到对应的GroupCoordinator

__consumer_offsets的会分布在各个broker,当一个新的Consumer要寻找和它交互的GroupCoordinator时,需要先对它的GroupId进行hash,然后取模__consumer_offsets的partition数量,最后得到的值就是对应partition,那么这个partition的leader所在的broker就是我们要交互的那个broker了。获取partition公式如下:

abs(GroupId.hashCode()) % NumPartitions

NumPartitions为__consumer_offsets的数量。GroupId为初始化Consumer时指定的groupId。

举个例子,假设一个GroupId计算出来的hashcode是5,之后取模50得到5。那么partition-5的leader所在的broker就是我们要找的那个节点。这个Consumer后面都会直接和该broker上的GroupCoordinator交互。

二、Consumer加入Group流程

Consumer在拉取数据之前,必须加入某个group,在consumer加入到group的整个流程中,主要涉及到了3种请求:

  • GROUP_COORDINATOR请求
  • JOIN_GROUP请求
  • SYNC_GROUP请求

GROUP_COORDINATOR请求

前面我们知道了通过__consumer_offsets和对应的公式可以算出要和哪台broker上的GroupCoordinator做交互,但是我们并不知道__consumer_offsets的各个partition位于哪些broker上。比如我们通过公式算出了要和__consumer_offsets的partition-5所在的broker做交互,但是我们不知道它的partition-5的leader在哪个broker上。因此我们需要先往集群的一个broker发送一个GROUP_COORDINATOR请求来获取对应的brokerId。

要往哪个broker发送GROUP_COORDINATOR请求也不是随机选择的,kafka会默认选择一个当前连接数最少的broker来发送该请求。这个连接数是指inFightRequest,也就是当前客户端发往broker还未返回的那些连接数量。

broker处理:

kafka的broker接收到GROUP_COORDINATOR请求后,会通过公式abs(GroupId.hashCode()) % NumPartitions算出对应的partition,然后搜索__consumer_offsets的metadata,找到该partition leader所在的brokerId,最后返回给客户端。

这里要注意一点:

  1. 如果__consumer_offsets被删除了或者还未创建,broker找不到对应的metadata时,会自动创建一个新的名为__consumer_offsets的topic然后再查找对应的brokerId。

JOIN_GROUP请求

找到要交互的broker后,客户端就会往该broker发送 JOIN_GROUP请求了。

JOIN_GROUP请求主要是让Consumer加入到指定的group中,broker上的GroupCoordinator服务会管理group的各个Consumer。

broker收到 JOIN_GROUP请求后,让目标group进入 PreparingRebalance状态,等待一段时间后,返回一些信息,这些信息包括Consumer在group中对应的memberId以及该group的leaderId、generationId(每次reblance都会+1)等等,如果对应consumer是leader,那么还会将当期组中所有的members信息返回给leader用于后面让leader来分配各个member要消费的partition(第一个加入该group的consumer就是该group的leader)。

Consumer收到broker返回的信息后,如果没有错误则表示已经加入到该Group中了。接着继续发送SYNC_GROUP请求。

SYNC_GROUP请求

前面的JOIN_GROUP请求只是加入目标group,还没有真正的分配partiton。SYNC_GROUP请求就是用于获取consumer要消费哪些partition用的。

Consumer根据前面JOIN_GROUP请求的返回值,会判断自己是否是leader,如果是leader,就直接获取group中的所有members然后使用PartitionAssignor的实现类来为group中的各个Consumer分配要消费哪些partition,PartitionAssignor的默认实现是RangeAssignor,也可以通过配置partition.assignment.strategy来指定不同的分配策略。最后leader把分配好的信息封装成SYNC_GROUP请求发送给broker。

如果consumer是follower,就直接发送一个SYNC_GROUP请求给broker。

broker收到SYNC_GROUP请求后,根据group中的leader给的分配信息在内存中给每个member分配对应的partiton,然后将这些信息返回给对应的consumer。

最后,各个group中的consumer就得到了自己要消费的partition,就可以开始拉取数据了。

三、Group的状态变更

对于一个 Consumer Group,它会有五种状态:Dead、Empty、AwaitingSync、PreparingRebalance、Stable。状态间的变更关系如下图所示:

[图片上传失败...(image-f69012-1542368543646)]

Empty状态

Empty状态表示该Consumer Group中没有任何member。新建的Group都是处于这个状态,它可能转化为以下两种状态

  • PreparingRebalance:如果有新的member加入,状态就会变更成PreparingRebalance,等待partition-rebalance开始。
  • Dead:如果该group被移除掉,状态就会变成Dead。

PreparingRebalance状态

PreparingRebalance状态表示该Group正在等待partition-rebalance开始。这个状态存在的目的主要是为了等待所有的member都加入到该Group中了,然后开始进行partition rebalance(也就是进入AwaitingSync状态)。这样就可以尽量保证在进行partition reblance时,group中的member不会发送变动。它可能转化为以下三种状态:

  • Dead:如果该group被移除掉,状态就会变成Dead
  • AwaitingSync:第一个发送PreparingRebalance请求的Consumer返回后,group的状态就会变成AwaitingSync,等待重新分配partition
  • Empty:group中最后一个member离开了,group重新变为Empty状态

AwaitingSync状态

AwaitingSync状态表示该Group正在等待重新分配partition的结果,partiton的分配是由member的leader来进行的,等leader发来SYNC_GROUP请求,GroupCoordinator知道partiton的分配情况了,Group状态就会变成Stable。它可能转化为以下三种状态:

  • Dead:如果该group被移除掉,状态就会变成Dead
  • PreparingRebalance:如果有新的member加入或者旧成员离开,状态会重新变回PreparingRebalance,等待新的一轮partition分配
  • Stable:partition分配完成,进入Stable状态

Stable状态

Stable状态表示目前Group已经给各个Consumer分配好各自要消费的partition了。只要Group没有发生成员变动或者member要消费的元数据没发送变动(比如某topic的partition数量变更),状态就会一直维持在Stable。它也可能转化为以下两种状态:

  • Dead:如果该group被移除掉,状态就会变成Dead
  • PreparingRebalance:如果有新的member加入或者旧成员离开,状态会重新变回PreparingRebalance,等待新的一轮partition分配

Dead状态

Dead状态表示该Group已经被移除掉了。如果__consumer_offsets的partition分布发生变动,就会导致Group可能不属于该broker上的GroupCoordinator管理,GroupCoordinator就会移除Group。

正常consumer加入group中的状态变动情况

Empty —> PreparingRebalance —> AwaitingSync —> Stable

当一个consumer发送 JOIN_GROUP请求要求加入一个新的group时,GroupCoordinator发现之前没有这个group,就会新建一个group,此时该group的状态为Empty。之后由于有新成员加入,状态迅速转变为PreparingRebalance。另外,GroupCoordinator收到JOIN_GROUP请求后会等待一段时间再返回,让该Group在PreparingRebalance状态等待一定时间,以确保该加入的member都加入了。

PreparingRebalance再返回JOIN_GROUP请求后,就会把Group的状态置为AwaitingSync。 Consumer收到响应后,会再发送SYNC_GROUP请求等待partition分配完成。如果该Consumer是leader,则该Consumer会在本地进行partition的分配,然后把partition的分配结果随着SYNC_GROUP请求一起上报给GroupCoordinator。之后GroupCoordinator收到leader发送过来的分配情况,就会将状态置为Stable,之后将这些信息作为SYNC_GROUP请求的响应发送给各个Consumer,各个Consumer就都得到了自己要消费的partition。

四、Consumer心跳机制

Consumer在加入Group后,会开启一个线程,不断的向GroupCoordinator发送心跳请求,报告自己还活着。GroupCoordinator会管理group中所有Consumer的心跳,如果发现有一个Consumer超过一定时间没有发送心跳过来,GroupCoordinator会认为这个Consumer已经离开group。这时GroupCoordinator会将该group的状态重新置为PreparingRebalance,开启新一轮的partition分配。

心跳的发送频率和consumer的配置 heartbeat.interval.ms有关,默认是3000,也就是每3s发送一次心跳。

GroupCoordinator判断member是否过期和consumer的配置session.timeout.ms有关,默认为10000,也就是超过10s没收到心跳请求,就移除该member。

Group处于Stable状态下,新加入一个Consumer

如果目前group已经处于stable状态了(各个consumer都在消费了),又新加入了一个Consumer,那么状态会怎么变更呢?

首先,新的Consumer会发送一个 JOIN_GROUP请求给GroupCoordinator,GroupCoordinator收到请求后发现这是一个新的member,就会将group的状态置为PreparingRebalance,然后等待其他member也发送 JOIN_GROUP请求。

那么其他正在消费的consumer怎么知道要重新分配partition呢?这个就和心跳机制有关系了。Consumer发送心跳给GroupCoordinator的时候,如果GroupCoordinator发现此刻group的状态是PreparingRebalance,就会告诉Consumer需要重新分配partition了,各个Consumer收到消息后就开始重新发送JOIN_GROUP请求。

Consumer离开可能引发的Group状态变更

当Consumer超过一定时间没有发送心跳,GroupCoordinator会认为该Consumer已经离开group。此时GroupCoordinator会将该group的状态置为PreparingRebalance,等待新一轮的parition分配。

五、 __consumer_offsets topic中的消息

在之前老的版本中,consumer消费的offset情况是存储在zookeeper中的,但是kafka对zk的依赖性很强,当consumer的数量不断增多,zk的负担也会越来越大,最终可能会影响到zk的正常运行。因此,在后面的版本中,kafka设计者将consumer的commitedoffset写到内部的一个topic中,也就是__consumer_offsets。

__consumer_offsets存储的两种消息类型

除了存储Consumer Group的commitedOffset外, __consumer_offsets中其他还存储了另外一种消息类型:GroupCoordinator管理的元数据信息,这些元数据包括GroupCoordinator管理的所有Group的信息,比如Group的状态,Group的leader信息,以及Group的各个member信息,但不包括Group中各个topic-partition的commitedOffset。kafka通过消息key的不同来区分两种消息类型

  1. commitedOffset 消息类型

它的key是 GroupId+topic+partition,value是对应的offset。

  1. GroupCoordinator 消息类型

它的key是 GroupId,value是对应的元数据信息

__consumer_offsets 消息的加载和写入

数据加载

[图片上传失败...(image-14e902-1542368543647)]

为了读取更快,无论是commitedOffset,还是GroupCoordinator的元数据,都会从 __consumer_offsets中加载出来缓存起来。这些数据在broker启动的时候加载的。

一个broker在启动的时候,并不会知道自己机器上的那些partition是leader还是replica,所以无法立即从 __consumer_offsets中加载数据。如果这时有Consumer来拉取offset,kafka就会抛出一个异常给Consumer,Consumer等待会等待若干时间后再次请求。

在broker启动后,Controller会感应到有新的broker启动,然后知道这个broker上的partition哪些是leader,哪些是replica,之后发送一个LEADER_AND_ISR请求给该broker。该Broker收到这个请求,解析附带的请求数据,就可以知道自己机器上的parition哪些是leader,哪些是replica了。接着,如果发现这些partition有__consumer_offsets的话,就开始读取__consumer_offsets的数据并加载的内存中。

加载的流程也很简单,kafka会预先申请5M的内存空间,然后从目标partition的第一条offset开始读取,直到读取到最后一个offset为止。由于kafka会定时对 __consumer_offsets进行compact,因此__consumer_offsets的partition大小一般也不会太大。

commitedOffset消息写入

当有Consumer提交OFFSET_COMMIT请求时,就会往__consumer_offsets的对应partition写入消息了。由于kafka对这个topic开始了消息压缩(Compact),因此随着时间的流逝,相同的key,旧的记录会被清除掉,只剩下最新的那个key

GroupCoordinator元数据写入

在Group状态变为Stable后,GroupCoordinator会将当前Group的相关元数据写入对应partiiton。当有成员离开Group,Group状态变成Empty的时候,也会写一条消息到partition。

你可能感兴趣的:(Consumer 加入&离开 Group详解(九))