涉及到的相关项目为
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

此节点是持久化节点，保存当前需要处理的消息的偏移量，用来继任消费者继续此节点开始处理消息。