Kafka 原理、消息存储机制、Message学习（ISR）

Topic中的所有数据分布式的[color=red][b]存储在kafka集群的所有机器(broker)上，[/b][/color]以分区(partition)的的形式进行数据存储；每个分区允许存在备份数据/备份分区(存储在同一kafka集群的其它broker上的分区)。

[color=blue][b]每个数据分区在Kafka集群中存在一个broker节点上的分区叫做leader，存储在其它broker上的备份分区叫做followers；[/b][/color]只有leader节点负责该分区的数据读写操作，followers节点作为leader节点的热备节点，从leader节点备份数据；当leader节点挂掉的时候，followers节点中会有一个节点变成leader节点，重新提供服务

Kafka集群的Partition的leader和followers切换依赖Zookeeper

[b]Kafka分布式保证的第一个特性就是：[/b][color=red][b]Kafka的Replication[/b][/color]

Kafka的Replication指的是Partition的复制，一个Partition的所有分区中只有一个分区是leader节点，其它分区是follower节点。

Replication对Kafka的吞吐率有一定的影响，但是极大的增强了可用性

Follower节点会定时的从leader节点上获取增量数据，一个活跃的follower节点必须满足一下两个条件：

[b]1.所有的节点必须维护和zookeeper的连接(通过zk的heartbeat实现)[/b]
2.follower必须能够及时的将leader上的writing复制过来，不能“落后太多”; “落后太多”由参数[color=red][b]{replica.lag.time.max.ms}[/b][/color]和[color=red][b]{replica.lag.max.messages}[/b][/color]决定。

[b]Kafka分布式保证的第二个特性就是：[/b][color=red][b]Kafka Leader Election[/b][/color]

Kafka提供了一个in-sync replicas(ISR)来确保Kafka的Leader选举，ISR是一个保存分区node的集合，如果一个node宕机了或数据“落后太多”，leader会将该node节点从ISR中移除，只有ISR中的follower节点才有可能成为leader节点

Leader节点的切换基于Zookeeper的Watcher机制，[size=medium][color=blue][b]当leader节点宕机的时候，其他ISR中的follower节点会竞争的在zk中创建一个文件目录(只会有一个follower节点创建成功)，创建成功的follower节点成为leader节点[/b][/color][/size]

一个Topic分为多个Partition来进行数据管理，[color=red][b]一个Partition中的数据是有序、不可变的，使用偏移量(offset)唯一标识一条数据，是一个long类型的数据。[/b][/color]

Partition接收到producer发送过来数据后，会产生一个递增的offset偏移量数据，同时将数据保存到本地的磁盘文件中[color=blue][b](文件内容追加的方式写入数据)[/b][/color]；Partition中的数据存活时间超过参数值(log.retention.{ms,minutes,hours}，默认7天)的时候进行删除(默认)

Consumer根据offset消费对应Topic的Partition中的数据(也就是每个Consumer消费的每个Topic的Partition都拥有自己的offset偏移量)

[color=red][b]注意：Kafka的数据消费是顺序读写的，磁盘的顺序读写速度(600MB/sec)比随机读写速度(100k/sec)快。[/b][/color]

[size=medium][color=red][b]一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成。[/b][/color][/size]

[color=blue][b]header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。[/b][/color]当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保存一些相关属性，比如是否压缩、压缩格式等等)；如果magic的值为0，那么不存在attributes属性

[size=medium][color=red][b]body是由N个字节构成的一个消息体，包含了具体的key/value消息[/b][/color][/size]

存储在磁盘的日志采用不同于Producer发送的消息格式，每个日志文件都是一个“log entries”序列，每一个log entry包含一个四字节整型数(message长度，值为1+4+N)，一个字节的magic，四个字节的CRC32值，最终是N个字节的消息数据。每条消息都有一个当前Partition下唯一的64位offset，指定该消息的起始下标位置，存储消息格式如下：

[img]http://dl2.iteye.com/upload/attachment/0124/6702/1b341c3a-c110-38b6-87cd-ed7a41aefbb4.png[/img]

这个“log entries”并非由一个文件构成，而是分成多个segment file(日志文件，存储具体的消息记录)和一个索引文件(存储每个segment文件的offset偏移量范围)。 结构如图所示：

[img]http://dl2.iteye.com/upload/attachment/0124/6704/07b599ce-75ac-328f-854f-7b8f69d6dea8.png[/img]

转自：[url]http://www.cnblogs.com/liuming1992/p/6425536.html[/url]