kafka入门之broker--日志存储设计

kafaka并不是直接将原省消息写入日志文件的，相反，它会将消息和一些必要的元数据信息大宝在一起封装成一个record写入日志。其实就是我们之前介绍的batch

具体对每个日志而言，kafka又将其进一步细分成日志段文件以及日志段索引文件，每个分区日志都是由若干日志段文件+索引文件构成的。

 

 

创建topic时，kafka为该topic的每个分区在文件系统中创建了一个对应的子目录，名字就是<topic>-<分区号>。每个日志子目录的文件构成都是如图所示的结构，即若干组日志段+索引文件。

1。日志段文件，即后缀名时.log的文件保存着真是的Kafka记录，kafla使用该文件第一条记录对应的offset来命名此.log文件。

kafka每个日志段文件是有上限大小的，由broker端参数log.segment.bytes控制，默认就是1GB大小。，因此当日志段文件填满记录后，kafka会自动创建一组新的日志段文件和索引文件，这个过程被称为日志切分。当前日志段非常特殊，它不受任何Kafka后台任务的影星，比如定期日志清楚任务和定期日志compaction任务。

2.索引文件

.index文件和.timeindex文件他们都是索引文件，分别被称为位移索引文件和时间戳索引文件，前者可以帮助broker更快地定位记录所在的物理文件位置，而后者则是根据给定的时间戳查询对应的位移信息。

它们都属于稀疏索引文件，每个索引文件都由若干索引项组成。kafka不会为每条消息记录都保存对应的索引项，而是特写入若干记录后才增加一个索引项，broker端参数log.index,interval.bytes设置了这个间隔到底是多大，默认值是4kb，即kafka分区至少写入了4KB数据后才会在索引文件中增加一个索引项，故本质上它们是稀疏的。

升序排列，有了这种升序规律，kafka可以利用二分查找算法来搜索目标索引项，从而降低整体时间复杂度到o(lgN)。若没有索引文件，kafka搜寻记录的方式只能是从每个日志段文件的体育部孙旭扫面，因此这种方案的时间复杂度是o（N）显然，引入索引文件可以极大的减少查找时间，减少broker端的cpu开销

当日志进行切分时，索引文件也需要进行切分，broker端参数log.index.size.max.bytes设置了索引文件的最大文件大小，默认是10MB。和日志段文件不同，索引文件的空间默认都是预先分配好的，而当对索引文件切分时，kafka会把该文件大小'裁剪'到真实数据大小：

格式：

1.位移索引文件：

每个索引项固定地占用8字节的物理空间，同时kafka强制要求索引文件必须是索引项大小的整数倍，即8的整数倍，因此假设用户设300会是296

索引文件文件名中的位移就是改索引文件的起始位移。

2.时间戳索引文件： 

每个索引项固定占用12字节的物理空间，同时kafka强制要求索引文件必须是索引项大小的整数倍，即12的整数倍，设100会是96

时间戳索引项保存的是时间戳与唯一的映射关系，给定时间戳后根据此索引文件只能找到不大于该时间戳的最大位移，然后kafka还需要拿着返回的位移再去位移索引文件中定位真实的物理文件位置。

日志留存：

定期清除日志，即删除符合策略的日志段文件和两个索引文件：

基于时间：默认7天，.log.retention.hours|minutes|ms用于配置清除日志的时间间隔，其中ms的优先级最高，minutes次之，hours优先级最低，计算当前时间戳与日志段首条消息的时间戳之差作为衡量日志段是否留存的依据，如果第一条消息没有时间戳，kafka才会使用最近修改时间的属性

基于大小，默认-1，表示kafka不会对log进行大小方面的限制

日志清除是一个异步过程，kafka broker启动后会创建单独的线程处理日志清除事宜。

日志compaction：

如果·使用log compaction，kafka消息必须要设置key，无key消息是无法为其进行压实操作的。

kafka有个组件叫cleanner，它就是负责执行compaction操作的。cleaner负责从log中移除已废弃的消息，如果一条消息的key是k，位移是o，只要日志中存在另外一条消息，key也是k，但位移是o‘，且o<o‘，即认为前面那条消息已经废弃。

log compaction是topic级别的设置。

在内部kafka会构造一个哈希表来保存key与最新位移的映射关系：

_consumer_offset内部topic就是采用log compaction留存策略的。

相关参数：

log.cleanup.policy:

log.cleaner.enable:

log.cleanner.min.compaction.lang.ms

 

转载于:https://www.cnblogs.com/lccsblog/p/11219681.html