Kafka在Zookeeper存储结构

在Kafka2.8之前，Kafka强依赖zookeeper，2.8版本之后Kafka可以采用KRaft（Kafka Raft）模式，逐步去除对zookeeper的依赖（依然兼容）。在zookeeper中存储了很多kafka元数据信息, 例如 「Broker的注册信息」、「Topic的信息」 、 「运维操作临时信息 」、 「配置信息」等等其他信息。

/brokers/topics/[topic]： 存储某个topic的partitions所有分配信息

{
   
	"version": "版本编号目前固定为数字1",
	"partitions": {
   
		"partitionId编号": [同步副本组brokerId列表],
		"partitionId编号": [同步副本组brokerId列表]
	}
}

/brokers/topics/[topic]/partitions/[0…N]： 分区状态信息，记录谁是leader，有哪些服务器能用

{
   
	"controller_epoch": 表示kafka集群中的中央控制器选举次数,
	"leader": 表示该partition选举leader的brokerId,
	"version": 版本编号默认为1,
	"leader_epoch": 该partition leader选举次数,
	"isr": [同步副本组brokerId列表]
}

/brokers/ids/[0…N]： 记录broker的信息，每个broker的配置文件中都需要指定一个数字类型的id（全局不可重复）,此节点为临时znode（EPHEMERAL）

{
   
	"jmx_port": jmx端口号,
	"timestamp": kafka broker初始启动时的时间戳,
	"host": 主机名或ip地址,
	"version": 版本编号默认为1,
	"port": kafka broker的服务端端口号,由server.properties中参数port确定
}

/controller: 辅助选举leader，记录当前Controller角色的BrokerId,数据示例:{“version”:1,“brokerid”:0,“timestamp”:“1624415590383”}，删除该节点立马触发重新选举

/controller_epoch: 记录选举次数，kafka集群中第一个broker第一次启动时为1，以后只要集群中center controller中央控制器所在broker变更或挂掉，就会重新选举新的center controller，每次center controller变更controller_epoch值就会 + 1

/log_dir_event_notification: 序列号持久节点，当某个Broker上的LogDir出现异常时（比如磁盘损坏,文件读写失败,等等异常）； 向zk中新增一个子节点/log_dir_event_notification/log_dir_event_序列号 ；Controller监听到这个节点的变更之后,会向Brokers们发送LeaderAndIsrRequest请求;；然后做一些副本脱机的善后操作

/isr_change_notification/log_dir_event_{序列号}: 当Isr有变更的时候,会写入这个节点Controller监听变更