6.1.5 日志管理

Love The Way You Lie 2023-01-15 08:08 15阅读 0赞

> Kafka的日志管理负责日志的创建、检索、清理，但和日志相关的读写操作则交给日志实例去处理。每个逻辑意义的分区都对应一个物理意义的日志实例，日志管理类用logs管理了分区对应的日志实例。相关代码如下：  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]

Kafka消息代理节点的数据目录配置项(log.di.rs)可以设置多个目录。如图6-31(左)所示，代理节点的log.di.rs=/t1’1p/kafka\_logs1,/tl’lp/kafka\_logs2，表示它有两个数据目录。代理节点负责的所有分区分别分布在这两个目录巾，第一个数据目录下有［test0－日，test0-1,test1-2］，第二个数据目录下有［test0-2,test1-0,test1-1］。右图中，第一个数据目录下除了所有分区的日志目录，还有一个代表所有分区的全局检查点文件。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]

注意：为了区分log.dirS和logDir，前者叫作数据目录，后者叫作日志目录。一个数据目录下可以有多个分区，而一个分区只对应一个日志目录。注意，同一个分区只会在其中的一个数据目录，不会同时存在多个数据目录中。

Kafka服务启动时会创建一个日志管理类，并且会执行loadLogs()方法加载所有的日志，而每个日志也会调用loadSegl’lents()方法加载所有的分段。由于这个过程比较缓慢，因此日志管理类用线程池的方式，为每个日志的加载都创建一个单独的线程。相关代码如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]

日志管理器采用线程池提交任务，表示不同的任务可以同时运行，但任务本身是阻塞式的。每个日志只有都加载完分段后，才会加入到logs映射表中。如果没有加载完所有日志，loadLogs()方法就不能返回。日志管理器加载完毕后，Kafka服务(KafkaServer)会调用日志管理器的startup()方法，启动下面4个后台的管理线程。前两个可以看作日志刷新策略，后两个可以看作日志清理策略。相关代码如下：  
![在这里插入图片描述][20210421220705688.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]

下面按照服务端配置文件的顺序，依次分析检查点文件、日志刷新、日志清理、日志压缩。

1.  检查点文件  
    消息代理节点用多个数据目录存储所有的分区日志，每个数据目录都有一个全局的检查点文件，检查点文件会存储这个数据目录下所有日志的检查点信息。比如前面的示例中，／tmp/kafka-logs1会存储［test0－日，test0-1,test1-2］的检查点。检查点表示日志已经刷新到磁盘的位置，它在分布式存储系统中，主要用于故障的恢复。下面的代码列举了日志管理器中与检查点有关的方法：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]

注意：涉及检查点文件的日志管理操作只针对特定的数据目录，而日志管理类的logs映射表并没有区分数据目录。logsByD"ir()方法会对数据目录进行分组，确保同一个数据目录下的所有日志会分在同一个组。

如图6-32所示，检查点文件在日志管理类和日志实例的运行过程中起了重要作用，具体步骤如下。

(1)Kafka启动时创建日志管理类，读取检查点文件，并把每个分区对应的检查点(checkPo"int)
    作为日志的恢复点(recoveryPo"int)，最后创建分区对应的日志实例。
    (2)消息追加到分区对应的日志，在刷新日志时，将最新的偏移盘作为日志的检查点。
    (3)日志管理器会启动一个定时任务：i卖取所有日志的检查点，并写入全局的检查点文件。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]

1.  刷新日志  
    日志管理器启动时全定时调度flushD"irtylogs()方法，定期将页面缓存中的数据真正刷写到磁盘的文件中。日志在未刷写之前，数据保存在操作系统的页面缓存中，这比直接将数据写到磁盘文件快得多。但这种做法同时也意味着：如果数据还没来得及刷写到磁盘上，消息代理节点崩溃了，就会导致数据丢失(当然，如果有副本，多个节点同时崩溃的情况比较少见，降低了数据丢失的风险)。有两种策略可以将日志刷写到磁盘上：时间策略和大小策略。对于时间而言，用调度器来做最适合，所以日志管理器启动的时候会启动一个定时器，每隔log.flush.1.nterval.l’ls的时间执行一次刷写动作。相关代码如下：

![在这里插入图片描述][20210421220808614.png]

对于大小策略，仅在有新消息产生的时候才可能有机会调用日志的flush()方法。相关代码如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 7]

消息追加到日志中，有下面两种场景会发生刷新日志的动作。

*  新创建一个日志分段，立即刷新旧的日志分段。
 *  日志中未刷新的消息、数量超过log.flush.1.nterval.f!lessages配置项的值。

刷新日志方法的参数是日志的最新偏移量(logEndOffset)，它要和日志中现有的检查点位置(recoveryPo"i.nt)比较，只有最新偏移量比检查点位置大，才需要刷新。由于一个日志有多个日志分段，所以刷新日志时，会刷新从检查点位置到最新偏移量的所有日志分段，最后更新检查点位置。如  
图6-33(左)所示，消息集追加到一个日志分段中，通过收集的消息数量或者固定的间隔时间，周期性地更新检查点。如右图所示，新创建一个日志分段，会立即刷写旧的日志分段，井更新检查点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 8]

1.  清理日志  
    为了控制日志中所有日志分段的总大小不超过阔值(log.retent"i.on.bytes配置项)，日志管理器会定时清理旧的日志分段。清理日志分段时，从最旧的日志分段开始清理。因为日志分段中消息的偏移量是递增的，所以清理旧的日志分段，表示清理旧的消息。日志清理有下面两种策略。

*  删除(delete)。超过日志的阁值，直接物理删除整个日志分段。
 *  压缩Ccol’lpact)。不直接删除日志分段，而是采用合并压缩的方式。

日志清理的相关代码如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]

删除日志的实现思路是：将当前最新的日志大小减去下一个即将删除的日志分段大小，如果结果超过阔值，则允许删除下一个日志分段；如果小于阔值，则不会删除下一个日志分段。如图6-34所示，假设有4个日志分段，大小分别是［IGB,!GB,!GB,500MB］，并且日志的大小阔值为lGB。最终清理操作会删除前面两个日志分段，剩余后两个日志分段。虽然后两个日志分段加起来为1.5GB，超过阔值的lGB，但并不会删除第三个日志分段，因为如果把它删除，日志分段就只剩下500MB了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 10]

日志的deleteOldSeefMents()方法接收一个pred"i.cate()高阶函数。高阶函数的参数是日志分段，返回值表示该日志分段是否需要被删除。日志的所有日志分段都会调用该方法，但只有predi.cate()方法返回值等于true的日志分段才会被删除。删除日志分段是一个异步的操作，在执行异步删除之前，要将日志分段从映射表中删除，并将日志分段的文件名(数据文件和索引文件)添加上.deleted后辍，最后才调度异步删除日志分段的任务。相关代码如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 11]

日志实例中涉及日志分段的修改，比如追加消息(append())、删除(delete())、滚动创建(roll())、刷新(flush())、截断(truncateTo())、替换(replaceSegl’lents())、关闭(close())、加载(loadSegl’lents())等操作，都会用一个对象锁保证同步。有些方法虽然没有直接加锁，但如果调用的是带有参数的logSegl’lents(fr01’1,tO)方法，也会进行加锁。

注意：追加消息有加锁，但读取消息不需要加锁。否则消息在不断追加到分区的过程中，如果存在写锁，客户端读取时获取不到锁，就无法读取同一个分区的消息。

清理日志有两种策略：一种是根据时间或大小策略直接删除日志分段，另一种是针对每个键进行日志压缩。日志清理的策略可以设置为全局的，或者针对主题进行单独设置，这完全取决于你的业务需求。如果消息没有键，就只能采用第一种清理策略。日志压缩也属于日志管理的一部分，但这个内容比较复杂，下面单独将日志压缩作为一节来分析。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]: /images/20221022/44355dc677b84d0a8ed83dee3e0d5e96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]: /images/20221022/b94af14e9a4144318d22b974067c0b97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 2]: /images/20221022/2b8e8ef88d7c4ba2b0167092a5c35ca7.png
[20210421220705688.png]: /images/20221022/0486f90b0ff548baabf3f446cb37b93c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 3]: /images/20221022/ea570773bc4143f6af51ee8413aa227f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 4]: /images/20221022/8f4cafb7cd3b4a0c9adf93474d0c6f89.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 5]: /images/20221022/8aacd20a257e47b1b133e54712225939.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 6]: /images/20221022/49a6e9516a174937b54ff533aa87c50e.png
[20210421220808614.png]: /images/20221022/a44bdb3fd2d1465082c536e6a6c40dc4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 7]: /images/20221022/e5785b0fb1f14ad3b9be78db4ac4c81d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 8]: /images/20221022/7df6f24a47e04c92bb51305148ae57ee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 9]: /images/20221022/cfccd538cbb74e0b9f77dbca9a03b73e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 10]: /images/20221022/0b6481122e504e739a502f6aaa90baf6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 11]: /images/20221022/9b4fde81b4b346aaa85a6ca864649636.png