kafka 的存储文件结构

Kafka 的存储文件结构是其高吞吐量和高效性能的关键部分。Kafka 的存储结构是围绕 日志（Log） 的设计展开的，而每个 Kafka 分区（Partition） 都会以日志文件的形式存储。Kafka 采用了顺序写入、分段存储和索引文件的机制，来确保高效的数据存储和读取。接下来，我们将详细介绍 Kafka 存储文件的组织结构和组成部分。

1. Kafka 存储目录结构

Kafka 的存储文件分布在每个 Broker 上，每个 Kafka Broker 都有一组数据目录（Log Directory）。这些目录包含了该 Broker 上的所有 Kafka topic 分区的数据。Kafka 中的存储结构主要由以下几个部分组成：

Kafka 存储路径结构：

/kafka├── logs├── topic_name│     ├── partition_0│     │     ├── 00000000000000000000.log│     │     ├── 00000000000000000000.index│     │     ├── 00000000000000000000.timeindex│     │     ├── 00000000000000000001.log│     │     └── 00000000000000000001.index│     └── partition_1│           ├── 00000000000000000000.log│           ├── 00000000000000000000.index│           ├── 00000000000000000000.timeindex│           └── 00000000000000000001.log└── topic_name2├── partition_0└── partition_1

2. Kafka 存储文件的主要组成部分

Kafka 通过将数据写入磁盘的方式来持久化消息数据，Kafka 的每个分区在物理磁盘上的存储通常包括以下几种文件类型：

1. .log 文件（消息日志文件）

• 每个分区的数据会存储在一个或多个 .log 文件中。
• 日志文件是 Kafka 存储消息的核心文件，它记录了消息的实际内容。Kafka 会将消息以追加的方式写入 .log 文件，并且这些文件按照时间顺序进行切分。消息在 .log 文件中的存储是 不可修改的。
• 这些文件的大小是固定的，一旦某个 .log 文件达到一定大小（通常是 1GB），Kafka 会将新的消息写入新的 .log 文件。

2. .index 文件（索引文件）

• 索引文件用于帮助 Kafka 快速定位日志文件中的消息位置。每个 .log 文件都有一个对应的 .index 文件。
• .index 文件记录了每条消息的偏移量（offset）和其在 .log 文件中的物理位置。通过索引文件，Kafka 能够在不扫描整个日志文件的情况下，快速找到某个偏移量对应的消息位置。

3. .timeindex 文件（时间索引文件）

• .timeindex 文件是为支持基于时间的高效查询而存在的。它记录了时间戳与消息偏移量之间的映射。
• 对于 Kafka 来说，时间戳可以是消息的生产时间，消费者可以通过 timeindex 文件找到特定时间点的消息，避免了扫描整个日志文件，提高了时间相关查询的效率。

4. .log 文件的结构

• Kafka 中的每个日志文件是由一系列消息组成的，每条消息都有一个唯一的 偏移量（offset），它表示消息在日志中的位置。
• 每条消息不仅包含数据本身，还包括时间戳、消息头、偏移量等元数据。

3. Kafka 存储文件的工作原理

• Kafka 在写入消息时，首先将消息追加到当前的 .log 文件中。当文件大小达到配置的阈值时（通常是 1GB），Kafka 会创建一个新的 .log 文件来存储新的消息。
• 顺序写入：Kafka 的存储结构设计中，所有的消息都按顺序追加写入文件。因为顺序写入能够最大化磁盘 I/O 性能，这也是 Kafka 高吞吐量的原因之一。

日志文件的生命周期：

• 写入阶段：Kafka 持续向 .log 文件中追加消息。这些消息首先通过 Producer 写入，依赖 Kafka 的磁盘顺序写入来高效处理大量数据。
• 日志切分（Segment）：一旦某个日志文件达到预定大小，Kafka 就会 切分日志文件，生成新的 .log 文件继续写入数据。每个新的日志文件（Segment）都会有一个新的 起始偏移量，确保消息的顺序性。
• 删除过期日志：Kafka 允许设置 消息保留策略，根据时间或大小删除过期的日志文件。Kafka 的日志清理机制有两种：
  1. 基于时间的清理：在一定时间内没有消费的日志会被删除。
  2. 基于大小的清理：根据磁盘占用的大小，删除较旧的日志。

4. 文件命名规范

• 日志文件命名：每个日志文件的名称是一个 递增的数字（例如 00000000000000000000.log），这个数字代表了消息的偏移量。
• 索引文件命名：与 .log 文件对应的索引文件采用相同的前缀和编号，后缀为 .index（例如 00000000000000000000.index）。
• 时间索引文件命名：时间索引文件的命名与索引文件类似，后缀为 .timeindex。

5. 日志清理与压缩（Log Compaction）

Kafka 支持两种日志清理模式：

• 删除日志（Log Deletion）：当消息过期时，Kafka 会根据时间戳或磁盘空间来删除过期的日志文件。
• 日志压缩（Log Compaction）：在这种模式下，Kafka 保留每个键的最新消息，删除旧的消息。适用于需要保持最新状态的应用场景（如用户信息或配置数据）。

稀疏索引

Kafka 的 索引文件（.index 文件） 和 时间索引文件（.timeindex 文件）都是采用 稀疏索引 的设计。

稀疏索引（Sparse Index）是指索引文件并不是对日志文件中的每一条消息都有索引，而是只对部分消息创建索引。这样做的好处是，可以减少索引的存储空间，并提高效率。与之相对的是 密集索引（Dense Index），即对日志文件中的每一条消息都有索引。

Kafka 中的索引结构

Kafka 中的索引是 稀疏的，每个分区的 .index 文件包含了日志文件中某些偏移量和消息位置的映射。具体来说：

1. 日志文件和索引文件的关系：
   • Kafka 的日志文件（.log）中存储的是实际的消息数据，每条消息都有一个唯一的偏移量（offset）。
   • 为了提高查找效率，Kafka 会在 索引文件（.index）中存储部分消息的偏移量和它们在 .log 文件中的位置。并不是每一条消息都会在索引文件中创建索引，而是按照一定的步长或间隔来做。
2. 稀疏索引的工作原理：
   • 假设每 100 条消息创建一个索引条目，那么 .index 文件中就只会存储这些间隔位置的消息偏移量及其对应的文件位置。
   • 当消费者需要查找某个特定偏移量的消息时，Kafka 会首先在索引文件中查找，并根据找到的偏移量，定位到 .log 文件中的具体位置。因为索引是稀疏的，查找过程需要扫描索引文件，但由于索引条目较少，扫描的成本通常是很低的。
3. 索引文件的组成：
   • 每个索引文件由多个条目组成，每个条目包含两个主要部分：
     • 消息的偏移量（Offset）：该消息在分区内的唯一标识符。
     • 消息在日志文件中的物理位置：该消息所在的 .log 文件中的偏移量，指示消息数据的具体位置。
4. 为什么使用稀疏索引？
   • 减少存储空间：如果对每条消息都创建索引，会极大增加存储的压力。稀疏索引通过只对部分消息进行索引，显著减少了索引的大小。
   • 提高效率：在 Kafka 中，消息是按顺序写入的，顺序读取的效率很高。稀疏索引能够在保持良好性能的同时，减少内存和磁盘的占用。
   • 性能优化：Kafka 的设计侧重于吞吐量和扩展性，稀疏索引帮助减少了不必要的索引存储负担，从而提升了整体的性能。

Kafka 时间索引文件的作用

Kafka 的时间索引文件的主要作用是为了 基于时间的消息查找。当你需要查询某个特定时间段内的消息时，Kafka 会通过时间索引来快速定位消息。这种设计对于按时间查询（例如根据消息的生产时间进行消费）非常有用。

为什么时间索引采用稀疏索引

与普通的偏移量索引（.index 文件）类似，时间索引文件的设计也是为了高效存储和快速查询，但因为时间索引文件不需要对每一条消息都进行索引，因此它也是 稀疏索引。每个时间索引文件包含的是某些时间戳和对应的消息偏移量之间的映射，并且这个映射并不是对每条消息都进行记录，而是只记录一部分关键的时间点。

时间索引文件的结构

1. 记录时间戳和偏移量的映射：
   • 时间索引文件中的每个条目包含两个主要部分：
     • 时间戳：消息的时间戳，通常是生产者生产消息时的时间。
     • 偏移量：该时间戳对应的消息在日志文件中的偏移量（即消息在 .log 文件中的位置）。
2. 稀疏索引的设计：
   • 并不是每一条消息都会在时间索引文件中进行索引，而是按照一定的时间间隔或某些关键时间点进行索引。例如，Kafka 可能每隔一段时间（如每秒、每分钟或每个消息块）就记录一个时间戳和对应的偏移量。
   • 这种方式减少了时间索引文件的大小，因为它不需要为每一条消息都记录时间戳和偏移量，只记录特定的时间点（即 稀疏的时间戳）。

时间索引的使用场景

时间索引的设计对 基于时间的查询 特别有用。假设你想要消费某个特定时间点或时间范围内的消息，Kafka 可以通过时间索引快速定位到对应的消息偏移量，而不必扫描整个日志文件。

• 快速定位时间段的消息：假如你知道某个时间点范围内的消息，你可以通过时间索引文件找到对应的偏移量，然后直接读取 .log 文件中对应的消息。
• 按时间查询：消费者可以基于生产时间来消费消息，而不是仅仅依赖于消息的偏移量。通过时间索引，Kafka 能够更加高效地支持这类场景。

.timeindex 配合 .index 文件使用

.timeindex 文件 主要存储 时间戳和偏移量（offset） 的映射，它本身并不包含消息的实际内容，而是用于提供 基于时间戳的查询 能力。为了加速查询，**.timeindex 文件需要与 .index 文件 配合使用，因为 .timeindex 文件 只存储时间戳和偏移量的映射，而 .index 文件 存储偏移量和消息物理位置的映射。正是因为有了物理位置，才能加速查询，这也是 .index 文件存储偏移量和物理位置的原因。只存储偏移量也可以查找到消息，但是走的是全盘扫描，如果配合上物理位置，就可以走索引，加速查询。

.timeindex 文件的局限

1. 不包含消息内容：
   • .timeindex 文件中只记录了 时间戳和偏移量 的映射关系。它的作用是帮助定位某个时间戳对应的偏移量，并不存储消息的实际内容。
   • 通过 .timeindex 文件，消费者可以根据时间戳找到相应的偏移量，但不能直接从 .timeindex 文件中获取消息的内容。
2. 需要与 .index 配合使用：
   • .timeindex 文件只是提供了时间戳到偏移量的映射，但消费者要读取消息内容，仍然需要依赖 .index 文件 来确定该偏移量所在的 物理位置。.index 文件通过存储 偏移量到日志文件字节位置 的映射，帮助消费者快速找到消息在日志文件中的物理位置。
   • 如果没有 .index 文件，即使找到了目标偏移量，消费者仍然需要顺序扫描日志文件来定位消息，这样就相当于“走过场”的全盘扫描，效率低下。

查询过程的优化

假设消费者需要根据某个 时间戳 来读取消息的内容，查询过程可以分为以下步骤：

1. 通过 .timeindex 文件查找偏移量：
   • 消费者通过查询 .timeindex 文件，找到接近目标时间戳的偏移量。例如，timeindex 文件中可能存储了类似以下映射：

     时间戳 1625678410000 -> 偏移量 3500
     时间戳 1625678520000 -> 偏移量 3600
     

   • 通过这种方式，消费者能够高效地通过时间戳快速定位到目标的偏移量。
2. 通过 .index 文件定位物理位置：
   • 一旦找到目标的 偏移量，消费者可以根据该偏移量去查找 .index 文件，进而定位消息在日志文件中的 物理位置（字节位置）。
   • .index 文件存储了偏移量到日志文件位置的映射，使得消费者可以直接跳转到目标位置，而不需要从头扫描整个日志文件。
3. 读取消息内容：
   • 最后，消费者直接读取该物理位置的消息内容，完成消费。

Kafka 消息的结构

Kafka 中的每条消息，通常包含以下几个部分：

1. CRC（4 bytes）
   • CRC（Cyclic Redundancy Check） 是用来校验消息数据完整性的一种技术。它用于确保消息在传输或存储过程中没有被篡改。
   • 4 个字节用于存储该消息的 CRC 校验码。发送方计算消息内容（包括键、值、头部信息等）的 CRC 校验值，并将其附加到消息中，接收方在接收到消息后，使用相同的算法进行校验，确保消息的完整性。
2. Metadata（通常包含消息的键、时间戳和其他元数据）
   • Metadata 通常包括了消息的一些附加信息，比如：
     • Key（可选）：消息的键。消息的键用于决定消息发送到哪个分区（Kafka 中是通过键来做分区的），如果没有设置键，Kafka 会使用轮询等策略将消息分配到不同的分区。
     • Timestamp（可选）：消息的时间戳。这个时间戳通常是在生产者发送消息时生成的。
     • Headers（可选）：一些额外的自定义元数据（键值对），可以携带用户自定义的消息属性。
   • Kafka 中 Metadata 的具体内容可能包括但不限于这些字段，具体取决于消息的构造和使用场景。
3. Payload（消息内容）
   • Payload 是消息的实际数据内容，即生产者发送的消息的主体部分。它是应用程序传递的核心数据，通常是 JSON、Avro、Protobuf 等格式的序列化数据。
   • 在 Kafka 消息的存储中，Payload 可能并不局限于某种特定的数据格式，而是存储了一个 字节数组，消费者可以根据实际需求进行反序列化。

结构图（更详细版本）

根据上述分析，Kafka 消息结构大致如下：

+--------------------+------------------+---------------------------+
| CRC (4 bytes)      | Metadata (varies) | Payload (message data)    |
+--------------------+------------------+---------------------------+

• CRC（4 bytes） 用于数据校验。
• Metadata 包含键（Key）、时间戳、消息头等元数据。消息头部分可能是可选的，不同版本的 Kafka 在这部分的格式上也有些许差异。
• Payload 是消息的实际数据内容。

具体示例

假设我们有一个简单的消息，包含以下内容：

• Key：userID
• Timestamp：1625678410000 （表示某个时间点）
• Payload：{"event": "login", "user": "john_doe"}

Kafka 会按以下方式组织消息：

• CRC：计算整个消息内容的 CRC 校验码（包括 Key、Timestamp 和 Payload）。
• Metadata：会包含 Key 和 Timestamp，还有可能会有自定义的 Headers。
• Payload：是 {"event": "login", "user": "john_doe"}，即消息的数据内容。

总结

• CRC 是用来校验消息是否被篡改。
• Metadata 包括消息的键（可选）、时间戳（可选）、头部信息（可选）等元数据。
• Payload 是消息的实际数据内容，通常是字节数据，可以根据应用需求进行序列化和反序列化。

总结

Kafka 的存储文件结构设计是其高吞吐量、高可靠性的关键。Kafka 的每个分区都对应一组 .log 文件、.index 文件和 .timeindex 文件，确保消息的顺序性和高效查询。每个分区的日志文件按顺序追加写入，采用了日志切分、索引和压缩等机制来保证存储效率和可扩展性。

• 日志（.log 文件）：存储消息内容；
• 索引（.index 文件）：帮助快速定位消息；
• 时间索引（.timeindex 文件）：用于基于时间的查询；
• 清理策略：通过删除过期日志或日志压缩来管理存储空间。

这些文件和机制让 Kafka 能够处理大量的消息流，同时保证高效的读写和可靠性。