涉及到的相关项目为
kafka 0.8.1.1
zookeeper 3.3.6
环境下面的存储的结构
图片中描述了kafka在zk中的存储结构，以及存储的相关数据，绿色代表的是zk的临时节点，当对应的进程退出后，此临时的znode将自动删除。由于consumer的offset节点保存对应的partition的消息队列的消息消费情况，当消费者退出后，继任的消费者需要在之前结束的地方继续下去，因此，此节点不是临时节点。
kafka创建的队列情况为：
Topic:test_kafka PartitionCount:3 ReplicationFactor:3 Configs:
Topic: test_kafka Partition: 0 Leader: 2 Replicas: 1,2,0 Isr: 2,0,1
Topic: test_kafka Partition: 1 Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
Topic: test_kafka Partition: 2 Leader: 2 Replicas: 0,1,2 Isr: 2,0,1
Partition 为3个，Replicas 为3个。
下面详细介绍每类主要节点：
Controller epoch:
/controller_epoch -> int (epoch)
此值为一个数字,kafka集群中第一个broker第一次启动时为1，以后只要集群中center controller中央控制器所在broker变更或挂掉，就会重新选举新的center controller，每次center controller变更controller_epoch值就会 + 1;
Broker注册信息
/brokers/ids/[0...N]
每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),此节点为临时znode(EPHEMERAL)
Schema:
{
“jmx_port”:-, //JMX的端口号
“timestamp”:”1416789803974″,//broker启动的时间戳
“host”:”JobTracker”, //broker 进程所在的机器的机器名
“version”:1, //默认的版本
“port”:9092 //broker进程的对外监听的端口号
}
/brokers/topics/topic1/partition/[0...n]
保存broker上面建立的topic队列的相关信息，以及对应的分区的数量，以及每个分区的元数据。
Schema:
{
“controller_epoch”:9, //中央控制器的总的选举次数
“leader”:2, //此partition的broker leader的id
“version”:1, //默认版本号
“leader_epoch”:7, //此partition的leader选举的次数
“isr”:[2,0,1] //同步副本组brokerId顺序列表
}
Controller注册信息:
存储center controller中央控制器所在kafka broker的信息
Schema:
{
“version”:1,
“brokerid”:3,
“timestamp”:”1416789802220″
}
Consumer注册信息:
每个consumer都有一个唯一的ID(consumerId可以通过consumer的客户端配置文件指定,也可以由系统自动生成，建议开发者自己制定ID),此id用来标记消费者信息.
/consumers/[groupId]/ids/[consumerIdString]
Schema:
{
“version”:1,
“subscription”:{“test_kafka”:3},//订阅topic列表
“topic名称”: consumer中topic消费者线程数[与队列的分区数量有关]
“pattern”:”static”,
“timestamp”:”1416810012297″
}
Consumer owner:
/consumers/[groupId]/owners/[topic]/[partitionId]/consumer_thread
用来保存每个topic的的partition的是由那个消费者线程进行消费的信息。
Consumer offset:
/consumers/[groupId]/offsets/[topic]/[partitionId] /offset number
此节点是持久化节点，保存当前需要处理的消息的偏移量，用来继任消费者继续此节点开始处理消息。