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

大家好，我是威哥，《RocketMQ技术内幕》作者、RocketMQ社区首席布道师、中通快递基础架构资深架构师，越努力越幸运，唯有坚持不懈，与大家共勉。

由于笔者公司目前使用的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表示，存储的内容如下：
  1.controller_epoch 控制器当前的选举版本。
  2.leader 该分区的Leader所在的Broker节点ID。
  3.version 当前的存储格式版本，默认为1。
  4.leader_epoch 分区Leader的选举版本。
  5.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,具体操作：
  1.在/brokers/topics节点下创建子节点，子节点名称为topic的名称。
  2.根据当前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，主题中存储的值是静态数据，具体还会触发选举，选举算法会参考这个分配。
  3.控制器还会注册调用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，共同交流。

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