标签：文件 log kafka offset position 日志 segment 梳理
一些必须提前知道的概念
patition
kafka日志文件是以patition在物理存储上分割的
是topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列
是以文件夹的形式存储在具体Broker本机上
LEO
表示每个partition的log最后一条Message的位置
HW（HighWatermark）
表示partition各个replicas（用于分布式存储的副本分片）数据间同步且一致的offset位置，即表示all replicas已经commit的位置 HW之前的数据才是Commit后的，对消费者才可见
Segment
每个partition又由多个segment file组成 我们说的kafka日志文件就是说的segment，下面我们主要讨论一下segment文件的结构Segment
日志目录以及文件组成
每个partition又由多个segment file组成 segment file 由2种文件组成组成，分别为index file（索引文件）和log file（日志文件） 日志文件的文件后缀为 *.log 索引文件的文件后缀为 *.index、*.timeindex 命名规则：partition的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset+1 （offset后文会提到） 下图能比较清晰的反应出来partition、segment、和文件的关系，以及在分布式系统中是如何体现的
从微观即一个partition看：
消息主题是ZXP-TEST
此消息有3个partition（创建主题时指定），每个partition会有一个自己的目录
每个partion的目录下都会有segment文件，比如第一个segment文件由三个文件组成：00000000000000000000.log、00000000000000000000.index、00000000000000000000.timeindex
三个文件的作用如上图，其中当log文件达到最大值，会新生成一套segment文件，文件都是追加写，所以写性能会比较高
我们再来从宏观即3台broker看：
broker1中partion ZXP-TEST-0是leader
broker1中partion ZXP-TEST-1是follower
broker1中partion ZXP-TEST-2是follower
那么ZXP-TEST-0对应的follower在broker2、broker3（副本数由启动参数offsets.topic.replication.factor决定）
ZXP-TEST-1对应的leader在broker2
注意：同一台broker中不能存放同一个partition的主从分片，这点很多分布式系统都有此设计
offset与position
offset偏移量：代表第几个消息
position位置：代表消息在磁盘的物理位置
其中日志文件命名中的偏移量是offset不是position，否则无法根据offset轻松找到在哪个日志文件中
日志文件内部数据结构
日志索引文件
由offset、position组成
bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.index # 也能印证日志文件命名中的偏移量是offset不是position offset:5083 position:1072592768
索引文件是有序的，可以快速根据offset寻找position，position可以快速从log文件定位消息体
时间索引文件
由timestamp、offset组成
bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.timeindex timestamp: 1603703296169 offset: 5083
时间索引文件也是有序的
日志文件
组成如下| X byte size | 描述 |
| 8 | POSITION |
| 4 | 消息大小 |
| 4 | CRC32 校验值 |
| 1 | magic kafka服务程序协议版本号 |
| 1 | attributes 独立版本或均表示压缩类型、编码类型 |
| 4 | ley lenght key的长度，-1时key不存在 |
| M | key key的内容，可选 |
| 4 | payload length 消息体的长度 |
| N | payload 消息数据 |
bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.log baseoffset:5083 position: 1072592768 CreateTime: 1603703296169
如何通过索引定位消息
找offset为7的消息
1、首先是用二分查找确定它是在哪个LogSegment中，自然是在第一个Segment中（日志文件命名中的偏移量是offset不是position）
2、打开这个Segment的index文件，也是用二分查找找到offset小于或者等于指定offset的索引条目中最大的那个offset。自然offset为6的那个索引是我们要找的，通过索引文件我们知道offset为6的Message在数据文件中的位置为9807。（Kafka 中的索引文件，以稀疏索引(sparse index)的方式构造消息的索引，它并不保证每个消息在索引文件中都有对应的索引项）
3、打开数据文件，从位置为9807的那个地方开始顺序扫描直到找到offset为7的那条Message（找到第6个消息后根据position+消息大小向后找直到找到）与rocketMQ的对比
| rocketmq | kafka | |
| 消费的offset记录 | 第几个消息，保存于offsetTable.offset json文件 | 第几个消息，保存于__consumer_offsets内置主题中 |
| 索引文件 | ConsumeQueue、（数组、下标就是offset，每行的offset其实是position） indexFile | index文件、（追加的，每条定长，offset、position） timeindex |
| 日志文件 | CommitLog（未具体研究，应该差不多） | log文件结构见上文 |
关于rocketmq的日志存储可以参考我的另一篇文章《快速弄明白RocketMQ的CommitLog、ConsumeQueue、indexFile、offsetTable 以及多种偏移量对比》
日志文件清理
Kafka将数据持久化到了硬盘上，为了控制磁盘容量，需要对过去的消息进行清理（segment文件）清理策略
1、内部有个定时任务检测删除日志，默认是5分钟 log.retention.check.interval.ms
2、支持配置策略对数据清理
3、根据segment单位进行定期清理
log.cleaner.enable=true log.cleaner.threads = 2 (清理线程数配置) log.cleanup.policy=delete #清理超过指定时间的消息,默认是168小时，7天， #还有log.retention.ms, log.retention.minutes, log.retention.hours，优先级高到低 log.retention.hours=168 #超过指定大小后，删除旧的消息，下面是1G的字节数，-1就是没限制 log.retention.bytes=1073741824
基于【时间删除】 日志说明
每个日志段文件都维护一个最大时间戳字段，每次日志段写入新的消息时，都会更新该字段 一个日志段segment写满了被切分之后，就不再接收任何新的消息，最大时间戳字段的值也将保持不变 kafka通过将当前时间与该最大时间戳字段进行比较，从而来判定是否过期基于【大小超过阈值】 删除日志 说明
假设日志段大小是500MB，当前分区共有4个日志段文件，大小分别是500MB，500MB，500MB和10MB 10MB那个文件就是active日志段。 此时该分区总的日志大小是3*500MB+10MB=1500MB+10MB 如果阈值设置为1500MB，那么超出阈值的部分就是10MB，小于日志段大小500MB，故Kafka不会执行任何删除操作，即使总大小已经超过了阈值； 如果阈值设置为1000MB，那么超过阈值的部分就是500MB+10MB > 500MB，此时Kafka会删除最老的那个日志段文件 注意：超过阈值的部分必须要大于一个日志段的大小才会删除 删除日志时不考虑，是不是还有未消费的数据，对于一个topic随时也有可能增加新的消费者标签：文件,log,kafka,offset,position,日志,segment,梳理 来源： https://www.cnblogs.com/zxporz/p/16291859.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。