Kafka的核心集群机制，重点保证了在复杂运行环境下，整个Kafka集群如何保证Partition内消息
的一致性。这就相当于一个军队，有了完整统一的编制。但是，在进行具体业务时，还是需要各个Broker进行分工，各自处理好自己的工作。
每个Broker如何高效的处理以及保存消息，也是Kafka高性能背后非常重要的设计。这一章节还是按照之前的方式，从可见的Log文件入手，来逐步梳理Kafka是如何进行高效消息流转的。Kafka的日志文件记录机制也是Kafka能够支撑高吞吐、高性能、高可扩展的核心所在。对于业界的影响也是非常巨大的。比如RocketMQ就直接借鉴了Kafka的日志文件记录机制。
*一、Kafka的Log*日志梳理 **
这一部分数据主要包含当前Broker节点的消息数据(在Kafka中称为Log日志)。这是一部分无状态的数据，也就是说每个Kafka的Broker节点都是以相同的逻辑运行。这种无状态的服务设计让Kafka集群能够比较容易的进行水平扩展。比如你需要用一个新的Broker服务来替换集群中一个旧的Broker服务，那么只需要将这部分无状态的数据从旧的Broker上转移到新的Broker上就可以了。
*1、Topic***下的消息是如何存储的？ **
在搭建Kafka服务时，我们在server.properties配置文件中通过log.dir属性指定了Kafka的日志存储目录。实际上，Kafka的所有消息就全都存储在这个目录下。
这些核心数据文件中，.log结尾的就是实际存储消息的日志文件。他的大小固定为1G(由参数
log.segment.bytes参数指定)，写满后就会新增一个新的文件。一个文件也成为一个segment文件名表示当前日志文件记录的第一条消息的偏移量。
.index和.timeindex是日志文件对应的索引文件。不过.index是以偏移量为索引来记录对应的.log日志文件中的消息偏移量。而.timeindex则是以时间戳为索引。
这些文件都是二进制的文件，无法使用文本工具直接查看。但是，Kafka提供了工具可以用来查看这些日志文件的内容。
这些数据文件的记录方式，就是我们去理解Kafka本地存储的主线。对这里面的各个属性理解得越详细，也就表示对Kafka的消息日志处理机制理解得越详细。
*1 log***文件追加记录所有消息 **
首先：在每个文件内部，Kafka都会以追加的方式写入新的消息日志。position就是消息记录的起点，size就是消息序列化后的长度。Kafka中的消息日志，只允许追加，不支持删除和修改。所以，只有文件名最大的一个log文件是当前写入消息的日志文件，其他文件都是不可修改的历史日志。
然后：每个Log文件都保持固定的大小。如果当前文件记录不下了，就会重新创建一个log文件，并以这个log文件写入的第一条消息的偏移量命名。这种设计其实是为了更方便进行文件映射，加快读消息的效率。
*2 index和timeindex加速读取log***消息日志。 **
详细看下这几个文件的内容，就可以总结出Kafka记录消息日志的整体方式：
首先：index和timeindex都是以相对偏移量的方式建立log消息日志的数据索引。比如说 0000.index和0550.index中记录的索引数字，都是从0开始的。表示相对日志文件起点的消息偏移量。而绝对的消息偏移量可以通过日志文件名 + 相对偏移量得到。
然后：这两个索引并不是对每一条消息都建立索引。而是Broker每写入40KB的数据，就建立一条index索引。由参数log.index.interval.bytes定制。
index文件的作用类似于数据结构中的跳表，他的作用是用来加速查询log文件的效率。而timeindex文件的作用则是用来进行一些跟时间相关的消息处理。比如文件清理。
这两个索引文件也是Kafka的消费者能够指定从某一个offset或者某一个时间点读取消息的原因。
版权归原作者 will.tsang 所有， 如有侵权，请联系我们删除。