Kafka-元数据存储（ZooKeeper）

我们上一章介绍了中间件：Zookeeper，本章将介绍另外一个中间件：Kafka。目前这2个中间件都是基于JAVA语言的。

我们前面在部署Kafka的时候，选择的是需要ZooKeeper支持的版本，在 Kafka 2.8 之前的版本中，ZooKeeper 承担了以下关键职责：

• Broker 注册与集群管理：每个 Broker 启动时向 ZooKeeper 注册自身信息（如 IP、端口、分区负载等）。监控 Broker 的存活状态（通过临时节点），当 Broker 宕机时触发故障转移。如果注册到ZooKeeper地址不一样，就代表了是不同的Kafka集群。
• 控制器（Controller）选举：Kafka 集群通过 ZooKeeper 选举唯一的 Controller（主节点），负责分区副本的 Leader 选举、副本重分配等关键操作。若 Controller 宕机，ZooKeeper 会触发重新选举。

#这里重启了broker节点，就触发了控制节点重新选举 
[zk: localhost:2181(CONNECTED) 10] get /kafka/controller
{"version":1,"brokerid":0,"timestamp":"1748188211809"}
[zk: localhost:2181(CONNECTED) 11] get /kafka/controller
{"version":1,"brokerid":1,"timestamp":"1748188273615"}

• 元数据存储：Topic 的配置（如分区数、副本因子）。分区的副本分配（AR, Assigned Replicas）和同步副本集合（ISR, In-Sync Replicas）。消费者组的 Offset（旧版本 Kafka，新版本已迁移至内部 Topic __consumer_offsets）。
• ACL 权限管理：若启用安全认证，ZooKeeper 存储访问控制列表（如 Topic 读写权限）。
• 动态配置管理：支持运行时修改 Topic 或 Broker 的配置，并通知相关节点更新。

我们下面就登录到ZooKeeper里面看看数据存储是什么样的。

#这是一个3节点Kafak 集群在ZK里面存储 
#为了方便管理，单独启用一个znode目录 
[zk: localhost:2181(CONNECTED) 3] ls /kafka
[admin, brokers, cluster, config, consumers, controller, controller_epoch, feature, isr_change_notification, latest_producer_id_block, log_dir_event_notification]

1. /admin

• 作用：存储 Kafka 集群的管理操作记录，一般情况下这里都是空的。
• 关键子节点：
  • /delete_topics：记录待删除的 Topic 列表（标记 Topic 为待删除状态）。
  • /reassign_partitions：分区副本重分配任务的状态（手动调整分区副本分布时生成）。

2. /brokers

• 作用：存储所有 Broker 的注册信息及状态。
• 关键子节点：
  • /ids：每个 Broker 的注册信息，以 Broker ID 命名（如 /brokers/ids/0），存储 JSON 格式的 Broker 元数据（IP、端口、版本等）。
  • /topics：Topic 的分区副本分配信息（AR, Assigned Replicas），例如每个 Topic 的分区分布到哪些 Broker。

[zk: localhost:2181(CONNECTED) 23] get /kafka/brokers/topics/new-topic1 
{"partitions":{"0":[0,1,2],"1":[1,2,3],"2":[2,3,4],"3":[3,4,0],"4":[4,0,1]},"topic_id":"Z8p3dNm9TNqLiS8rBz8pxw","adding_replicas":{},"removing_replicas":{},"version":3}

3. /cluster

• 作用：集群级元数据。
• 关键子节点：
  • /id：集群的唯一标识符（Cluster ID），用于区分不同的 Kafka 集群。

4. /config

• 作用：存储动态配置信息。
• 关键子节点：
  • /topics：Topic 级别的动态配置（如 retention.ms、max.message.bytes 等）。
  • /clients：客户端级别的动态配置（如生产者和消费者的配额）。
  • /changes：配置变更通知（用于触发 Broker 更新配置）。

5. /consumers

• 作用：旧版本 Kafka 消费者组的 Offset 存储位置（新版本已迁移到内部 Topic __consumer_offsets）。
• 关键子节点：
  • /{group_id}/offsets/{topic}/{partition}：消费者组的消费偏移量（Offset）。
  • /{group_id}/owners/{topic}/{partition}：记录消费者与分区的分配关系（哪个消费者消费哪个分区）。

6. /controller

• 作用：存储当前 Controller（主节点）的 Broker ID，前面提到它的选举作用。
• 机制：
  • Controller 是 Kafka 集群的核心协调者，负责 Leader 选举、副本同步等操作。
  • 该节点的值是当前 Controller 的 Broker ID（如 {"version":1,"brokerid":0,"timestamp":"..."}）。
  • 若 Controller 宕机，其他 Broker 会通过 ZooKeeper 重新选举新的 Controller。

7. /controller_epoch

• 作用：记录 Controller 的纪元（Epoch）编号，用于防止脑裂（Split Brain）。和前面ZooKeeper的epoch类似。
• 机制：
  • 每次 Controller 切换时，纪元号递增。
  • Broker 在处理元数据变更时，会校验 Controller 的纪元号，确保操作来自最新的 Controller。

8. /isr_change_notification

• 作用：ISR（In-Sync Replicas）变更通知队列。
• 机制：
  • 当分区的 ISR 集合发生变化（如副本掉线或恢复）时，会在此路径下生成临时节点。
  • Controller 监听此路径，触发 ISR 变更处理逻辑（如更新元数据或重新选举 Leader）。

9. /latest_producer_id_block

• 作用：存储 Producer ID 的分配信息（用于幂等性生产者和事务）。
• 机制：
  • 每个事务型 Producer 会被分配一个唯一的 Producer ID。
  • Kafka 通过此节点记录当前已分配的 Producer ID 范围（避免重复）。

10. /log_dir_event_notification

• 作用：日志目录事件通知（如 Broker 磁盘故障）。
• 机制：
  • 当 Broker 的日志目录（Log Directory）发生异常（如不可写）时，会在此路径下生成临时节点。
  • Controller 监听此路径，触发副本迁移或告警。

11. /feature

• 作用：存储 Kafka 功能特性的版本兼容性信息（用于集群升级时的版本协调）。