Kafka日志清理策略详解：从LogSegment到delete与compact的配置实践

1. 为什么说日志清理是 Kafka 集群的"隐形命门"

先说句可能颠覆很多人认知的话：在 Kafka 的日常运维里，真正让集群出大事的，往往不是消息堆积、不是消费者宕机，而是日志清理策略配置不当。我见过凌晨三点被拉起来处理磁盘告警的同行，也见过因为日志段文件无法删除导致整个分区不可写的惨痛案例，最后定位下来，十有八九是清理策略没吃透。

Kafka 之所以叫"分布式消息队列"，很多人只记住了"分布式""消息队列"，却忽略了它底层其实是一个基于日志文件的分布式存储系统。每一个主题（Topic）的分区（Partition），在物理存储上都对应着一组日志段（LogSegment）文件。这些文件不断追加写入，如果不加节制，磁盘再大也有被撑爆的一天。这时就需要"日志清理策略"登场——它本质上就是 Kafka 自带的磁盘空间管理机制，决定了一个日志文件什么时候可以被删除、什么时候需要被压缩、哪些数据可以淘汰、哪些数据必须保留。

我接触过的很多入门开发者，对这块的认知停留在"默认保留7天日志"这种粗浅层面，真到生产环境一压测，问题就全暴露出来了。举个例子：你在 server.properties 里配置了log.retention.hours=168，以为日志7天后会被清掉，结果一周后一看磁盘占用率还是居高不下。为什么？因为你对"日志清理"的触发机制、文件切分逻辑、删除粒度一无所知。

这篇文章我不想抄官方文档，而是基于我自己的运维和调优经验，把 Kafka 日志清理策略从头到尾拆开揉碎，讲清楚三件事：日志文件到底怎么组织的、清理策略的底层原理是什么、生产环境里应该怎么配才不出事。不管你是刚入门的大数据开发，还是已经在生产环境摸爬滚打的运维，这篇文章都值得仔细读完。

对了，如果你正在准备 Kafka 相关的面试，这一块也是高频考点。很多面试官喜欢问"Kafka 的日志清理策略有哪些？它们各自的原理是什么？"——相信我，看完这文章，你不仅能答上来，还能举出实际案例，这就和那些只会背八股文的候选人拉开了差距。

2. 日志存储模型：不搞懂 LogSegment 和索引文件，清理策略就是空中楼阁

2.1 从"一个分区一个目录"说起

Kafka 的日志存储结构其实非常规整。在 broker 的日志目录下（默认是/tmp/kafka-logs），每一个分区都对应一个形如<topic>-<partition>的目录，比如orders-0、orders-1。这个目录里装着的就是该分区的全部消息数据。

但是 Kafka 并不会把整个分区的数据塞进一个巨大的文件里，而是按大小和时间切成一个一个的日志段文件（LogSegment）。每个日志段默认是 1GB（由log.segment.bytes控制），或者 7 天（由log.roll.hours控制）切换一次，哪个条件先满足就切哪个。

这种设计背后的逻辑很容易理解：如果一个分区只有一个文件，随着数据增长，文件会达到几十上百 GB，无论是清理旧数据还是查找消息，代价都太大。切成若干个小段以后，删除旧数据就变成了"直接删除整个文件"的操作，效率极高。

每个日志段目录下，实际包含两类核心文件：

• .log文件：真正存储消息数据的文件，按顺序写入，文件名是当前段的第一条消息的偏移量（offset）。
• .index文件和.timeindex文件：分别是偏移量索引和时间戳索引，用于快速定位消息位置。

这里尤其要注意：Kafka 的日志清理，清理的最小单元其实是日志段文件，而不是单条消息。这个认知非常重要。我见过有同学问"为什么我的分区里还有昨天的消息？明明 retention 设置的是 3 天"——原因就在于这些消息所在的日志段文件还没到删除条件，因为清理的判断是基于整个文件的时间戳和大小，不是逐条消息判断。

2.2 活跃段（Active Segment）的特殊地位：为什么它永远删不掉

在每个分区目录下，永远有一个正在写入的日志段，我们称之为活跃段（active segment）。活跃段的文件名后缀是最新偏移量，或者我们说它是"当前正在追加写入的那个文件"。

这里有一个非常容易踩坑的点：活跃段是不参与清理的，无论你怎么设置 retention，活跃段都不会被删除。为什么？因为 Kafka 还在往里面写数据，你把它删了，后续消息往哪写？

这导致了一个非常经典的现象：假设你的log.segment.bytes=1073741824（默认1GB），你的业务流量很小，一天只写入 10MB 数据，那么这个活跃段可能要 100 天才能写满。此时即便你设置了log.retention.hours=72（保留3天），实际上旧数据在磁盘上会留存远远超过 3 天——因为消息还在活跃段里，而活跃段不滚动、不删除。

用大白话说就是：日志清理策略的生效前提是"日志段已经不属于活跃段"。要让旧数据真正被清掉，日志段必须被"滚动"（roll）成非活跃段，然后等待清理线程来处理。

所以生产环境里，如果你的业务消息量很小，强烈建议调小log.segment.bytes或log.roll.hours。比如设置log.segment.bytes=268435456（256MB）或log.roll.hours=24，保证日志段一天甚至更短时间就滚动一次，这样清理策略才能真正发挥作用。

2.3 索引文件在清理过程中的角色

有人可能会问：清理策略和索引文件有什么关系？

关系很大。在讲清理策略之前，必须先铺垫一下索引文件的机制，因为后面说的"基于时间的删除"和"基于偏移量的查找"都依赖索引来定位。

以.index文件为例，它采用的是稀疏索引方式，也就是说并不是每条消息都有索引条目，而是每隔一定字节数（由log.index.interval.bytes控制，默认 4096 字节）记录一条索引。索引项保存的是相对偏移量和物理位置之间的关系。

.timeindex文件则是时间戳到偏移量的映射。当你设置了按时间删除日志时，Kafka 的清理线程需要找到"哪个日志段的最后修改时间（或最大时间戳）超过了保留阈值"，从而决定是否删除整个文件。这个过程中，时间戳索引可以帮助快速定位每个日志段消息的时间范围。

在实际排查问题时，如果发现时间戳索引损坏，可能会导致时间戳查询异常，甚至影响基于时间的清理策略的判断。虽然这种情况比较少见，但一旦出现，清理就会"卡住"，表现为日志一直不删。如果你在日志中看到类似java.io.IOException: Map failed或索引相关的报错，优先考虑删除损坏的索引文件让 Kafka 重建，这是个非常实用的运维技巧。

3. 清理策略一：delete——大多数人的默认选择，你真的用对了吗

3.1 基于时间的删除：不是"整点删除"，而是"惰性检查"

当log.cleanup.policy设置为delete时，Kafka 的清理方式就是删除整个日志段文件。删除的判断依据主要有三个维度：时间、大小、起始偏移量。我们逐个说。

基于时间：默认情况下，broker 的log.retention.hours=168（7天）。Kafka 的日志清理线程（LogCleaner 或 LogManager 的后台任务）会周期性检查，大概每 5 分钟跑一次（由log.retention.check.interval.ms控制，默认 300000 毫秒）。

检查的逻辑是：遍历所有非活跃日志段，读取每个日志段中消息的最大时间戳（或者日志段的最后修改时间），如果这个时间距离当前时间的差值超过了 retention 阈值，就标记这个日志段为待删除。

这个机制有个重要特征：它是惰性检查，不是精确到秒的准点清理。比如一条消息在 10:00:00 落盘，retention 是 1 小时，它并不会在 11:00:00 被立刻删除，而是会在 11:00 到 11:05 之间的某次周期性检查中被发现并标记，然后在下一个删除周期真正执行删除。对于绝大多数场景来说，这种分钟级的延迟完全可以接受，但你要是做对实时性要求极高的合规删除，就要有心理准备。

3.2 基于大小的删除：最容易让人忽视的隐藏 Boss

很多人在配置 Kafka 时只设置了时间 retention，完全忽略了大小 retention。生产环境中最典型的故障场景是这样的：

某业务 Topic 的 daily 写入量是 500GB，你设置了log.retention.hours=72。按理说 3 天的数据也就是 1.5TB，磁盘 5TB 应该够。但因为某些原因，某天写入量突增到了 2TB，结果一下就把磁盘撑爆了。

如果你同时设置了log.retention.bytes，情况就完全不一样了。log.retention.bytes是分区维度的配置，意思是这个分区下所有日志段文件的总大小不能超过这个值。清理线程在检查时发现当前分区总大小超出阈值，就会从最老的日志段开始删，直到总大小降到阈值以下。

这里有个很多人没注意的细节：log.retention.bytes的默认值是 -1，即不限制。所以如果你只配了时间 retention，那么在极端流量突刺下，磁盘是没有任何兜底保护的。我个人强烈建议在生产环境里，对核心 Topic 同时设置时间和大小两个维度的 retention，双保险。

另外还要提一个 topic 级别的配置和 broker 级别的区别。broker 级别的log.retention.bytes和log.retention.hours是全局默认值，而创建 Topic 时可以通过--config retention.ms=xxx和--config retention.bytes=xxx覆盖。改配置的优先级是 Topic 级别 > broker 级别，这个优先级关系经常被搞混，面试也爱考。

3.3 基于起始偏移量的删除：配合消费者进度理解 file.delete.delay.ms

Kafka 删除日志段时还遵循一个原则：不会删除当前消费者还在消费的日志段。更准确地说，Kafka 会记录所有消费者组在当前分区上的消费位置（即 current offset），如果某个日志段的最大偏移量还大于某个消费者组当前消费的偏移量，那么这个日志段不会被删除，即使它已经超过了时间 retention。

这个设计是出于安全考虑，但也会带来一个问题：如果某个消费者组挂掉之后再也没有起来过，它的 offset 一直停留在很老的位置，那么这个位置上所有的日志段都无法删除，磁盘占用会一直居高不下。这就是很多团队遇到的"日志删不掉"的另一个原因。

排查思路非常简单：用kafka-consumer-groups.sh --describe --group <group_id>查看这个消费者组的CURRENT-OFFSET和LOG-END-OFFSET，如果发现CURRENT-OFFSET远远小于LOG-END-OFFSET，说明这个消费者严重滞后甚至已经"死掉"了。如果确认该业务已经不再需要，直接删除对应的消费者组，或者重置 offset，日志段很快就会被清理掉。

关于删除动作本身，还有一个参数叫log.segment.delete.delay.ms（默认 60000ms，即 1 分钟）。也就是说，即使日志段已经被标记为删除，也不是立即物理删除，而是要延迟 1 分钟才会真正执行删除。这个延迟的目的是给消费者一个缓冲时间，避免正在消费的文件被突然删除导致异常。

3.4 delete 策略的完整工作流总结

来梳理一下 delete 策略的完整执行链路，方便你理解整个流程：

1. 消息不断写入活跃段，当活跃段达到log.segment.bytes大小或log.roll.hours时间时，滚动生成新的活跃段，旧的变为非活跃段。
2. 日志清理线程周期性扫描所有非活跃日志段（默认每 5 分钟一次）。
3. 对每个日志段，依次检查：是否超过时间 retention → 是否超过大小 retention → 是否被某个消费者组 pin 住。
4. 需要删除的日志段先被标记为delete状态，等待log.segment.delete.delay.ms延迟时间。
5. 延迟结束后，执行真正的文件删除操作，同时删除对应的.log、.index、.timeindex文件。

这个流程看起来简单，但每个环节都可能出问题。最常见的就是第 3 步里消费者组 pin 住日志段，我甚至见过一个测试环境里消费者程序没有配置enable.auto.commit=false也没手动提交 offset，导致消费者组 offset 一直为 0，所有日志段都无法删除，磁盘告警频繁触发。后来一查，就是一个已经没人维护的测试消费者在"作妖"。

4. 清理策略二：compact——从"删数据"到"合并数据"的思维转变

4.1 基于 Key 的日志压缩：到底是什么鬼

说完 delete，再来说另一种策略：compact。官方名称叫"日志压缩"（Log Compaction）。

很多初学者第一次听到 compact 都是一脸懵：这不是日志吗？还能压缩？又不是压缩包。

这里说的"压缩"并不是把文件缩小体积，而是针对相同 Key 的消息做去重合并。Kafka 的 compact 策略会保留每个 Key 的最新一条消息，删除掉同一个 Key 的所有旧消息。这样一来，日志中每个 Key 只有最新的一条记录，查找某个 Key 的最新状态时会非常高效。

打个比方：delete 策略就像你每天清理垃圾桶，垃圾满了就倒掉；而 compact 策略就像整理通讯录，同名的人只保留最新更新的那个，旧的联系方式全部删掉。

这种策略在什么场景下特别有用？最典型的就是用 Kafka 实现"事件溯源"（Event Sourcing）或"状态存储"。比如你有一个用户信息变更的 Topic，每次用户修改资料都发一条消息，Key 是用户 ID。在 delete 策略下，这个 Topic 里可能躺着几十条同一个用户的旧数据，你如果要恢复这个用户的最新状态，得从头消费所有消息然后逐条应用。但在 compact 策略下，日志里每个用户只保留最新一条修改记录，新消费者启动后可以快速恢复全量最新状态。

4.2 compact 的存储结构：Log Cleaner 和 Cleaner 线程池

compact 策略的核心执行者是 Kafka 的Log Cleaner。它不是单线程，而是一个线程池，由log.cleaner.threads配置控制，默认 1 个线程。如果你的 Kafka 集群里有很多 compact 类型的 Topic，建议适当调大这个值，比如 4 或 8。每个线程负责处理一个或多个日志段的压缩任务。

Log Cleaner 的工作过程稍微复杂一些，我分步骤说明：

1. 标记 dirty 区域：每个 compact Topic 的日志会划分为"clean 区域"和"dirty 区域"。clean 区域是已经完成压缩的部分，dirty 区域是待压缩的新写入数据。随着消息不断写入，dirty 区域不断扩张。
2. 构建 Key 映射表：Cleaner 在压缩某个日志段之前，会先构建一个"Key → 最新 Offset"的映射表。它从 dirty 区域中从后往前遍历消息，记录每个 Key 出现的最新偏移量。
3. 逐段复制保留消息：Cleaner 逐一处理日志段，把"当前偏移量等于该 Key 最新偏移量"的消息复制到保留区，其余消息丢弃。
4. 替换日志段：压缩完成后，用保留的消息生成新的日志段文件，替换掉旧的日志段，同时更新索引。

你可能会问：压缩过程中如果生产者还在不断写入怎么办？Kafka 的处理方式是：在压缩过程中，新写入的消息不会被阻塞，而是追加到新的活跃段中。压缩只针对被标记为 dirty 的旧日志段，不会触碰活跃段。这也是 Kafka 能做到"边写边压缩"的原因。

4.3 min.cleanable.dirty.ratio：压缩频率的"阈值开关"

compact 策略里有一个很重要的参数叫min.cleanable.dirty.ratio，默认是 0.5，意思是当 dirty 区域占整个日志的比例超过 50% 时，才会触发压缩。

这个参数的本质作用是控制压缩的频率和资源消耗。如果比例设置得太小（比如 0.1），那么日志很快就会被压缩，但压缩操作本身是 CPU 密集型的，频繁压缩会拖垮 broker 性能。如果设置得太大（比如 0.9），压缩很少发生，日志膨胀会很严重，磁盘占用高，且消费时会有大量冗余消息。

生产环境的经验值是：对于写入频繁、Key 重复度高的 Topic，可以设置小一点（0.2~0.3）；对于写入不频繁、Key 重复度低的 Topic，用默认 0.5 即可。这个参数在 Topic 级别可以用min.cleanable.dirty.ratio覆盖。

另一个值得一提的参数是delete.retention.ms（默认 86400000ms，即 1 天）。compact 策略下，如果某条消息带有删除标记（tombstone，即 value 为 null），Kafka 不会立刻删除它，而是会等到超过delete.retention.ms之后才真正删除。这是为了给消费者足够的时间处理删除事件。如果你的业务中有大量 tombstone 消息，要注意这个参数，否则带 null 的消息会一直堆积。

4.4 compact 和 delete 组合：cleanup.policy=compact,delete

很多人不知道，Kafka 的log.cleanup.policy其实支持两个值同时设置，写法是compact,delete。这意味着 Kafka 会同时执行两种清理策略：先按 delete 策略删除过期日志段，再对剩余日志段做 compact 压缩。

这种组合在真实生产环境中非常有用。举个例子：你有一个订单事件 Topic，希望每个订单 ID 只保留最新状态（用 compact），同时不想让日志无限膨胀（用 delete 兜底）。此时设置cleanup.policy=compact,delete，并配合retention.ms=604800000（7天），就既能保证 Key 级别的去重，又能保证磁盘空间不会无限增长。

但有件事必须注意：当 compact 和 delete 同时启用时，log.retention.ms和log.retention.bytes依然生效。如果 delete 触发得太早，可能会删除掉某些 Key 的最新消息，导致 compact 的"每个 Key 保留最新"的语义被破坏。所以组合模式下，retention 时间不宜设得太短，至少要让 compact 有足够的时间完成一轮压缩。

5. 真实运维场景复盘：日志清理失效，我是怎么一步步定位和解决的

5.1 场景一：磁盘暴涨的幕后黑手——活跃段不滚动

有一次我在客户现场排查一个问题：某个 Kafka 集群磁盘使用率从 60% 一路涨到 95%，耗时不到两周。客户的业务量并不大，而且 retention 设置的是 3 天。理论上来说磁盘占用应该很稳定，怎么会出现这种情况？

我先用df -h确认磁盘确实要满了，然后进入 broker 的日志目录，用du -sh *查看哪些 Topic 的目录占空间大，很快就锁定了几个 Topic。接着用ls -lh看这些分区目录下的日志段文件数量，结果发现有的分区居然只有一个日志段文件，而且这个文件已经超过 20GB。

问题找到了：这个 Topic 的消息量太小，log.segment.bytes=1GB下，一天只写几十 MB，日志段要几个月才能滚动一次，而活跃段又不参与清理，所以旧消息全堆在活跃段里，永远删不掉。

解决方案分两步：

1. 立即把这个 Topic 的segment.bytes调小到 256MB，或者设置segment.ms=3600000，让日志段每小时滚动一次。
2. 手动触发一次日志滚动，可以通过重启 broker 或者等待下一次滚动条件满足。

这个案例的教训是：别把log.segment.bytes当成一个"性能参数"，它其实直接决定了清理策略的有效性。消息量小的 Topic，segment 必须调小，否则日志清理就是空转。

5.2 场景二：设置了 retention 但日志就是不删——消费者组 pin 住了？

另一个非常常见的场景：retention 设置 1 天，但部分 Topic 的日志始终能查到 5 天甚至 10 天前的数据。我排查这个问题时，首先看了 broker 的日志清理线程有没有报错，发现没有；然后看了日志段的时间戳，发现很多日志段早就超过了 retention 阈值。

那为什么没删？我用kafka-consumer-groups.sh把所有消费这个 Topic 的消费者组信息都拉出来，逐个查看CURRENT-OFFSET和LOG-END-OFFSET。果然，有一个消费者组的CURRENT-OFFSET还停在大约 7 天前的位置，而且明显这个消费者组已经没人使用了。

日志段被这个已经"死掉"的消费者组 pin 住，导致清理线程不敢动它。处理办法是：先确认这个消费者组确实没有在用，然后删除消费者组（用 admin 工具或直接删除__consumer_offsets中对应的记录），或者用kafka-consumer-groups.sh --reset-offsets把 offset 重置到最新位置。操作完以后，下一次清理周期日志就被正常删除了。

补充一句：除了消费者组，Kafka 的事务机制也可能导致日志段无法删除。如果启用了事务，且某个事务一直没有 commit 或 abort，对应的日志段也不会被清理。这种问题可以通过查看事务状态来定位，相对冷门，但遇到了非常头大。

5.3 场景三：compact Topic 越积越大——Cleaner 线程被饿死了

再分享一个 compact 场景的问题。某个状态存储 Topic 设置了cleanup.policy=compact，但运行一段时间后，磁盘占用越来越大，而且用kafka-log-dirs.sh查看时发现日志段数量暴涨。

排查过程中我发现，这个 Topic 的写入 QPS 非常高，每秒钟有几万条消息，而且 Key 的重复率很高。按照正常逻辑，compaction 应该频繁触发才对，为什么日志还在膨胀？

我看了 broker 的监控指标，发现kafka.server:type=BrokerTopicMetrics里的压缩指标几乎没有增长，也就是说 Log Cleaner 线程根本没干活。再看log.cleaner.threads=1，只有 1 个线程，但是这个集群上有 3 个 compact Topic 同时在跑，其中一个 Topic 的数据量巨大，把唯一一个 Cleaner 线程占满了，其他 Topic 的压缩任务一直在排队。

解决方案是：把log.cleaner.threads调大到 4，同时把那个巨大的 compact Topic 单独拆分到独立的 broker 上，避免资源争抢。调完以后，压缩任务能正常执行，磁盘占用很快回落到正常水平。

这个案例告诉大家：compact 并非全自动的"免费午餐"，它依赖 Cleaner 线程池的处理能力。如果集群中 compact Topic 较多，一定要监控kafka.log:type=LogCleaner相关的指标，特别是cleaner-*线程的忙碌率。

6. 生产环境配置建议：这些参数搭配，我测了很久才稳定下来

6.1 我常用的配置参数表

这里给出一份我经过多轮压测和故障复盘后沉淀的配置参考，分成 broker 全局和 topic 级别两部分，大家可以直接抄作业，但要根据自己的业务体量做微调。

6.2 Topic 级别怎样覆盖全局配置

实际生产中，我们很少用一个全局配置管所有 Topic，因为不同业务的消息量、保留需求差异太大。Kafka 提供了非常灵活的 Topic 级别配置覆盖机制。

创建 Topic 时指定：

kafka-topics.sh --create \ --topic user-status \ --partitions 12 \ --replication-factor 3 \ --config cleanup.policy=compact \ --config delete.retention.ms=86400000 \ --config min.cleanable.dirty.ratio=0.3 \ --bootstrap-server localhost:9092

修改已有 Topic 的配置：

kafka-configs.sh --bootstrap-server localhost:9092 \ --alter \ --entity-type topics \ --entity-name user-status \ --add-config retention.ms=604800000,retention.bytes=5368709120

注意一个容易搞混的细节：Topic 级别的retention.ms和retention.bytes是分区维度的还是整个 Topic 维度的？答案：对于 topic 级别的配置，Kafka 会把值除以分区数来应用（严格来说是每个分区有独立的限额），而 broker 级别的log.retention.bytes也是每个分区独立判断。这意味着如果你设置了retention.bytes=10GB，这个 Topic 有 3 个分区，那么每个分区的限额是 10GB/3 吗？其实不是——准确说，Kafka 在判断时会拿"分区当前总大小"对比"分区保留的字节限额"，而retention.bytes在 topic 配置里会被统一当作每个分区的限额，不会自动分摊。这点文档描述得比较含糊，但实际验证下来，topic 级别的retention.bytes是每个分区都要满足的约束，也就是说总占用可能是该值的 N 倍（N 为分区数）。

6.3 千万要避开的几个"坑中坑"

1. 不要把log.cleanup.policy混用在同一集群的不同 Topic 时不做隔离。有些老版本 Kafka 对 cleanup 策略的切换支持不好，如果你把一个 Topic 从delete改为compact，可能需要在 broker 级别重启才能生效。现在新版本虽然支持动态切换，但切换后旧日志段的处理方式会有差异，建议先在测试环境验证。

2. 慎重设置min.cleanable.dirty.ratio过小。很多人为了压缩更频繁，把 ratio 设成 0.1，结果 Cleaner 线程忙到飞起，broker 的 CPU 飙高，反而影响了正常的消息读写。压缩是有代价的，不是越频繁越好。

3. Kafka 版本差异很大。不同版本的默认值不完全一样。比如 2.8 之前log.retention.hours默认是 168，但从某个版本开始引入了log.retention.ms等更细的配置。升级 Kafka 小版本后，如果你没有主动配过这些参数，默认值变化可能导致行为不一致。升级前务必先核对官方 release note。

4. Docker 部署 Kafka 时尤其要注意日志目录的挂载。很多人用 Docker 跑 Kafka 时，把日志目录映射到了容器内部没有持久化，导致容器重建后日志全丢，或者宿主机磁盘被撑爆。这不是日志清理策略本身的问题，但属于"存储层配错导致清理策略失效"的典型案例，值得专门提一句。

7. 从清理策略反推 Kafka 的全局存储设计逻辑

讲到这里，相信你对 Kafka 日志清理策略已经有了比较完整的认识。最后我想从更宏观的角度做一个延伸思考：为什么 Kafka 要设计这么复杂的清理机制？为什么不直接用常见的"过期消息自动删除"？

核心原因在于 Kafka 的设计哲学：它不是一个"用完即走"的临时消息管道，而是一个可重放、可回溯的分布式日志系统。消息的消费和删除是解耦的，生产者只管追加，消费者自行管理 offset，而消息的物理生命周期完全由清理策略这个独立的"物管系统"来维护。这给系统带来了极大的灵活性——你可以让一个消费者从一周前的 offset 开始重放，也可以让新消费者通过 compact 快速恢复全量状态。

理解了这一点，你就会明白为什么 Kafka 面试题里凡是涉及到"日志存储""消息过期""数据清理"的问题，都不仅仅是考一个知识点，而是在考察你对这套存储架构的深层理解。很多人背了很多参数，但遇到实际故障仍然一头雾水，就是因为缺乏这种"机制到问题"的映射能力。

以我个人的实际经验来说，维护 Kafka 集群这几年，日志清理方向的故障占了相当高的比例。每次排查到最后，都不是什么高深的问题，而是某个参数配置和生产环境不匹配。所以真心建议在做完任何一次集群配置变更后，都留出几分钟专门检查清理策略相关的配置项，这个习惯比任何监控告警都管用。