文件存储机制
1、Topic数据的存储机制
topic是逻辑上的概念,而partition是物理上的概念,每个partition对应一个log文件,该log文件中存储就是Producer生产的数据。Producer生产的数据会不断追加到该log文件末端,为防止log文件过大导致数据定位效率低下,Kafka采取可分片和索引机制,将每个partitioner分为多个segment,每个segment包括:“.index"文件、”.log"文件和timeindex等文件,这些文件位于一个文件夹夏,该文件夹的命名规则为:topic名称+分区序号,例如:first-0
1、一个topic分为多个partition
2、一个partion分为多个seagment
3、.log日志文件
4、.index 偏移索引文件
4、 .timeindex事件索引文件
其他文件
说明:index和log文件时以当前segment的第一条信息的offset命名
2、思考:Topic 数据到底存储在什么位置?
存在data文件夹下,这里我是在我的安装路径下
cat cat 00000000000000000000.log
乱码
需要使用工具查看index和log等信息
kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.index
3、index 文件和 log 文件详解
1、根据目标offset定位Segment文件
2、找到小于等于目标offset的最大offset对应的索引项
3、定位到log文件
4、向下遍历找到目标Record
注意:
1、index为稀疏索引,大约每往log文件写入4kb数据,会往index文件写入一条索引。
2、index文件中保存的offset相对offset,这样能确保offset的值所占空间不会过大,因此能将offset的值控制固定大小
参数 | 描述 |
---|---|
log.segment.bytes | kafka中log日志是分成一块块存储的,此配置是指log日志划分成分的大小,默认1G |
log.index.interval.bytes | 默认4kb,kafka里面每单写入了4KB大小的日志(.log),然后就往index文件里面记录一个索引,稀疏索引 |
4、 文件清理策略
Kafka中默认的日志保存事件为7天,可以通过调整如下参数修改保存时间
log.retention.hours,最低优先级小时,默认7天
log.retention.minutes,分钟
log.retention.ms,最高优先级毫秒
log.retention.check.interval.ms,负责设置检查周期,默认5分钟
那么日志一旦超过了设置时间,怎么处理呢?
Kafka中提供的日志清理策略有delete和compact两种
1)delete日志删除:将过期数据删除
log.cleanup.policy = delete所有数据启用删除策略
基于时间:默认打开。以segment中所有记录中的最大时间戳作为该文件时间戳
基于大小:默认关闭,超过设置所有日志总大小,删除最早的segment,log.retention.bytes,默认等
于-1,表示无穷大。
如果一个 segment 中有一部分数据过期,一部分没有过期,怎么处理?
2)compact日志压缩
compact日志压缩:对于相同key不同的valu值,值保留最后一个版本
log.cleanup.policy = compact 所 所以有数据启用压缩策略
压缩后的offset是不连续的,比如上图中没有6,当从这些offset消息消息时,将会拿到比这个offset大的offset对应消息,实际上会拿到offset为7的消息,从这个位置开始消费
这种策略只适合特殊场景,比如消息的key是用户ID,value是用户的资料,通过这种压缩策略,整个消息集里面保存了所有用户最新资料