1 broker 保存消息
物理上把 topic 分成一个或多个 patition（对应 server.properties 中的num.partitions=3配置）
每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件），如下：
2 分区分配
在创建主题时， Kafka 首先会决定如何在 broker 间分配分区。
假设你有 6 个 broker ，打算 创建一个包含 10 个分区的主题，并且复制系数为 3。那么 Kafka 就会有 30(10*3) 个分区副本， 它们可以被分配给 6 个 broker。 在进行分区分配时，我们要达到如下的目标。
-
在 broker 间平均地分布分区副本。对于我们的例子来说，就是要保证每个 broker 可以 分到 5 个副本。
-
确保每个分区的每个副本分布在不同的 broker 上。假设分区 0 的首领副本在 broker2 上， 那么可以把跟随者副本放在 broker3 和 broker 4 上，但不能放在 broker2 上，也不能两个都放在 broker3 上。
-
如果为 broker 指定了机架信息，那么尽可能把每个分区的副本分配到不同机架的 broker 上。这样做是为了保证一个机架的不可用不会导致整体的分区不可用。
如何实现上述目标: 使用轮询的方式.
为了实现这个目标，我们先随机选择一个 broker(假设是 4)，然后使用轮询的方式给每个 broker 分配分区来确定首领分区的位置。
于是，首领分区0 会在 broker4 上，首领分区 1 会在 broker5 上，首领分区2 会在 brokerO 上（只有 6 个 broker），并以此类推。
然后，我们从分区首领开始， 依次分配跟随者副本。
如果分区0 的首领在 broker4 上， 那么它的第一个跟随者副本会在 broker5 上， 第二个跟随者副本会在 broker O 上, ...。
分区1 的首领在 broker5 上， 那么它的第一个跟随者副本在 brokerO 上， 第二个跟随者副本在 broker1 上 ...。
3 分区文件管理
保留数据是 Kafka 的一个基本特性， 但是 Kafka 不会一直保留数据，也不会等到所有消费者都读取了消息之后才删除消息。
相反，Kafka 管理员为每个主题配置了数据保留期限， 规定数据被删除之前可以保留多长时间， 或者清理数据之前可以保留的数据量大小。
有两种策略可以删除旧数据：
- 基于时间：
log.retention.hours=168(默认一周) - 基于大小：
log.retention.bytes=1073741824( 1G )
以先到的为准.
需要注意的是，因为 Kafka 读取特定消息的时间复杂度为 O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。
4 索引
消费者可以从 Kafka 的任意可用偏移量位置开始读取消息。 假设消费者要读取从偏移量 100 开始的 1MB 消息， 那么 broker 必须立即定位到偏移量 100, 然后开始从这个 位置读取消息。
为了帮助 broker 更快地定位到指定的偏移量，Kafka 为每个分区维护了一个索引。 索引把偏移量映射到片段文件和偏移量在文件里的位置。