差点被这个Kafka的删除策略难住了

原创

已于 2024-07-13 14:31:18 修改 · 1.2k 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#kafka #分布式

于 2024-07-13 14:13:13 首次发布

最近接一个任务，任务发到我这里的时候，已经由同事查了两天，没查出原因。查了两天的问题转给我来查，当然是因为我~~能力强~~ （死马当活马医）。

了解任务背景

业务中发送了大量的kafka消息，因此为了避免kafka的历史消息堆积导致磁盘占满，业务会修改某几个topic的消息保留时间。测试发现，页面上把topicA消息的保留时间改为只保留一天，但仍能查到超过一天的消息，也就是修改某个topic的消息保留时间，但没有其效果。（排查、分析过程比较长，可以直接跳过看总结）

排查

先按常规步骤试一下，KAFKA-UI上直接将retain时间改为1天中：Topics-[业务topic的名字]-右上角按钮-EditSetting-Time to retain data (in ms) 。

修改后观察到kafka日志确实有打印 ConfigRsource ... name='topicA' ... set configuration retention.ms to 86400000 的字样。紧接着5分钟(log.retention.check.interval.ms)之内，又打印partition=topicA ... Deleting和Deleted ... /data/topicA-0.log.deleted 。使用 du -sm查看/data目录，确实变小了，日志里面提到的文件也被删掉了。Kafka-ui页面上查的数据也是一天左右（有几条消息超出了十分钟左右）。

到此，我以为就完了。高兴的跟同事反馈：“你看，这个没问题。” 同事一脸不信：“我试了那么久都不行，你一下就行了？”（可能是我天选之人吧）我拉着同事一起查看日志，他也信了，说着让我再试试其他topic，这次用系统的上接口来调用一下。我想着，有道理，也有可能是我们的使用的KAFKA API没调通导致的。

继续排查

打开我们自己的系统页面，点击配置，把topicA、topicB改为只保留一天。观察到日志里打印 topicB的配置被修改成一天（topicA前面已经改了，这次没打日志也说得过去），紧接着是对topicB的删除。事情是那么顺利，我不急不忙的打开kafka-ui查看topicB的数据：当前时间是下午两点，数据只保留到昨天的12点后的数据。嗯，只有一天。嗯？但为何不是只保留有昨天2点后的数据？可能清除的时候有点误差吧，再观察观察，反正5分钟(log.retention.check.interval.ms)后又要清理。

… 1个小时过去了 …

没等来topicB的二次清理。倒是topicA不定时的清理了几次。

我一边bing，一边KIMI搜索：KAFKA日志删除策略。
然后KIMI告诉我：