从 Kafka Docs 我开始感兴趣并尝试了以下两种保留类型
删除前日志的最大大小类型：long默认：-1有效值：重要性：高更新模式：集群范围
删除之前保留日志文件的毫秒数（以毫秒为单位），如果未设置，则使用 log.retention.minutes 中的值。如果设置为 -1，则不应用时间限制。类型：long 默认值：null 有效值：重要性：high 更新模式：集群范围
作为
我目前在我的主题上有属于两个不同日志文件的所有消息，这两个文件都 < 1GB
假设 log.1 文件有 400 MB 的消息，其中最旧的消息 > 7 天。
这是在顶部
log.2 文件有 500 MB，最新消息 > 7 天。
我知道 kafka 会清理属于 log.2 文件的所有记录，换句话说，从主题中删除此日志。
log.1 中超过 7 天的记录会发生什么情况？
有两个属性定义了 Kafka 中的消息保留 -log.retention.bytes和log.retention.ms（每个主题每个分区级别）。数据删除的策略是FIFO基本的，即先推送到某个主题的消息将首先被删除。
您正确地说，相同的默认值是：
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＆amp ;主题上的消息在消费/过期后不会立即删除。在后台发生的情况是，一旦违反任何一个限制，消息就会被标记为已删除。Kafka 中有 3 种日志清理策略—— DELETE（默认）COMPACT、、、DELETE AND COMPACT。Kafka Log Cleaner 进行日志压缩，后台压缩线程池。
要打开主题的压缩，请使用主题配置log.cleanup.policy=compact。要设置延迟以在写入记录后开始压缩记录，请使用 topic config log.cleaner.min.compaction.lag.ms。直到这段时间之后，记录才会被压缩。该设置使消费者有时间获取每条记录。这可能是旧邮件没有立即被删除的原因。您可以检查压缩延迟的属性值。
以下链接可能会有所帮助：
我在这里转述一本书的相关部分，Kafka - Definitive Guide。它很可能会清除您的疑问。
log.retention.bytes：这表示每个分区保留的消息的总字节数。因此，如果我们有一个有 8 个分区的主题，并且log.retention.bytes设置为 1GB，那么为该主题保留的数据量最多为 8GB。这意味着如果我们选择增加一个主题的分区数量，保留的数据总量也会增加。
log.retention.ms：Kafka 保留消息多长时间的最常见配置是按时间。默认在配置文件中使用log.retention.hours参数指定，设置为168小时，即1周。但是，还允许使用其他两个参数，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 天后被删除。