从图中可以看出Consumer和ConsumerGroup之间的关系,即一个Consumer对应一个ConsumerGroup,一个ConsumerGroup包含多个Consumer。另外,一个ConsumerGroup中的不同Consumer只能消费不同的Partition,跨ConsumerGroup中的Consumer则没有这个限制,即ConsumerA1和ConsumerB1可以消费同一个Partition。
二、Consumer向Broker发送消息的完整流程(从启动到消费)
Consumer只能消费topic中某个partition的数据(其中topic个数可为多个)。为了获取分配的partition,Consumer需要经过下面的几个步骤。
第一步:Consumer发送GroupCoordinator请求获取GroupCoordinator所在节点。
如下图,ConsumerA1向Broker1请求GroupCoordinator节点,ConsumerA2向Broker3请求GroupCoordinator节点,Broker集群需要保证Broker1和Broker3分配的是同一个GroupCoordinator(注意一个Broker对应一个GroupCoordinator),这里是通过MedataCache来保证。MedataCache数据在集群中是一致的。
image.png
第二步:Consumer发送JoinGroup请求加入GroupCoordinator。
假设在第一步中分配结果为Broker2中的GroupCoordinator。此时ConsumerA1和ConsumerA2将分别提交JoinGroup请求加入GroupCoordinator。JoinGroup请求包含消费者的订阅信息、支持的分区分配器、和自定义数据。Broker2中GroupCoordinator收到请求后,会从中选取一个Consumer做为Leader,还会选取一个支持所有Consumer的分区分配策略,然后以JoinGroupResponse返回。图中ConsumerA1被选取作为了Leader。虽然每个消费者都会收到JoinGroupResponse,但是只有 Leader Consumer收到的JoinGroupResponse中封装了其他消费者的信息。当消费者确定自己是Leader后,会根据消费者的信息以及选定的分区分配策略进行分区分配。
image.png
第三步:Consumer发送SyncGroup请求获取分区分配。
如图所示,ConsumerA1和ConsumerA2各自发送SyncGroup请求去获取分区分配结果。它们的分配结果是在上一步由ConsumerA1分配的。
image.png
第四步:Consumer发送OffsetFetch请求获取分区消费位置。
假设第三步的分配结果为ConsumerA1对应Partition1-Leader,ConsumerA2对应Partition2-Leader。因为ConsumerA1和ConsumerA2从未消费过Partition数据,所以返回的offset为-1。
image.png
第五步:Consumer发送OffsetsRequest请求获取分区消费位置。
因为第四步未得到ConsumerA1和ConsumerA2的消费offset,所以ConsumerA1和ConsumerA2需要发送OffsetsRequest到各自的leader partition所在的broker以至获取起始offset。
image.png
第六步:Consumer发送Fetch请求获取数据。
ConsumerA1和ConsumerA2根据上一步获取的offset从各自的Partition Leader中获取数据。
image.png
第七步:Consumer发送OffsetCommit请求到GroupCoordinator保存消费offset。
保存offset的目的是为了Consumer可以接着上次的消费offset继续消费(比比如Consumer重启)。
image.png
第八步:Consumer发送Heartbeat请求到GroupCoordinator。
Consumer发送心跳请求到GroupCoordinator。若GroupCoordinator在一个时间段内未检查到Consumer的心跳请求,则GroupCoordinator会要求ConsumerGroup中Consumer的Reblance,进而重新从第二步开始运行。