Kafka 甚至在达到段大小之前删除段

Question

我在本地机器上玩Kafka，我添加了以下Topic配置：

bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 config retention.ms=60000
bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 —config file.delete.delay.ms=40000
bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 --config segment.bytes=400000

我的理解是，当段达到上面定义的段大小 (segment.bytes=400000) 加上段中的每条消息都比上面定义的保留时间 (retention.ms=60000) 旧时，段将被删除。

我注意到的是只有 35 个字节的段，其中只包含一条消息，一分钟后被删除（可能多一点）

我从哪里得到这些信息？来自 Linkedin 工程师关于删除过程如何工作的帖子：

保留将基于保留和段大小设置的组合（作为旁注，建议使用 log.retention.ms 和 log.segment.ms，而不是小时配置。这是出于遗留原因，但 ms 配置更一致）。当 Kafka 收到消息时，它们会被写入每个分区的当前打开的日志段。当达到 log.segment.bytes 或 log.segment.ms 限制时，该段将被轮换。一旦发生这种情况，日志段将关闭并打开一个新段。只有在日志段关闭后才能通过保留设置将其删除。一旦日志段关闭并且该段中的所有消息都早于 log.retention.ms 或总分区大小大于 log.retention.bytes，则该日志段将被清除。

链接：保留的工作原理

Answer 1

有一个代理配置 - log.retention.check.interval.ms会影响此测试。默认为 5 分钟。因此，每 5 分钟检查一次代理日志段，看看是否可以根据保留策略将其删除。

topic1 配置设置了保留策略 ( retention.ms =60000)，因此，如果 topic1 的活动段中至少有一条现有消息，则该段闲置足够长的时间后将被关闭并删除。由于 log.retention.check.interval.ms 是代理配置，因此它不受主题更改的影响。在最后一条消息生成到段后，retention.ms 也必须传递。因此，在该段生成最后一条消息后，段将在不少于retention.ms毫秒且不超过retention.ms+log.retention.check.interval.ms的时间内被删除。

因此，“仅包含一条消息的 35 个字节的段在一分钟（可能多一点）后就被删除了”，因为保留检查几乎是在消息生成到该段后立即发生的。然后，代理只需等待 60 秒，以确保不会为该段生成新消息（在这种情况下，不会发生删除），并且由于没有新消息，因此它删除了该段

其他 topic1 配置在这里没有发挥多大作用。

file.delete.delay.ms =40000 刚刚定义，在代理已经决定删除​​该段之后，它应该等待 40 秒才能执行此操作

segment.bytes =400000 在此测试中没有任何影响。它定义了当 400000 字节存储到该段后，应将其关闭并推出新的段。

Answer 2

您误解了您引用的一些陈述：

当达到 log.segment.bytes 或 log.segment.ms 限制时，该段将轮换。

这清楚地表明旋转可以由大小或时间触发。是或，不是和。

一旦发生这种情况，日志段就会关闭。[...] 一旦日志段关闭并且该段中的所有消息都早于 log.retention.ms 或总分区大小大于 log.retention.bytes，则日志段将被清除。

这样，当一个段因时间触发的旋转而关闭后，无论它的大小如何，都可以将其删除。