1. 为什么说日志清理是 Kafka 集群的隐形命门先说句可能颠覆很多人认知的话在 Kafka 的日常运维里真正让集群出大事的往往不是消息堆积、不是消费者宕机而是日志清理策略配置不当。我见过凌晨三点被拉起来处理磁盘告警的同行也见过因为日志段文件无法删除导致整个分区不可写的惨痛案例最后定位下来十有八九是清理策略没吃透。Kafka 之所以叫分布式消息队列很多人只记住了分布式消息队列却忽略了它底层其实是一个基于日志文件的分布式存储系统。每一个主题Topic的分区Partition在物理存储上都对应着一组日志段LogSegment文件。这些文件不断追加写入如果不加节制磁盘再大也有被撑爆的一天。这时就需要日志清理策略登场——它本质上就是 Kafka 自带的磁盘空间管理机制决定了一个日志文件什么时候可以被删除、什么时候需要被压缩、哪些数据可以淘汰、哪些数据必须保留。我接触过的很多入门开发者对这块的认知停留在默认保留7天日志这种粗浅层面真到生产环境一压测问题就全暴露出来了。举个例子你在 server.properties 里配置了log.retention.hours168以为日志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.bytes1073741824默认1GB你的业务流量很小一天只写入 10MB 数据那么这个活跃段可能要 100 天才能写满。此时即便你设置了log.retention.hours72保留3天实际上旧数据在磁盘上会留存远远超过 3 天——因为消息还在活跃段里而活跃段不滚动、不删除。用大白话说就是日志清理策略的生效前提是日志段已经不属于活跃段。要让旧数据真正被清掉日志段必须被滚动roll成非活跃段然后等待清理线程来处理。所以生产环境里如果你的业务消息量很小强烈建议调小log.segment.bytes或log.roll.hours。比如设置log.segment.bytes268435456256MB或log.roll.hours24保证日志段一天甚至更短时间就滚动一次这样清理策略才能真正发挥作用。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.hours1687天。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.hours72。按理说 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.msxxx和--config retention.bytesxxx覆盖。改配置的优先级是 Topic 级别 broker 级别这个优先级关系经常被搞混面试也爱考。3.3 基于起始偏移量的删除配合消费者进度理解 file.delete.delay.msKafka 删除日志段时还遵循一个原则不会删除当前消费者还在消费的日志段。更准确地说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 策略的完整执行链路方便你理解整个流程消息不断写入活跃段当活跃段达到log.segment.bytes大小或log.roll.hours时间时滚动生成新的活跃段旧的变为非活跃段。日志清理线程周期性扫描所有非活跃日志段默认每 5 分钟一次。对每个日志段依次检查是否超过时间 retention → 是否超过大小 retention → 是否被某个消费者组 pin 住。需要删除的日志段先被标记为delete状态等待log.segment.delete.delay.ms延迟时间。延迟结束后执行真正的文件删除操作同时删除对应的.log、.index、.timeindex文件。这个流程看起来简单但每个环节都可能出问题。最常见的就是第 3 步里消费者组 pin 住日志段我甚至见过一个测试环境里消费者程序没有配置enable.auto.commitfalse也没手动提交 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 的工作过程稍微复杂一些我分步骤说明标记 dirty 区域每个 compact Topic 的日志会划分为clean 区域和dirty 区域。clean 区域是已经完成压缩的部分dirty 区域是待压缩的新写入数据。随着消息不断写入dirty 区域不断扩张。构建 Key 映射表Cleaner 在压缩某个日志段之前会先构建一个Key → 最新 Offset的映射表。它从 dirty 区域中从后往前遍历消息记录每个 Key 出现的最新偏移量。逐段复制保留消息Cleaner 逐一处理日志段把当前偏移量等于该 Key 最新偏移量的消息复制到保留区其余消息丢弃。替换日志段压缩完成后用保留的消息生成新的日志段文件替换掉旧的日志段同时更新索引。你可能会问压缩过程中如果生产者还在不断写入怎么办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 为 nullKafka 不会立刻删除它而是会等到超过delete.retention.ms之后才真正删除。这是为了给消费者足够的时间处理删除事件。如果你的业务中有大量 tombstone 消息要注意这个参数否则带 null 的消息会一直堆积。4.4 compact 和 delete 组合cleanup.policycompact,delete很多人不知道Kafka 的log.cleanup.policy其实支持两个值同时设置写法是compact,delete。这意味着 Kafka 会同时执行两种清理策略先按 delete 策略删除过期日志段再对剩余日志段做 compact 压缩。这种组合在真实生产环境中非常有用。举个例子你有一个订单事件 Topic希望每个订单 ID 只保留最新状态用 compact同时不想让日志无限膨胀用 delete 兜底。此时设置cleanup.policycompact,delete并配合retention.ms6048000007天就既能保证 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.bytes1GB下一天只写几十 MB日志段要几个月才能滚动一次而活跃段又不参与清理所以旧消息全堆在活跃段里永远删不掉。解决方案分两步立即把这个 Topic 的segment.bytes调小到 256MB或者设置segment.ms3600000让日志段每小时滚动一次。手动触发一次日志滚动可以通过重启 broker 或者等待下一次滚动条件满足。这个案例的教训是别把log.segment.bytes当成一个性能参数它其实直接决定了清理策略的有效性。消息量小的 Topicsegment 必须调小否则日志清理就是空转。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.policycompact但运行一段时间后磁盘占用越来越大而且用kafka-log-dirs.sh查看时发现日志段数量暴涨。排查过程中我发现这个 Topic 的写入 QPS 非常高每秒钟有几万条消息而且 Key 的重复率很高。按照正常逻辑compaction 应该频繁触发才对为什么日志还在膨胀我看了 broker 的监控指标发现kafka.server:typeBrokerTopicMetrics里的压缩指标几乎没有增长也就是说 Log Cleaner 线程根本没干活。再看log.cleaner.threads1只有 1 个线程但是这个集群上有 3 个 compact Topic 同时在跑其中一个 Topic 的数据量巨大把唯一一个 Cleaner 线程占满了其他 Topic 的压缩任务一直在排队。解决方案是把log.cleaner.threads调大到 4同时把那个巨大的 compact Topic 单独拆分到独立的 broker 上避免资源争抢。调完以后压缩任务能正常执行磁盘占用很快回落到正常水平。这个案例告诉大家compact 并非全自动的免费午餐它依赖 Cleaner 线程池的处理能力。如果集群中 compact Topic 较多一定要监控kafka.log:typeLogCleaner相关的指标特别是cleaner-*线程的忙碌率。6. 生产环境配置建议这些参数搭配我测了很久才稳定下来6.1 我常用的配置参数表这里给出一份我经过多轮压测和故障复盘后沉淀的配置参考分成 broker 全局和 topic 级别两部分大家可以直接抄作业但要根据自己的业务体量做微调。配置项推荐值适用场景备注log.retention.hours723天日志型 Topic按合规要求和业务需求调整log.retention.bytes10737418241GB高频写入 Topic给磁盘兜底建议必配log.segment.bytes268435456256MB小消息量 Topic消息量大可保持默认 1GBlog.roll.hours24通用保证日志段每天滚动一次log.cleanup.policydelete或compact,delete按业务选择状态存储类用 compactlog.cleaner.threads4多 compact Topic单线程容易成瓶颈log.retention.check.interval.ms3000005分钟通用调小可加快清理响应log.segment.delete.delay.ms600001分钟通用不建议设 0给消费者缓冲min.cleanable.dirty.ratio0.5默认compact Topic按需调小到 0.2~0.3file.delete.delay.ms600001分钟通用配合文件删除的延迟6.2 Topic 级别怎样覆盖全局配置实际生产中我们很少用一个全局配置管所有 Topic因为不同业务的消息量、保留需求差异太大。Kafka 提供了非常灵活的 Topic 级别配置覆盖机制。创建 Topic 时指定kafka-topics.sh --create \ --topic user-status \ --partitions 12 \ --replication-factor 3 \ --config cleanup.policycompact \ --config delete.retention.ms86400000 \ --config min.cleanable.dirty.ratio0.3 \ --bootstrap-server localhost:9092修改已有 Topic 的配置kafka-configs.sh --bootstrap-server localhost:9092 \ --alter \ --entity-type topics \ --entity-name user-status \ --add-config retention.ms604800000,retention.bytes5368709120注意一个容易搞混的细节Topic 级别的retention.ms和retention.bytes是分区维度的还是整个 Topic 维度的答案对于 topic 级别的配置Kafka 会把值除以分区数来应用严格来说是每个分区有独立的限额而 broker 级别的log.retention.bytes也是每个分区独立判断。这意味着如果你设置了retention.bytes10GB这个 Topic 有 3 个分区那么每个分区的限额是 10GB/3 吗其实不是——准确说Kafka 在判断时会拿分区当前总大小对比分区保留的字节限额而retention.bytes在 topic 配置里会被统一当作每个分区的限额不会自动分摊。这点文档描述得比较含糊但实际验证下来topic 级别的retention.bytes是每个分区都要满足的约束也就是说总占用可能是该值的 N 倍N 为分区数。6.3 千万要避开的几个坑中坑不要把log.cleanup.policy混用在同一集群的不同 Topic 时不做隔离。有些老版本 Kafka 对 cleanup 策略的切换支持不好如果你把一个 Topic 从delete改为compact可能需要在 broker 级别重启才能生效。现在新版本虽然支持动态切换但切换后旧日志段的处理方式会有差异建议先在测试环境验证。慎重设置min.cleanable.dirty.ratio过小。很多人为了压缩更频繁把 ratio 设成 0.1结果 Cleaner 线程忙到飞起broker 的 CPU 飙高反而影响了正常的消息读写。压缩是有代价的不是越频繁越好。Kafka 版本差异很大。不同版本的默认值不完全一样。比如 2.8 之前log.retention.hours默认是 168但从某个版本开始引入了log.retention.ms等更细的配置。升级 Kafka 小版本后如果你没有主动配过这些参数默认值变化可能导致行为不一致。升级前务必先核对官方 release note。Docker 部署 Kafka 时尤其要注意日志目录的挂载。很多人用 Docker 跑 Kafka 时把日志目录映射到了容器内部没有持久化导致容器重建后日志全丢或者宿主机磁盘被撑爆。这不是日志清理策略本身的问题但属于存储层配错导致清理策略失效的典型案例值得专门提一句。7. 从清理策略反推 Kafka 的全局存储设计逻辑讲到这里相信你对 Kafka 日志清理策略已经有了比较完整的认识。最后我想从更宏观的角度做一个延伸思考为什么 Kafka 要设计这么复杂的清理机制为什么不直接用常见的过期消息自动删除核心原因在于 Kafka 的设计哲学它不是一个用完即走的临时消息管道而是一个可重放、可回溯的分布式日志系统。消息的消费和删除是解耦的生产者只管追加消费者自行管理 offset而消息的物理生命周期完全由清理策略这个独立的物管系统来维护。这给系统带来了极大的灵活性——你可以让一个消费者从一周前的 offset 开始重放也可以让新消费者通过 compact 快速恢复全量状态。理解了这一点你就会明白为什么 Kafka 面试题里凡是涉及到日志存储消息过期数据清理的问题都不仅仅是考一个知识点而是在考察你对这套存储架构的深层理解。很多人背了很多参数但遇到实际故障仍然一头雾水就是因为缺乏这种机制到问题的映射能力。以我个人的实际经验来说维护 Kafka 集群这几年日志清理方向的故障占了相当高的比例。每次排查到最后都不是什么高深的问题而是某个参数配置和生产环境不匹配。所以真心建议在做完任何一次集群配置变更后都留出几分钟专门检查清理策略相关的配置项这个习惯比任何监控告警都管用。