作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了中间件：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 功能特性的版本兼容性信息（用于集群升级时的版本协调）。
运维小路
一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！
关注微信公众号《运维小路》获取更多内容。
