kafka磁盘空间管控核心是合理配置保留策略：必须同时设置retention.ms与log.segment.bytes，并配合log.retention.check.interval.ms，通过时间与大小双重条件触发周期性清理，避免单维度配置导致磁盘暴胀或数据冗余。
直接控制磁盘空间不被历史消息撑爆，关键不是“清空”或“手动删”，而是让 Kafka 自动、准时、按需清理——核心靠保留策略（retention policy）的合理组合与分层配置。
明确保留策略的触发逻辑
Kafka 的清理不是“等满了再删”，而是周期性检查（默认每5分钟）哪些日志段已满足删除条件。它用的是“或”逻辑：只要满足时间 或 大小任一条件，就标记为可删。所以单设时间或单设大小都不够稳妥，尤其在流量波动大的场景下。
- 只设时间（如7天）：突发写入高峰可能在1天内就占满磁盘
- 只设大小（如10GB）：低流量主题可能几个月都没数据，但旧消息一直留着，浪费空间
- 建议同时设置两者，形成双重保险
优先使用毫秒级统一配置（避免歧义）
别混用 log.retention.hours、log.retention.minutes 和 log.retention.ms。Kafka 内部按优先级取值：ms > minutes > hours，容易覆盖出错。Java 应用侧或 Docker 部署时，统一用 retention.ms 最可靠。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 例如：保留24小时 → 设为
retention.ms=86400000 - 保留3天 →
retention.ms=259200000 - 在
server.properties或 Docker 环境变量中写死这个值，避免隐式继承导致偏差
主题级覆盖比集群级更安全
不要指望所有主题都适用同一套保留规则。比如用户行为日志可设1天，审计日志要存90天，而配置变更 topic 可能需要永久保留（设为 -1）。
- 创建主题时指定：
kafka-topics.sh --create --topic audit-log --config retention.ms=7776000000（90天） - 已有主题动态调整：
kafka-configs.sh --alter --entity-type topics --entity-name user-events --add-config retention.ms=86400000 - 这样既避免测试环境误删关键数据，也防止生产环境因全局7天策略导致磁盘告警
配合日志段大小与检查间隔提升响应速度
保留策略生效依赖两个底层机制：日志段（segment）切分粒度，和清理任务执行频率。
-
log.segment.bytes=1073741824（1GB）：段太大，清理时一次性删太多；太小（如10MB）则文件过多，扫描慢。1GB 是较平衡的选择 -
log.retention.check.interval.ms=300000（5分钟）：默认值通常够用，若磁盘增长极快（如每小时新增50GB），可调至60000（1分钟）加快响应 - 注意：
log.cleanup.policy=delete必须显式保留（默认就是 delete），压缩策略（compact）仅适用于键值型状态类数据，不解决磁盘占用问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
