在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监听变更