转载连接:Kafka 日志消息保存时间总结_月亮船长的博客-CSDN博客_kafka默认消息保留时间
Kafka 日志消息保存时间总结
Kafka 作为一个高吞吐的消息中间件和传统的消息中间件一个很大的不同点就在于它的日志实际上是以日志的方式默认保存在/kafka-logs文件夹中的。虽然默认有7天清楚的机制,但是在数据量大,而磁盘容量不足的情况下,经常出现无法写入的情况。如何调整Kafka的一些默认参数就显得比较关键了。这里笔者整理了一些常见的配置参数供大家参考:
分段策略属性
属性名 | 含义 | 默认值 |
---|---|---|
log.roll.{hours,ms} | 日志滚动的周期时间,到达指定周期时间时,强制生成一个新的segment | 168(7day) |
log.segment.bytes | 每个segment的最大容量。到达指定容量时,将强制生成一个新的segment | 1G(-1为不限制) |
log.retention.check.interval.ms | 日志片段文件检查的周期时间 | 60000 |
日志刷新策略
Kafka的日志实际上是开始是在缓存中的,然后根据策略定期一批一批写入到日志文件中去,以提高吞吐率。
属性名 | 含义 | 默认值 |
---|---|---|
log.flush.interval.messages | 消息达到多少条时将数据写入到日志文件 | 10000 |
log.flush.interval.ms | 当达到该时间时,强制执行一次flush | null |
log.flush.scheduler.interval.ms | 周期性检查,是否需要将信息flush | 很大的值 |
日志保存清理策略
属性名 | 含义 | 默认值 |
---|---|---|
log.cleanup.polict | 日志清理保存的策略只有delete和compact两种 | delete |
log.retention.hours | 日志保存的时间,可以选择hours,minutes和ms | 168(7day) |
log.retention.bytes | 删除前日志文件允许保存的最大值 | -1 |
log.segment.delete.delay.ms | 日志文件被真正删除前的保留时间 | 60000 |
log.cleanup.interval.mins | 每隔一段时间多久调用一次清理的步骤 | 10 |
log.retention.check.interval.ms | 周期性检查是否有日志符合删除的条件(新版本使用) | 300000 |
这里特别说明一下,日志的真正清楚时间。当删除的条件满足以后,日志将被“删除”,但是这里的删除其实只是将该日志进行了“delete”标注,文件只是无法被索引到了而已。但是文件本身,仍然是存在的,只有当过了log.segment.delete.delay.ms 这个时间以后,文件才会被真正的从文件系统中删除。
使用命令删除:
1.高版本的kafka,提供了直接删除n条消息的操作方法。
脚本内容地址:
-
https://github.com/apache/kafka/blob/trunk/bin/kafka-delete-records.sh
使用这个脚本, 配套的还有一个json文件。 新建一个json文件,内容如下,里面指定了partition和offset. 然后把这个文件保存为 offset.json
{"partitions": [{"topic": "mytest", "partition": 0, "offset": 90}], "version":1 }
这时候调用脚本,可以做到删除
./kafka-delete-records.sh --bootstrap-server localhost:9092 --offset-json-file ./offset.json
2.如果上述方法,提示错误:
Error: Could not find or load main class kafka.admin.DeleteRecordsCommand
则说明kafka版本过低,这时候可以使用另一种方法。
./kafka-topics.sh --zookeeper 127.0.0.1:2181 --alter --topic testTopic --config retention.ms=时间(微秒)
动态地更新消息保留时间,假如只保留一小时之内的消息 ,60 x 60 x 1000 = 360000 就设置为retention.ms=3600000
然后kafka需要轮询,之后会执行删除
注意:kafka执行完删除后 你需要再次调用这个脚本 把时间还原回去
这种方法,误差根据你服务器的配置来决定的。由kafka配置文件的log.retention.check.interval.ms参数控制。 并且因为有很多个节点,经常是某个节点删除了数据之后,其他的节点还没有轮询到删除操作。 总的来说精确度不是很高。