一、为什么需要关注日志保留策略
很多刚开始用Kafka的朋友都会忽略日志保留配置，直到某天发现磁盘爆满才追悔莫及。这就像家里从来不收拾，等到连下脚的地方都没有了才开始大扫除。Kafka的日志文件会不断增长，如果不加限制，很快就会把磁盘空间吃光。
举个例子，假设你有个电商系统，订单数据通过Kafka传输。双十一期间订单量暴增，如果不设置合理的保留策略，可能三天就把500G的磁盘写满了。这时候新订单就进不来了，整个系统就会瘫痪。
二、常见的配置误区
1. 只设置时间保留策略
很多人以为只要设置log.retention.hours=168（7天）就万事大吉了。但实际上，Kafka的日志清理是按照segment文件为单位进行的。如果一个segment文件里既有7天前的数据又有6天前的数据，这个文件就不会被删除。
// Kafka配置示例（Java技术栈）
Properties props = new Properties();
props.put("log.retention.hours", "168"); // 只设置这个是不够的
props.put("log.segment.bytes", "1073741824"); // 每个segment文件1GB
props.put("log.retention.check.interval.ms", "300000"); // 5分钟检查一次
2. 忽略磁盘空间监控
即使设置了保留策略，也要监控磁盘使用情况。因为如果数据写入速度突然加快，可能在保留时间到达前就把磁盘写满了。
3. 所有topic使用相同配置
不同topic的重要性不同，应该区别对待。比如用户行为日志可以保留3天，订单数据可能需要保留30天。
三、正确的配置方法
1. 时间+大小双重保险
建议同时设置时间和大小限制，这样无论哪个条件先达到都会触发清理。
// 推荐配置方式
props.put("log.retention.hours", "168"); // 7天
props.put("log.retention.bytes", "536870912000"); // 500GB总大小限制
props.put("log.segment.bytes", "1073741824"); // 每个segment 1GB
props.put("log.segment.ms", "86400000"); // 每天生成一个新segment
2. 针对不同topic定制配置
可以通过Kafka的配置工具为重要topic单独设置：
# 为订单topic设置更长的保留时间
bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name orders --alter --add-config retention.ms=2592000000
四、高级优化技巧
1. 压缩日志节省空间
对于文本类日志，可以启用压缩：
props.put("compression.type", "gzip"); // 使用gzip压缩
props.put("min.compaction.lag.ms", "3600000"); // 消息至少1小时后才压缩
2. 分层存储
新版本Kafka支持将旧数据转移到廉价存储：
props.put("log.dirs", "/fast/ssd,/slow/hdd"); // SSD存新数据，HDD存旧数据
props.put("log.retention.ms", "604800000"); // SSD保留7天
props.put("log.retention.hours", "720"); // HDD保留30天
五、实际场景分析
1. 电商系统案例
- 订单数据：保留30天，压缩存储
- 支付流水：保留180天，不压缩
- 用户行为日志：保留7天，高压缩比
2. IoT设备数据
- 实时告警：保留3天，不压缩
- 设备状态：保留30天，中等压缩
- 历史统计：保留1年，高压缩
六、注意事项
- 修改配置后要滚动重启broker才能生效
- 清理是后台进行的，磁盘不会立即释放空间
- 监控清理线程是否正常工作
- 测试环境要先验证配置效果
- 考虑备份重要数据，不要完全依赖保留策略
七、总结
配置Kafka日志保留就像给家里制定打扫计划：太频繁了浪费精力，太少了又脏乱差。找到适合自己业务的平衡点最关键。记住三个要点：
- 时间和大小限制要同时设置
- 不同重要性的数据区别对待
- 一定要监控实际效果
合理的配置既能保证数据安全，又能节省存储成本。希望这些经验能帮你避开我踩过的坑。
评论