是否有可能迫使清理者为流量很低的分区压缩分区日志？

Question

是否可以强迫清洁器为流量很低的分区压缩分区日志？

对于将retention.policy设置为"compact, delete"的主题，可以理解压缩(以及对于空记录-删除)是在较干净的线程决定清理日志时发生的。这个决定是基于几件事。与这个问题相关的是段滚动功能；除非创建了一个新段，否则压缩不会运行。

段卷可以通过segment.ms和segment.bytes配置。

现在，为了这个问题。因为在记录被写入之前，活动段不会被清除，新段也不会成为活动段，那么是否有可能强迫清理器为不再接收任何写通信量的主题压缩分区日志呢？

示例日志：

$ kcat -b kafka:9092 -t foo -C -K:
1:hello
2:world
1:

不管配置如何，除非在1:null压缩之后写入记录，否则不会运行。然而：

$ echo "3:compact" | kcat -b kafka:9092 -t foo -P -K:
# `segment.ms` time passes
$ kcat -b kafka:9092 -t foo -C -K:
2:world
1:
3:compact

Answer 1

我在Community上做了进一步的研究，并验证了当书面记录的时间戳与当前活动段中的第一条记录的时间戳相差很大时，就会有段滚动。

换句话说，除非写入记录，否则段永远不会滚动。因此，问题的答案是“不，这是不可能的”。

Answer 2

如果log.cleaner.backoff.ms具有默认值(15000)，那么清理线程应该每15秒运行一次。当然，如果没有清理，什么也不做。墓碑消息(空消息)包含在清理过程中。如果启用了紧凑策略和delete策略，则delete策略应该遵循log.retit.*参数。当然，不能删除任何活动段。无论如何，请注意，因为清理线程逐段工作在完整的分区上，而当一个段完成清理时，相同的段将被清除的段所代替。如果清理线程没有足够的内存来清除一个段，那么它将被跳过，但是您应该会在kafka日志上看到一个错误。如果流量很低，您也许应该使用log.segment.bytes和log.segment.ms来调整您的段关闭策略。