从零学习Kafka：数据存储

下载好之后进行解压并进入到对应的目录。tar -xzf kafka_2.13-4.1.1.tgz cd kafka_2.13-4.1.1接着我们执行下面两条命令进行一些必要的配置。KAFKA_CLUSTER_ID$(bin/kafka-storage.sh random-uuid) bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c config/server.properties为了方便观察文件切分我把 segment 文件大小调整为了 1MB具体修改方法为编辑 config/server.properties 文件修改log.segment.bytes参数的数值。修改好之后就可以启动 Kafka 集群了。bin/kafka-server-start.sh config/server.properties可以观察日志看集群是否启动成功集群启动之后我们手动创建一个测试 topic。bin/kafka-topics.sh --create \ --bootstrap-server localhost:9092 \ --topic test-topic \ --partitions 2 \ --replication-factor 1接着可以使用 Kafka 提供的压测工具来写入一批数据。bin/kafka-producer-perf-test.sh \ --topic test-topic \ --num-records 50000 \ --record-size 100 \ --throughput -1 \ --producer-props bootstrap.serverslocalhost:9092这里我分两次写入每次写入了 50000 条数据每条数据大小 100 字节也就是一共写入了大约 10MB 数据。现在把目光投向/tmp/kraft-combined-logs这个目录。如果没有这个目录需要看一下集群配置的目录。Broker 根目录首先来看第一级目录drwxr-xr-x 10 wheel 320 1月 31 00:25 __cluster_metadata-0 -rw-r--r-- 1 wheel 355 1月 31 00:14 bootstrap.checkpoint -rw-r--r-- 1 wheel 0 1月 31 00:14 cleaner-offset-checkpoint -rw-r--r-- 1 wheel 4 1月 31 00:52 log-start-offset-checkpoint -rw-r--r-- 1 wheel 122 1月 31 00:14 meta.properties -rw-r--r-- 1 wheel 42 1月 31 00:52 recovery-point-offset-checkpoint -rw-r--r-- 1 wheel 42 1月 31 00:52 replication-offset-checkpoint drwxr-xr-x 23 wheel 736 1月 31 00:33 test-topic-0 drwxr-xr-x 27 wheel 864 1月 31 00:33 test-topic-1这里一共有 9 个文件目录大体上可以分为三类集群元数据、数据目录和 Checkpoint 文件。集群元数据meta.properties是 Broker 的身份证这里记录了 Cluster ID 和 Node ID。bootstrap.checkpoint用于记录集群初始化信息。__cluster_metadata-0是一个特殊的数据目录它记录了集群的元数据因此我将其归类到集群元数据中。数据目录test-topic-0和test-topic-1这两个目录就是我们 test-topic 的两个 partition 存储数据的目录待会儿再详细分析目录下的内容现在你只需要知道 Kafka 是以 topic名 partitionId 来命名数据目录的。Checkpoint 文件剩下的都是 checkpoint 文件是用于宕机重启后的快速恢复的。cleaner-offset-checkpoint这是清理检查点文件只有设置了cleanup.policycompact时才有用它记录了上一次 Log Compact 各个 partition 已清理的偏移量。log-start-offset-checkpoint日志起始位置记录每个分区第一个有效的 Offset。recovery-point-offset-checkpoint记录每个 partition 已刷盘的 Offset。replication-offset-checkpoint记录每个 partition 已同步的 Offset这里记录的就是 High Watermark。Partition 存储结构现在我们再来看下数据目录下的各个文件的作用是什么。核心三兄弟首先来介绍数据存储的核心分别是.log、.index和.timeindex文件每个 Segment 都会有这三个文件它们的文件名都是文件内存的第一条消息的 Offset。log 文件.log是消息数据文件Kafka 接收的消息都会顺序写入到这个文件中。可以通过下面这个命令查看文件的内容~/workspace/kafka_2.13-4.1.1/bin/kafka-dump-log.sh --files test-topic-0/00000000000000009472.log --print-data-log可以看到 log 文件中存储的主要是 Offset 和具体的序列化后的数据。index 文件.index文件是偏移量索引文件这里的索引是稀疏索引文件内存储的是 Offset 到 log 文件位置的映射。我们使用下面这条命令来查看文件内容~/workspace/kafka_2.13-4.1.1/bin/kafka-dump-log.sh --files test-topic-0/00000000000000009472.index --deep-iterationKafka 默认每 4KB 数据写入一次索引这个值可以通过log.index.interval.bytes参数调整。timeindex 文件.timeindex是时间戳索引文件用来支持 by_duration 按照时间回溯。查看文件内容的方法与查看 index 文件的方法类似~/workspace/kafka_2.13-4.1.1/bin/kafka-dump-log.sh --files test-topic-0/00000000000000009472.timeindex --deep-iteration我们在定位数据时可以通过二分法在 index 索引文件中找到对应的数据位置或者最接近的位置也可以先通过时间在 timeindex 文件中找到最接近的 Offset再到 index 文件中找到数据位置。辅助文件除了上述三个核心文件之外在数据目录中还有三种辅助文件我们来看下它们的作用。.snapshot文件是用来记录事务快照的。用于 Exactly-Once 语义如果 Broker 宕机可以通过加载这个文件知道 Producer 之前发送到哪里了防止数据重复。查看文件内容的方法如下~/workspace/kafka_2.13-4.1.1/bin/kafka-dump-log.sh --files test-topic-0/00000000000000009472.snapshotleader-epoch-checkpoint文件是一个 Leader “任期表”它记录了每一任 Leader 开始工作时的 Offset主要用于在选主时保证数据一致性。partition.metadata文件是 Partition 的“身份证“它存储了 Topic ID。Page Cache至此我们已经比较细致的了解了 Kafka 底层存储结构。到这里不知道你会不会有疑问Kafka 是写磁盘的为什么速度还会这么快Kafka 在操作磁盘时重度依赖操作系统的 Page Cache 功能这个功能就是 Kafka 性能高的原因之一。简单来说Page Cache 就是在读取磁盘时操作系统会把读到的数据放到内存中一份这块内存就是 Page Cache。在 Kafka 的应用场景中Producer 写入顺序写入数据时操作系统会先把数据写到 Page Cache然后异步刷盘。在 Consumer 消费数据时由于大部分情况下都是消费最新数据因此要读的数据大概率还在 Page Cache 中 操作系统可以直接从内存中返回。题外话Kafka 为什么不自己维护一套缓存机制呢我觉得主要有以下原因避免 GC 开销如果自己在 JVM 内存中维护缓存那么会带来很大的 GC 压力。如果用操作系统的 Page Cache就完全不用担心 GC 问题。Page Cache 对内存的利用率更高如果 Kafka 进程重启Page Cache 也还会在内存中数据不需要重新加载。逻辑简单Kafka 只需要负责读写操作剩下的缓存维护逻辑全部交给操作系统。总结本文我们了解了 Kafka 物理层面的数据存储。在 Broker 根目录下有集群元数据、数据目录、Checkpoint 文件三种类型的文件目录。在数据目录中最核心的三种文件是.log、.index和.timeindex三种文件它们分别存储了数据、稀疏 Offset 索引以及时间戳与 Offset 的映射。