【问题标题】:Kafka retention policy doesn't work as expectedKafka 保留政策未按预期工作
【发布时间】:2017-07-19 17:18:42
【问题描述】:

我想为我们拥有的一些用例实现数据重放,为此,我需要使用 Kafka 保留策略(我正在使用 join,我需要准确的窗口时间)。 附言我正在使用 Kafka 版本 0.10.1.1

我正在向这样的主题发送数据:

 kafkaProducer.send(
                    new ProducerRecord<>(kafkaTopic, 0, (long) r.get("date_time") ,r.get(keyFieldName).toString(), r)
            );

我这样创建我的主题:

kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic myTopic
kafka-topics --zookeeper localhost --alter --topic myTopic --config retention.ms=172800000 kafka-topics --zookeeper localhost --alter --topic myTopic --config segment.ms=172800000

所以通过上面的设置,我应该将我的话题的保留时间设置为48小时。

我扩展TimestampExtractor 以便记录每条消息的实际时间。

public class ConsumerRecordOrWallclockTimestampExtractor implements TimestampExtractor {
    private static final Logger LOG = LoggerFactory.getLogger(ConsumerRecordOrWallclockTimestampExtractor.class);
    @Override
    public long extract(ConsumerRecord<Object, Object> consumerRecord) {
        LOG.info("TIMESTAMP : " + consumerRecord.timestamp() + " - Human readable : " + new Date(consumerRecord.timestamp()));
        return consumerRecord.timestamp() >= 0.1 ? consumerRecord.timestamp() : System.currentTimeMillis();
    }
}

为了测试,我向我的主题发送了 4 条消息,我收到了这 4 条日志消息。

2017-02-28 10:23:39 信息 ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP: 1488295086292 人类可读-2017 年 2 月 28 日星期二 10:18:06 EST
2017-02-28 10:24:01 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - 时间戳:1483272000000 人类可读 -Sun Jan 01 07:00:00 EST 2017
2017-02-28 10:26:11 信息 ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP: 1485820800000 人类可读-2017 年 1 月 30 日星期一 19:00:00 EST
2017-02-28 10:27:22 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - 时间戳:1488295604411 人类可读-2017 年 2 月 28 日星期二 10:26:44 EST

因此,根据Kafka's retention policy,我预计我的两条消息会在 5 分钟后被清除/删除(第二条和第三条消息是在 1 月 1 日和 1 月 30 日发送的)。但是我尝试使用我的主题一个小时,每次使用我的主题时,我都会收到所有 4 条消息。

kafka-avro-console-consumer --zookeeper localhost:2181 --from-beginning --topic myTopic

我的 Kafka 配置是这样的:

############################# Log Retention Policy #############################

# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.

# The minimum age of a log file to be eligible for deletion
log.retention.hours=168

# A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
# segments don't drop below log.retention.bytes.
#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824

# The interval at which log segments are checked to see if they can be deleted according
# to the retention policies
log.retention.check.interval.ms=300000

我做错了什么还是我错过了什么?

【问题讨论】:

    标签: apache-kafka purge


    【解决方案1】:

    Kafka 通过删除日志段来实施其保留策略。 Kafka 从不删除活动段,该段是将发送到分区的新消息附加到该段。 Kafka 只删除旧段。当新消息发送到分区时,Kafka 会将活动段滚动到旧段中,并且

    • 包含新消息的活动段的大小将超过log.segment.bytes,或者
    • 活动段中第一条消息的时间戳早于log.roll.ms(默认为 7 天)

    因此,在您的示例中,您必须在 2017 年 2 月 28 日星期二 10:18:06 EST 2017 之后等待 7 天,发送一条新消息,然后所有 4 条初始消息都将被删除。

    【讨论】:

    • 如果是这样,当我在 5 分钟后发送两条时间戳为 1970 的消息(非常旧的消息)都被删除时,它如何解释?
    猜你喜欢
    • 2018-07-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-08
    • 2019-07-30
    • 2021-07-09
    • 2020-12-29
    相关资源
    最近更新 更多