Kafka 做为一个高吞吐的消息中间件和传统的消息中间件一个很大的不一样点就在于它的日志其实是以日志的方式默认保存在/kafka-logs文件夹中的。虽然默认有7天清楚的机制,可是在数据量大,而磁盘容量不足的状况下,常常出现没法写入的状况。如何调整Kafka的一些默认参数就显得比较关键了。这里笔者整理了一些常见的配置参数供你们参考:apache
分段策略属性
属性名 | 含义 |默认值
---|---|--
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 这个时间之后,文件才会被真正的从文件系统中删除。文档