kafka系列12——第6章1——kafka存储-CSDN博客

本文链接：https://blog.csdn.net/m0_68657832/article/details/141307484

🌈hello，你好鸭，我是Ethan，西安电子科技大学大三在读，很高兴你能来阅读。

✔️目前博客主要更新Java系列、项目案例、计算机必学四件套等。
🏃人生之义，在于追求，不在成败，勤通大道。加油呀！

🔥个人主页：Ethan Yankang
🔥推荐：史上最强八股文||一分钟看完我的几百篇博客

🔥温馨提示：划到文末发现专栏彩蛋点击这里直接传送

🔥本篇概览：详细讲解了kafka系列12——第6章1——kafka存储。🌈⭕🔥

【计算机领域一切迷惑的源头都是基本概念的模糊，算法除外】

🔥 微服务全集

🔥 kafka全集

🔥 前一篇章

🌈引出

Apache的kafka是一个分布式的消息发布订阅中间件。具有高吞吐、可扩展和容错性等特点。主要用于处理大规模的流式数据。

本博客从各个方面详细讲解了kafka的机制，并实际上手使用之，好好学完定会习得大功。（bushi，上一次面试就噶在kafka上了，好好对待之。）

第6章 Kafka存储

tips 学完这一章你可以

在完成 Kafka 应用开发的基础上，知道文件存储机制

Kafka 为什么使用磁盘作为存储介质

分析文件存储格式

快速检索消息

6.1 存储结构概述

每一个partion( 文件夹 ) 相当于一个巨型文件被平均分配到多个大小相等 segment(段) 数据文件里。但每一个段segment file 消息数量不一定相等，这样的特性方便 old segment file 高速被删除。

（默认情况下每一个文件大小为 1G ）

每一个partiton 仅仅须要支持顺序读写即可了。 segment 文件生命周期由服务端配置參数决定。

6.1.2partiton中segment文件存储结构

segment file组成：由 2 大部分组成。分别为 index file 和 data file ，此 2 个文件一一相应，成对出现，后缀”.index” 和 “.log” 分别表示为 segment 索引文件、数据文件 .

segment文件命名规则：

partion全局的第一个 segment 从 0 开始，兴许每一个 segment 文件名称为上一个segment 文件最后一条消息的 offset 值。数值最大为64 位 long 大小。 19 位数字字符长度，没有数字用 0 填充。

itcast@Server-node:/mnt/d/kafka_2.12-2.2.1$ ll /tmp/kafka/log/heima-0/
total 20480
drwxr-xr-x 1 itcast sudo 512 Aug 29 09:38 ./
drwxrwxrwx 1 dayuan dayuan 512 Aug 29 09:41 ../
-rw-r--r-- 1 itcast sudo 10485760 Aug 29 09:38 00000000000000000000.index
-rw-r--r-- 1 itcast sudo 0 Aug 29 09:38 00000000000000000000.log
-rw-r--r-- 1 itcast sudo 10485756 Aug 29 09:38 00000000000000000000.timeindex
-rw-r--r-- 1 itcast sudo 8 Aug 29 09:38 leader-epoch-checkpoint
itcast@Server-node:/mnt/d/kafka_2.12-2.2.1$

6.2 日志索引

6.2.1 数据文件的分段

Kafka解决查询效率的手段之一是将数据文件分段，比如有 100 条 Message ，它们的 oﬀset 是从 0 到 99 。

假设将数据文件分成5 段，第一段为 0-19 ，第二段为 20-39 ，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的oﬀset 命名。这样在查找指定 oﬀset的Message的时候，用二分查找就可以定位到该Message在哪个段中。

6.2.2 偏移量索引

数据文件分段使得可以在一个较小的数据文件中查找对应offset 的Message 了，但是这依然需要顺序扫描才能找到对应offset 的 Message 。为了进一步提高查找的效率， Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。

比如：要查找绝对 offset 为 7 的 Message ：

首先是用二分查找确定它是在哪个LogSegment中，自然是在第一个 Segment 中。打开这个 Segment 的 index文件，也是用二分查找找到 offset 小于或者等于指定 offset 的索引条目中最大的那个 offset 。自然 offset为 6 的那个索引是我们要找的，通过索引文件我们知道 offset 为 6 的 Message 在数据文件中的位置为9807 。

打开数据文件，从位置为9807 的那个地方开始顺序扫描直到找到offset为7的那条Message。

这套机制是建立在offset 是有序的。索引文件被映射到内存中，所以查找的速度还是很快的。

一句话，Kafka 的 Message存储采用了分区(partition)，分段(LogSegment)和稀疏索引这几个手段来达到了高效性。

6.3 日志清理

6.3.1 日志删除

Kafka日志管理器允许定制删除策略。目前的策略是删除修改时间在 N 天之前的日志（按时间删除），也可以使用另外一个策略：保留最后的N GB 数据的策略 ( 按大小删除 ) 。为了避免在删除时阻塞读操作，采用了copy-on-write 形式的实现，删除操作进行时，读取操作的二分查找功能实际是在一个静态的快照副本上进行的，这类似于Java 的 CopyOnWriteArrayList 。 Kafka 消费日志删除思想： Kafka 把 topic 中一个parition 大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用

log.cleanup.policy=delete启用删除策略
直接删除，删除后的消息不可恢复。可配置以下两个策略：清理超过指定时间清理：
log.retention.hours=16
超过指定大小后，删除旧的消息：
log.retention.bytes=1073741824

6.3.2 日志压缩

将数据压缩，只保留每个key 最后一个版本的数据。首先在 broker 的配置中设置

log.cleaner.enable=true 启用 cleaner ，这个默认是关闭的。在 Topic 的配置中设置

log.cleanup.policy=compact 启用压缩策略。

压缩后的oﬀset 可能是不连续的，比如上图中没有 5 和 7 ，因为这些 oﬀset 的消息被 merge[合并] 了，当从这些oﬀset消费消息时，将会拿到比这个 oﬀset 大的 oﬀset 对应的消息，比如，当试图获取 oﬀset 为 5 的消息时，实际上会拿到oﬀset 为 6 的消息，并从这个位置开始消费。

这种策略只适合特俗场景，比如消息的key 是用户 ID ，消息体是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。

压缩策略支持删除，当某个Key 的最新版本的消息没有内容时，这个 Key 将被删除，这也符合以上逻辑。

6.4 磁盘存储优势

文件追加

Kafka在设计的时候，采用了文件追加的方式来写入消息，即只能在日志文件的尾部追加新的消息，并且不允许修改已经写入的消息，这种方式属于典型的顺序写入此判断的操作，所以就算是Kafka 使用磁盘作为存储介质，所能实现的吞吐量也非常可观。

页缓存

Kafka中大量使用页缓存，这也是 Kafka 实现高吞吐的重要因素之一。

零拷贝技术

除了消息顺序追加，页缓存等技术，Kafka 还使用了零拷贝技术来进一步提升性能。 “ 零拷贝技术 ” 只用将磁盘文件的数据复制到页面缓存【在内核中】中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制操作。如果有10 个消费者，传统方式下，数据复制次数为4*10=40 次，而使用 “ 零拷贝技术 ” 只需要 1+10=11 次，一次为从磁盘复制到页面缓存， 10 次表示10 个消费者各自读取一次页面缓存。