Kafka放弃Zookeeper后如何持存储主题与消费组呢？（二）

2、消费组存储在位点主题中

在较低版本中，启动Kafka消费组需要指定zookeeper集群的地址，因为在低版本中消费组的元信息存储在zookeeper中，具体路径为/consumers，但后续版本中消费端的启动已经不需指定zookeeper，而是指定broker的地址列表即可，那这个时候，消费组的信息是存储在哪呢？

在前面介绍Kafka故障解决相关的文章中我们常常看到消费组组协调器，内部持有一个消费组元数据管理器GroupMetadataManager，相关的代码截图如下所示：

 
在GroupMetadataManager对象中持有一个Map结构的缓存，其键为消费组的名称，值为GroupMetadata对象，内部记录消费组的状态，消费组的成员列表，位点信息。

内存的特点：访问高效，但随着Broker进程的退出而丢失，消费组存储在内存中显然不行，但又不在zookeeper中，那消费组的定义信息存储在什么地方呢？

2.1消费组元信息存储
消费组的定义信息存储在系统主题__consumer_offsets中，什么，这个主题不是用来存储消费位点的吗？

原来__consumer_offsets不仅存储消费组的位点信息，还存储消费组的元信息，具体代码入口：GroupMetadataManager#storeGroup,部分代码截图如下所示：

 
即消费组元信息当成一条消息写入到__consumer_offsets，一条消费组元信息存储的value值，由GroupMetadataManager的groupMetadataValue方法定义，具体代码如下：

 
随着Kafka的不断演化，存储格式进行了多次修改，对应的版本如下：

• V0：Kafka 0.10级以下版本
• V1：大于 0.10，低于等于2.1版本。
• V2：2.2版本及以后
  消费组元信息存储的格式为Json，具体存储的内容：
• protocol_type 协议版本，取自AbstractCoordinator的抽象方法protocolType()，消费组的固定为：consumer。
• generation 消费组元信息的版本号，每发生一次消费组重平衡，该值会加一。
• protocol 协议内容，存储消费组的队列负载算法，在构建消费者时可通过partition.assignment.strategy参数传递，可以传递多个，消费组具体的负载算法会选择每一个消费者都支持的协议进行队列负载，默认的负载算法为RangeAssignor。
• leader 当前消费组的Leader，通常为第一个加入该消费组的消费者。
• current_state_timestamp 最新状态变更的时间戳，该值是从V2版本开始引入。
• members 消费组的成员信息，每一个成员信息存储的信息如下：
• member_id 成员id,客户端id(clientId) + uuid。
• client_id 客户端ID。
• client_host 客户端ip地址。
• rebalance_timeout 重平衡时间，默认为300000,5分钟。
• session_timeout 会话超时时间，默认为10s。
• subscription 元信息，取自AbstractCoordinator的抽象方法metadata()，消费组的实现类为ConsumerCoordinator，主要是遍历负载算法，每一个负载算法根据订阅信息计算元信息。
• assignment

各个消费者的队列负载情况。
⚠️温馨提示：GroupMetadataManager的storeGroup方法的调用时间是在消费组进行重平衡时，具体是重平衡第二阶段(SYNC_GROUP)与完成重平衡。
2.2加载消息组元信息
消费组元信息是存储在 __consumer_offsets主题中，在什么时候会从该主题中加载到内存中呢？

在__consumer_offsets的分区发生Leader选举时会触发将对应分区中的数据加载到内存，具体的处理入口在KafkaApis的handleLeaderAndIsrRequest方法，简易调用链如下图所示：

 
3、总结

本文主要介绍了Kafka 主题与消费组的持久化机制，在Kafka2.8版本开始，官方逐步去除对Zookeeper的依赖，那kafka3.x之后，又会是如何存储消费组、主题的信息呢？大家可以尝试思考后，笔者也将在该专栏的后续文章中加以介绍，敬请期待。

文章转自公众号：中间件兴趣圈