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的过程如下：
- Controller 在 ZooKeeper 的 /brokers/topics 节点上注册 watcher，当检测到新的topic 被创建，则 controller 会从 /brokers/ids 读取当前所有可用的 broker 列表，为这个topic创建partition和replica对象。
- 对于每一个partition，从分配给该 partition 的所有 replica中任选一个可用的 broker 作为新的 leader，并将其他broker设置为ISR（In-sync replicas）
- 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state
从上述的流程可以看出，Controller利用了zookeeper的watcher机制，动态监听topic节点的改变，从而进行分配partition和replica，选择leader，设置ISR并将这些信息存储到到zookeeper中。
3. Producer写消息
因此，Producer写一条消息的流程如下：
- Producer查询ZooKeeper，获得对应partition的leader
- Producer向该leader写一条消息，Leader收到后写入本地
- 该Leader的follwer会持续的从leader处pull消息，收到后写入本地，然后返回ack给leader
- leader收到ISR中所有的follower的ack消息后，返回ack消息给producer
上述流程针对于配置了ack = all的Producer，如果ack = 1，那么leader就不会等待follower的应答而直接返回ack给Producer。这两种方式也被称为Synchronous replication和Asynchronous replication。
