Kafka 读写原理与存储结构

1. Kafka消息存储

我么知道，Kafka中一个Topic由多个partition组成。Kafka会为每个partition按照topicName-partitionNumber的方式创建文件夹（文件夹位于log.dir属性定义的目录下）。例如有一个名为report的topic，它拥有4个partition，那么Kafka会为其创建4个数据文件夹：

report-0
report-1
report-2
report-3

其中每个文件夹下都存储着对应partition的数据文件。

1.1 Segment

在物理上partition中的数据是存储在Segment文件中的。一个partition拥有多个Segment文件。每个Segment文件存储着partition中的部分数据。如下图所示：

Segment.JPG

• Segment文件：Segment并不是一个单一的文件，它包括一个.index文件（存储数据索引）和一个.log（存储真实数据）文件。这两个文件一一对应。
• Segment命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局partion的最大offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

例如：

0000000000000000000.index
0000000000000000000.log （存储着offset在0~67892的数据）
0000000000000067892.index
0000000000000067892.log （存储着offset从67893开始的数据）

可以看到，.log数据文件按照offset序号命名，这样根据offset读取message时，可以快速定位到对应的.log文件。同时每一个.log文件都对应着一个同名的.index文件，它存储着对应的.log文件中数据的索引。如图所示：

index.JPG

.index文件中存储的格式为offset-address，例如3, 497代表着对应.log文件中offset为3的message，它的物理偏移地址为497。这儿的3代表着这条message在此log中的相对offset，而不是真实的message的offset。真实的message的offset应该是 368769 + 3，即.index文件名序号 + 相对offset。index文件中只存储相对offset的目的是节省存储空间。

因此，Broker根据offset查找message的流程如下：

• 通过offset定位到对应的.index文件和.log文件
• 查找对应的.index文件，找出该消息的物理偏移地址
• 读取.log文件，根据物理偏移地址找到该条消息

2. Controller对象

Kafka集群中在启动时，会从Broker中选取一个成为Controller。Controller主要负责partition管理和replica管理。具体的选举方案是Broker自动向ZooKeeper注册宣布成为Controller，最先成功的Broker就成为了Controller对象。

下面是Controller的主要职责：

• Broker 的上线、下线处理
• 新创建的 topic 或已有 topic 的分区扩容，处理分区副本的分配、leader 选举
• topic 删除、副本迁移、leader 切换等处理

客户端创建一个topic时，只需要和zookeeper通信，在对应的znode节点新建一个子节点即可。但是有了topic，还需要分配partition和replica，还要选出partition的leader，以及ISR（In-sync replicas）等，而这些工作，都是由controller来完成。

Controller创建partition和replica的过程如下：

1. Controller 在 ZooKeeper 的 /brokers/topics 节点上注册 watcher，当检测到新的topic 被创建，则 controller 会从 /brokers/ids 读取当前所有可用的 broker 列表，为这个topic创建partition和replica对象。
2. 对于每一个partition，从分配给该 partition 的所有 replica中任选一个可用的 broker 作为新的 leader，并将其他broker设置为ISR（In-sync replicas）
3. 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state

从上述的流程可以看出，Controller利用了zookeeper的watcher机制，动态监听topic节点的改变，从而进行分配partition和replica，选择leader，设置ISR并将这些信息存储到到zookeeper中。

3. Kafka replica机制

Leader会维护一个与其保持同步的Replica列表，该列表称为ISR（in-sync Replica）。如果一个Follower复制的Offset落后于Leader太多（落后数量上限由replica.lag.max.messages决定），或者超过一段时间内未发起数据复制请求（由replica.lag.time.max.ms决定），Leader会将该Follower从ISR中移除。

Producer在向某个partition写入一条消息时，先通过 Metadata （通过 Broker 获取并且缓存在 Producer 内） 找到该 Partition 的Leader。然后只向Leader发送消息写入的请求。之后Leader会将消息写入本地log（但不commit），之后每个Follower都从Leader pull数据。Follower在收到该消息并写入其Log后，向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW（high watermark，表示已经commit的消息的位置，只有Offset小于HW的消息才会暴露给Consumer消费）表示该消息提交成功。

4. Producer写消息

因此，Producer写一条消息的流程如下：

1. Producer查询ZooKeeper，获得对应partition的leader
2. Producer向该leader写一条消息，Leader收到后写入本地
3. 该Leader的follwer会持续的从leader处pull消息，收到后写入本地，然后返回ack给leader
4. leader收到ISR中所有的follower的ack消息后，返回ack消息给producer

上述流程针对于配置了ack = all的Producer，如果ack = 1，那么leader就不会等待follower的应答而直接返回ack给Producer。这两种方式也被称为Synchronous replication和Asynchronous replication。

5. Kafka如何选举Leader

最简单最直观的方案是，所有 Follower 都在 ZooKeeper 上设置一个 Watch，一旦 Leader 宕机，其对应的 ephemeral znode（临时节点） 会自动删除，此时所有 Follower 都尝试创建该节点，而创建成功者（ZooKeeper 保证只有一个能创建成功）即是新的 Leader，其它 Replica 即为 Follower。

但是该方法会有 3 个问题：

• split-brain 这是由 ZooKeeper 的特性引起的，虽然 ZooKeeper 能保证所有 Watch 按顺序触发，但并不能保证同一时刻所有 Replica“看”到的状态是一样的，这就可能造成不同 Replica 的响应不一致
• herd effect 如果宕机的那个 Broker 上的 Partition 比较多，会造成多个 Watch 被触发，造成集群内大量的调整
• ZooKeeper 负载过重 每个 Replica 都要为此在 ZooKeeper 上注册一个 Watch，当集群规模增加到几千个 Partition 时 ZooKeeper 负载会过重。

Kafka 0.8 的 Leader Election 方案解决了上述问题，它在所有 broker 中选出一个 controller，所有 Partition 的 Leader 选举都由 controller 决定。controller 会将 Leader 的改变直接通过 RPC 的方式（比 ZooKeeper Queue 的方式更高效）通知需为为此作为响应的 Broker。同时 controller 也负责增删 Topic 以及 Replica 的重新分配。