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

最新推荐文章于 2024-01-03 10:14:34 发布

LiangGzone

最新推荐文章于 2024-01-03 10:14:34 发布

阅读量314

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MzA5NDg3MjAwMQ==&mid=2457118224&idx=1&sn=6e7cefad6edb67e23871d687ac251eae&chksm=87c80ebeb0bf87a824d9c680b829a6797fae537fba77489789bcd04a107e3de261f4f7c99ccb&scene=126&&sessionid=0

版权

点击上方“服务端思维”，选择“设为星标”

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

作者 | 丁威

出品 | 中间件兴趣圈

由于笔者公司目前使用的kafka版本是2.2.1，故当下关于kafka的内核研究目前主要是基于该版本，当然该专栏还会继续关注Kafka3.0。

我在使用kafka时发现客户端可以不依赖Zookeeper的情况下完成消息发送、消息消费，众所周知早期的Kafka，所有的元信息(topic、消费组、集群)等信息都存储在Zookeeper中，原先的消息发送客户端、消息消费客户端都需要依赖Zookeeper。

温馨提示：Kafka逐步开启了去zookeeper化，到kafka2.8之前实现了消息发送者、消息消费者的去zookeeper化，从2.8版之后broker也支持去zookeeper。

那kafka2.2.1版本中，主题的路由信息、消费组信息分别是存储在什么地方呢？消息发送端、消息消费端是如何感知的呢？

温馨提示：如果大家对Kafka有基本的了解，不防停留片刻，稍作思考。

1、主题元数据存储在Zookeeper中

进入到Kafka Broker连接的Zookeeper集群，我们不难发现在 /{namespace}/brokers/topics节点下存在该集群中所有的主题信息，展开某一个具体的主题，如下图所示：

关于主题的元信息，其实主要包括如下信息：

分区数量每一个具体topic下会有一个partitions节点，该节点下的每一个子节点代表一个分区。
分区状态信息每一个分区的的状态由叶子节点 /{namespace}/brokers/topics/{topicName}/parttions/{partNO}/state表示，存储的内容如下：
- controller_epoch 控制器当前的选举版本。
- leader 该分区的Leader所在的Broker节点ID。
- version 当前的存储格式版本，默认为1。
- leader_epoch 分区Leader的选举版本。
- isr 分区的ISR集合。

主题的路由信息是存储在Zookeeper中，那为什么客户端只需要Broker的地址，就可以获取到主题的路由信息呢？

1.1 主题路由寻址

查找路由信息在Kafka2.1版本中是发送ApiKeys.METADATA请求,该请求的响应逻辑定义在Broker中，那客户端是如何对Broker进行路由，Broker中的路由信息又是从何而来呢？

消息发送者首次发送METADATA定位Broker机制：首次发送请求会从KafkaProducer的bootstrap.servers中设置的broker列表中选择当前最空闲的Broker，后续能感知所有的Broker。

消息消费者发送METADATA定位Broker机制：发送到当前消费组的组协调所在的Broker。

根据查阅KafkaApis的handleTopicMetadataRequest方法，进行一些ACL校验后进入其核心方法：

关键点：

从MetadataCache中获取topic到路由信息。
如果MetadataCache中不存在指定topic的路由信息，如果Broker允许自动创建主题(auto.create.topics.enable),默认为true，则自动创建该主题的信息，并将主题信息写入到zookeeper,具体操作：
- 在/brokers/topics节点下创建子节点，子节点名称为topic的名称。
- 根据当前kafka分区的机架信息，分区数、副本数，broker节点数，进行分配，主要尽量将主分区不放在同一个机架、存储在主题的节点信息中，例如{"version":1,"partitions":{"4":[2,0,1],"5":[0,1,2],"1":[2,1,0],"0":[1,0,2],"2":[0,2,1],"3":[1,2,0]}}，其中key为分区名称，值为副本所在的brokerId，其中排在第一位是倾向性Leader，主题中存储的值是静态数据，具体还会触发选举，选举算法会参考这个分配。
- 控制器还会注册调用registerPartitionModificationsHandlers方法，监听主题信息的变化，从而触发后续流程，启动分区的真正创建（各个分区的Leader选举等）。

⚠️温馨提示：Kafka开启自动创建主题，分区数量取自kafka broker中的num.partitions参数，默认为1，副本因子则取决于default.replication.factor参数，默认为1。

1.2 路由信息同步机制

MetadataCache，元信息缓存，那这里的数据又是从何而来呢？MetadataCache中路由信息的更新调用链如下图所示：

Kafka的KafkaController(后续统称控制器)首先会听/brokers/topics/{topicName}节点内容的变化，一旦有新主题创建或主题信息变更，topic变更事件就会触发，此时TopicChange的process方法会调用，最终调用updatePartitionReplicaAssignment，也就是一旦主题的信息发生变更，控制器会向所有Broker节点发送ApiKeys.UPDATE_METADATA，各个Broker在到该请求后，会更新各个Broker中的内存缓存，供消息发送者查找topic路由信息。

即Kafka2.2版本中，topic的元信息存储在Zookeeper中，同时Kafka Controller会监听zookeeper中相关节点，从而感知信息变更，从而将路由信息通过RPC发送到集群内所有的Broker中，故每一个Broker的内存中都存储一份相同的路由信息。

⚠️Kafka2.8版本开始尝试去Zookeeper化。

思考题：⚠️为什么各个Broker不都监听zookeeper，从而感知topic变化，更新本地内存呢？欢迎各位留言讨论或私信dingwpmz，共同交流。

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
  各个消费者的队列负载情况。