Kafka 主题记录保留政策不明确

Question

从 Kafka Docs 我开始感兴趣并尝试了以下 2 种保留类型一起

log.retention.bytes：

删除前日志的最大大小 类型：long默认：-1有效值：重要性：high更新模式：集群范围

log.retention.ms

在删除之前保留日志文件的毫秒数（在 毫秒），如果未设置，则使用 log.retention.minutes 中的值。 如果设置为 -1，则不应用时间限制。类型：long 默认值：nullValid 值：重要性：高更新模式：集群范围

作为

1. log.retention.bytes = 1Gb
2. log.retention.ms = 7 天

---

问题情况

我目前在我的主题上有属于两个不同日志文件的所有消息，这两个文件都是

假设 log.1 文件有 400 MB 的消息，其中最旧的消息 > 7 天。

在上面

log.2 文件有 500 MB，最新消息 > 7 天。

我知道 kafka 会清理属于 log.2 文件的所有记录，换句话说，从主题中删除此日志。

log.1 中超过 7 天的记录会怎样？

Answer 1

有两个属性定义了 Kafka 中的消息保留 - log.retention.bytes 和 log.retention.ms（每个主题每个分区级别）。数据删除策略适用于FIFO basic，即先推送到主题的消息将首先被删除。

你说得对，默认值是：

log.retention.bytes = 1Gb (per topic per partition)
log.retention.ms = 7 days (per topic)

这意味着无论首先违反哪个限制，都会导致Kafka中的数据清除。

例如，假设您的主题中的消息大小占用 500 MB 空间（小于 log.retention.bytes）但超过 7 天（即大于默认的 log.retention.ms）。在这种情况下，超过 7 天的数据将被清除（基于FIFO）。

同样，如果对于给定主题，消息占用的空间超过log.retention.bytes，但不早于log.retention.ms，在这种情况下，数据也会被清除（基于FIFO）。

使数据过期的概念称为Cleanup & 主题上的消息在使用/过期后不会立即删除。在后台发生的情况是，一旦违反任何一个限制，消息就会被标记为已删除。 Kafka 中有 3 个日志清理策略 - DELETE（默认）、COMPACT、DELETE AND COMPACT。 Kafka Log Cleaner 进行日志压缩，后台压缩线程池。

要为主题启用压缩，请使用主题配置log.cleanup.policy=compact。要设置延迟以在写入后开始压缩记录，请使用主题配置 log.cleaner.min.compaction.lag.ms。 在此期间之后才会压缩记录。该设置让消费者有时间获取每条记录。这可能是旧邮件没有立即被删除的原因。您可以检查压缩延迟的属性值。

以下链接可能会有所帮助：

• https://medium.com/@sunny_81705/kafka-log-retention-and-cleanup-policies-c8d9cb7e09f8
• http://cloudurable.com/blog/kafka-architecture-log-compaction/index.html
• https://www.learningjournal.guru/courses/kafka/kafka-foundation-training/broker-configurations/

Answer 2

我在这里转述一本书的相关部分，Kafka - Definitive Guide。它很可能会消除您的疑虑。

log.retention.bytes ：这表示每个分区保留的消息的总字节数。所以，如果我们有一个有 8 个分区的主题，并且log.retention.bytes 设置为 1GB，那么为该主题保留的数据量最多为 8GB。这意味着如果我们选择增加某个主题的分区数量，保留的数据总量也会增加。

log.retention.ms ：Kafka 保留消息多长时间的最常见配置是按时间。默认值在配置文件中使用log.retention.hours 参数指定，设置为168 小时，即一周。但是，还允许使用其他两个参数，log.retention.minutes 和 log.retention.ms。所有这三个都指定了相同的配置——可以删除消息的时间量——但推荐使用的参数是log.retention.ms，因为如果指定了多个，较小的单元大小将优先。这将确保为log.retention.ms 设置的值始终是使用的值。如果指定了多个，则较小的单元大小将优先。

按时间和上次修改时间保留：按时间保留是通过检查磁盘上每个日志段文件的上次修改时间 (mtime) 来执行的。在正常的集群操作下，这是日志段关闭的时间，代表文件中最后一条消息的时间戳。但是，当使用管理工具在 broker 之间移动分区时，这个时间是不准确的，会导致这些分区的保留过多。

按大小和时间配置保留：如果您已为 log.retention.bytes 和 log.retention.ms 指定了一个值（或按时间保留的另一个参数），则当任一条件为遇见了。例如，如果 log.retention.ms 设置为 86400000（1 天），log.retention.bytes 设置为 1000000000（1 GB），如果消息总量超过一天的过程大于 1 GB。反之，如果卷小于 1 GB，即使分区总大小小于 1 GB，消息也可以在 1 天后删除。