kafka集群依赖于ZOOKEEPER，了解kafka在zookeeper中的一些存储结构，便于更好的理解kafka的工作原理，zookeeper在kafka中扮演了举足轻重的作用(0.9版本后offest不放在zk上,由kafka内部topic自己保存),kakfa的 broker,消费者等相关的信息都存在zk的节点上,zk还提供了对kafka的动态负载均衡等机制，以下是我的测试环境ZK截取目录结构：
接下来分析一下每个节点的作用：
（1） controller_epoch
此值为一个数字,kafka集群中第一个broker第一次启动时为1，以后只要集群中center controller*控制器所在broker变更或挂掉，就会重新选举新的center controller，每次center controller变更controller_epoch值就会 + 1;
（2）controller
存储控制器broker信息，数据格式为：
{"version":1,"brokerid":0,"timestamp":"1524191485779"}
version: 版本编号默认为1,
brokerid: kafka集群中broker唯一编号,
timestamp: kafka broker*控制器变更时的时间戳
（3）brokers/topics
当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息，如下：
- test：topic名称
- partitions：分区列表，当前只有一个分区”0“
- state：Kafka的ISR的管理最终都会反馈到Zookeeper节点上。目前有两个地方会对该节点进行维护：
{"controller_epoch":1,"leader":0,"version":1,"leader_epoch":0,"isr":[0]}
- Controller来维护：Kafka集群中的其中一个Broker会被选举为Controller，主要负责Partition管理和副本状态管理，也会执行类似于重分配partition之类的管理任务。在符合某些特定条件下，Controller下的LeaderSelector会选举新的leader，ISR和新的leader_epoch及controller_epoch写入Zookeeper的相关节点中。同时发起LeaderAndIsrRequest通知所有的replicas。
- leader来维护：leader有单独的线程定期检测ISR中follower是否脱离ISR, 如果发现ISR变化，则会将新的ISR的信息返回到Zookeeper的相关节点中。
（4）brokers/ids
每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),此节点为临时znode(EPHEMERAL)，存放的内容格式如下。
{
"listener_security_protocol_map": {
"PLAINTEXT": "PLAINTEXT"
},
"endpoints": ["PLAINTEXT://hostname:port"],
"jmx_port": -1,
"host": "host ip",
"timestamp": "1524191485634",
"port": port,
"version": 4
}
（5）brokers/topics/_consumer_offsets
新版kafka将消费者的位置信息（offset）保存在kafka内部的topic中，就是这里的__consumer_offsets topic,并且提供了kafka-consumer-groups.sh供用户查看消费者信息。