我来帮你厘清kafka-delete-records.sh的实际工作机制——这确实是很多Kafka使用者容易混淆的点：

简单来说，这个工具的操作分为两步，既不是只调整偏移量就完事，也不会立刻执行物理删除：

• 第一步：标记数据为不可用（调整Low Watermark）
  当你运行kafka-delete-records.sh指定要删除到某个偏移量时，Kafka会先更新对应分区的low_watermark（最小可用偏移量）。这一步完成后，所有消费者（不管是正在运行的还是新启动的）都会从这个新的偏移量开始读取数据——之前的记录对消费者来说完全不可见，就像已经被删除了一样。但此时这些记录还实实在在地存在于Broker的日志文件中，只是被标记为"消费者不可访问"。

• 第二步：后台异步完成物理删除
  之后，Kafka的日志清理线程会根据你配置的日志清理策略（比如log.cleanup.policy设为delete或者compact），自动处理这些被标记的记录：

  • 如果是delete策略：当某个日志段文件里的所有记录都低于low_watermark时，整个日志段会被彻底删除；
  • 如果是compact策略：除了清理重复键的旧记录，也会移除所有低于low_watermark的记录。
    这个物理删除过程是异步的，不会在你执行删除命令时立刻完成，具体耗时取决于集群的负载和清理线程的配置。

结合你提到的KIP补充说明 #

• KIP-107正是kafka-delete-records.sh功能的源头，它引入了"删除指定偏移量之前记录"的能力，核心就是通过调整low_watermark来隔离消费者和待删除数据；
• KIP-204则优化了日志清理的效率，让物理删除的过程更流畅，但并没有改变"标记不可用+后台清理"的核心逻辑。

如果你想确认物理删除是否完成，可以直接查看Broker的日志目录，检查对应分区的日志段文件是否已经被移除；或者用kafka-log-dirs.sh工具来查看分区的日志段状态。

内容的提问来源于stack exchange，提问作者David Zamora