Am1*_*3zA 3 purge apache-kafka
我想为我们的一些人实现数据重放,为此,我需要使用Kafka保留策略(因为我正在使用join,我需要窗口时间准确).PS我使用的是Kafka版本0.10.1.1
我将数据发送到这样的主题:
kafkaProducer.send(
new ProducerRecord<>(kafkaTopic, 0, (long) r.get("date_time") ,r.get(keyFieldName).toString(), r)
);
Run Code Online (Sandbox Code Playgroud)
我创建这样的主题:
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-主题--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();
}
}
Run Code Online (Sandbox Code Playgroud)
为了测试,我已经向我的主题发送了4条消息,我得到了这4条日志消息.
2017-02-28 10:23:39 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP:1488295086292 Human readble -Tue Feb 28 10:18:06 EST 2017
2017-02-28 10:24:01 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP:1483272000000 Human readble -Sun Jan 01 07:00:00 EST 2017
2017-02-28 10:26:11 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP:1485820800000 Human readble -Mon Jan 30 19:00:00 EST 2017
2017-02-28 10: 27:22 INFO ConsumerRecordOrWallclockTimestampExtractor:21 - TIMESTAMP:1488295604411 Human readble -Tue Feb 28 10:26:44 EST 2017
因此,根据Kafka的保留政策,我预计会在5分钟后看到我的两条消息被清除/删除(自1月1日和1月30日以来第2和第3消息).但我试着消耗我的主题一个小时,每次我消耗我的主题我得到了所有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
Run Code Online (Sandbox Code Playgroud)
我做错了什么或者我错过了什么?
Chi*_*ang 12
Kafka通过删除日志段来实施其保留策略.Kafka从不删除活动段,该段是将附加发送到分区的新消息的段.卡夫卡只删除旧段.当新消息发送到分区时,Kafka将活动段滚动到旧段中
log.segment.bytes或log.roll.ms(默认为7天)因此,在您的示例中,您必须在2017年2月28日10:18:06之后等待7天,发送新消息,然后将删除所有4条初始消息.
| 归档时间: |
|
| 查看次数: |
4034 次 |
| 最近记录: |