5.1 集群成员的关系
Kafka使用Zookeeper来维护集群成员的信息。
5.2 控制器
控制器就是一个broker，除了具有一般broker的功能之外，还负责分区首领的选举。
Kafka使用Zookeeper的临时节点来选举控制器，并在节点加入集群或退出集群时通知控制器。控制器负载在节点加入集群或离开集群时进行分区首领选举。控制器使用epoch来避免”脑裂“。“脑裂”是指两个节点同时认为自己是当前的控制器。
5.3 复制
Kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。
副本保存在broker上，每个broker可以保存成百上千个属于不同主题和分区的副本。
*首领副本
每个分区都有一个首领副本。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
*跟随者副本
任务就是从首领副本那里复制消息，保持和首领一致的状体。
每个分区都有一个首选首领——创建主题时选定的首领就是分区的首选首领。
5.4 处理请求
broker的大部分工作就是处理客户端、分区副本和控制器发送给分区首领的请求。
请求类型：
生产请求
生产者发送的请求，它包含客户端要写入broker的消息
获取请求
在消费者和跟随者副本需要从broker读取消息时发送的请求
5.4.1 生产请求
最后消息被写入本地磁盘。
5.4.2 获取请求
Kafka使用零复制技术向客户端发送消息——Kafka直接把消息从文件（Linux文件系统缓存）里发送到网络通道，而不需要经过任何中间缓冲区。
5.4.3 其他请求
元数据请求、生产请求和获取请求。
客户端在网络上使用的通用二进制协议。
5.5 物理存储
基本存储单元是分区。分区无法在多个broker间进行再细分，也无法在同一个broker的多个磁盘上进行再细分。
配置Kafka的时候，管理员指定了一个用于存储分区的目录清单——也就是log.dirs参数的值。
5.5.1 分区分配
在创建主题时，Kafka首先会决定如何在broker间分配分区。
单独为每个分区分配目录，规则很简单：计算每个目录里的分区数量，新的分区总是被添加到数量最小的那个目录里。
5.5.2 文件管理
Kafka管理员为每个主题配置了数据保留期限，规定数据被删除之前可以保留多长时间，或者清理数据之前可以保留的数据量大小。
分区分成若干个片段，当前正在写入数据的片段叫做活跃片段。
5.5.3 文件格式
把Kafka的消息和偏移量保存在文件里。保存在磁盘上的数据格式与从生产者发送过来或发送给消费者的消息格式是一样的。
5.5.4 索引
消费者可以从Kafka的任意可用偏移量位置开始读取消息。
为了更快定位到指定的偏移量，Kafka为每个分区维护了一个索引。
索引把偏移量映射到片段文件和偏移量在文件里的位置。
5.5.5 清理
5.5.6 清理的工作原理
每个日志片段分为以下两个部分：
干净的部分：
这些消息之前被清理过，每个键只有一个对应的值，这个值是上一次清理时保留下来的。
污浊的部分：
这些消息是在上一次清理之后写入的。
5.5.7 被删除的事件
为了彻底把一个键从系统里删除，应用程序必须发送一个包含该键且值都为null的消息。
5.5.8 何时会清理主题
5.9 总结