kafka存储结构以及Log清理机制.docxVIP

kafka存储结构以及Log清理机制 泽睿 2021-07-26 本文次要聚焦 kafka 的日志存储以及日志清理相关。 日志存储结构 首先我们来看一张 kafak 的存储结构图。 如上图所示、kafka 中消息是以主题 topic 为基本单位进行归类的，这里的 topic 是规律上的概念，实际上在磁盘存储是依据分区存储的，每个主题可以分为多个分区、分区的数量可以在主题创建的时候进行指定。例如下面 kafka 命令创建了一个 topic 为 test 的主题、该主题下有 4 个分区、每个分区有两个副本保证高可用。 ./bin/kafka-topics.sh --create --zookeeper :2181 --replication-factor 2 --partitions 4 --topic test 复制代码 分区的修改除了在创建的时候指定。还可以动态的修改。如下将 kafka 的 test 主题分区数修改为 12 个 ./kafka-topics.sh --alter --zookeeper :2181 --topic test --partitions 12 复制代码 分区内每条消息都会被安排一个独一的消息 id,也就是我们通常所说的 offset, ?因而 kafak 只能保证每一个分区内部有序性,不能保证全局有序性。 假如分区设置的合理，那么全部的消息都可以均匀的分布到不同的分区中去，这样可以实现水平扩展。不考虑多副本的情况下，一个分区对应一个 log 日志、如上图所示。为了防止 log 日志过大，kafka 又引入了日志分段(LogSegment)的概念，将 log 切分为多个 LogSegement，相当于一个巨型文件被平均安排为相对较小的文件，这样也便于消息的维护和清理。现实上，Log 和 LogSegement 也不是纯粹物理意义上的概念，Log 在物理上只是以文件夹的方式存储，而每个 LogSegement 对应于磁盘上的一个日志文件和两个索引文件，以及可能的其他文件(比如以.txindex为后缀的事务索引文件)。 kafak 中的 Log 对应了一个命名为- 的文件夹。举个例子、假如有一个 test 主题，此主题下游 3 个分区，那么在实际物理上的存储就是 test-0,test-1,test-2 这三个文件夹。 向 Log 中写入消息是挨次写入的。只要最终一个 LogSegement 才能执行写入操作，在此之前的全部 LogSegement 都不能执行写入操作。为了便利描述，我们将最终一个 LogSegement 成为ActiveSegement，即表示当前活跃的日志分段。随着消息的不断写入，当 ActiveSegement 满足肯定的条件时，就需要创建新的 activeSegement，之后在追加的消息写入新的 activeSegement。 为了便于消息的检索，每个 LogSegement 中的日志文件(以.log 为文件后缀)都有对应的两个文件索引：偏移量索引文件(以.index 为文件后缀)和时间戳索引文件(以.timeindex为文件后缀)。每个 LogSegement 都有一个“基准偏移量” baseOffset，用来标识当前 LogSegement 中第一条消息的 offset。偏移量是一个 64 位的长整形。日志文件和两个索引文件都是依据基准偏移量（baseOffset）命名的，名称固定为 20 位数字，没有达到的位数则用 0 填充。比如第一个 LogSegment 的基准偏移量为 0，对应的日志文件为 00000000000000000000.log 示例中第 2 个 LogSegment 对应的基准位移是 256，也说明白该 LogSegment 中的第一条消息的偏移量为 256，同时可以反映出第一个 LogSegment 中共有 256 条消息（偏移量从 0 至 254 的消息）。 留意每个 LogSegment 中不只包含“.log”“.index”“.timeindex”这 3 种文件，还可能包含“.deleted”“.cleaned”“.swap”等临时文件，以及可能的“.snapshot”“.txnindex”“leader-epoch-checkpoint”等文件。 日志清理机制 由于 kafak 是把消息存储 在磁盘上，为了把握消息的不断添加我们就必需对消息做肯定的清理和压缩。kakfa 中的每一个分区副本都对应的一个 log 日志文件。而 Log 又分为多个 LogSegement 日志分段。这样也便于日志清理。kafka 内部供应了两种日志清理策略。 日志删除 依据肯定的保留策略直接删除不符合条件的日志分段。 基于时间 我们可以通过 broke