每个数据分区在Kafka集群中存在一个broker节点上的分区叫做leader，存储在其它broker上的备份分区叫做followers；只有leader节点负责该分区的数据读写操作，followers节点作为leader节点的热备节点，从leader节点备份数据；当leader节点挂掉的时候，followers节点中会有一个节点变成leader节点，重新提供服务
Kafka集群的Partition的leader和followers切换依赖Zookeeper
Kafka分布式保证的第一个特性就是： Kafka的Replication
Kafka的Replication指的是Partition的复制，一个Partition的所有分区中只有一个分区是leader节点，其它分区是follower节点。
Replication对Kafka的吞吐率有一定的影响，但是极大的增强了可用性
Follower节点会定时的从leader节点上获取增量数据，一个活跃的follower节点必须满足一下两个条件：
1.所有的节点必须维护和zookeeper的连接(通过zk的heartbeat实现)
2.follower必须能够及时的将leader上的writing复制过来，不能“落后太多”; “落后太多”由参数 {replica.lag.time.max.ms}和 {replica.lag.max.messages}决定。
Kafka分布式保证的第二个特性就是： Kafka Leader Election
Kafka提供了一个in-sync replicas(ISR)来确保Kafka的Leader选举，ISR是一个保存分区node的集合，如果一个node宕机了或数据“落后太多”，leader会将该node节点从ISR中移除，只有ISR中的follower节点才有可能成为leader节点
Leader节点的切换基于Zookeeper的Watcher机制， 当leader节点宕机的时候，其他ISR中的follower节点会竞争的在zk中创建一个文件目录(只会有一个follower节点创建成功)，创建成功的follower节点成为leader节点
一个Topic分为多个Partition来进行数据管理， 一个Partition中的数据是有序、不可变的，使用偏移量(offset)唯一标识一条数据，是一个long类型的数据。
Partition接收到producer发送过来数据后，会产生一个递增的offset偏移量数据，同时将数据保存到本地的磁盘文件中 (文件内容追加的方式写入数据)；Partition中的数据存活时间超过参数值(log.retention.{ms,minutes,hours}，默认7天)的时候进行删除(默认)
Consumer根据offset消费对应Topic的Partition中的数据(也就是每个Consumer消费的每个Topic的Partition都拥有自己的offset偏移量)
注意：Kafka的数据消费是顺序读写的，磁盘的顺序读写速度(600MB/sec)比随机读写速度(100k/sec)快。
一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成。
header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保存一些相关属性，比如是否压缩、压缩格式等等)；如果magic的值为0，那么不存在attributes属性
body是由N个字节构成的一个消息体，包含了具体的key/value消息
存储在磁盘的日志采用不同于Producer发送的消息格式，每个日志文件都是一个“log entries”序列，每一个log entry包含一个四字节整型数(message长度，值为1+4+N)，一个字节的magic，四个字节的CRC32值，最终是N个字节的消息数据。每条消息都有一个当前Partition下唯一的64位offset，指定该消息的起始下标位置，存储消息格式如下：
这个“log entries”并非由一个文件构成，而是分成多个segment file(日志文件，存储具体的消息记录)和一个索引文件(存储每个segment文件的offset偏移量范围)。 结构如图所示：
转自： http://www.cnblogs.com/liuming1992/p/6425536.html