kafka日志管理核心是分清“怎么切段”和“留多久”：按大小（log.segment.bytes，默认1gb）或时间（log.segment.ms，默认7天，最小1天）触发分段；保留策略基于关闭segment的largesttimestamp，优先用log.retention.ms（毫秒级），配合log.retention.bytes控空间，清理策略由log.cleanup.policy决定（delete/compact）。
直接在 Broker 配置或 Topic 级别设几个关键参数就能控制日志分段和保留行为，核心是分清“怎么切段”和“留多久”两件事。
日志分段怎么切：控制 segment 创建节奏
分段（Segment）是 Kafka 日志管理的最小物理单位，切段行为由两个独立条件触发——满足任一即生成新段：
- 按大小切：用 log.segment.bytes 控制单个 .log 文件最大容量，默认 1073741824（1GB）。达到即滚动生成新段，不可设为 0，设为 -1 不推荐（可能撑爆磁盘）。
- 按时间切：用 log.segment.ms 指定活跃段最长存活毫秒数，默认 604800000（7 天）。注意：最小允许值为 86400000（1 天），低于该值会被自动纠正。
两者是“或”关系。比如设 segment.bytes=512MB、segment.ms=3600000（1 小时），那么只要消息写满 512MB 或已过 1 小时，当前段就关闭，新段开始接收数据。
消息保留多久：决定哪些段能被删
保留策略不作用于单条消息，而是判断整个 segment 是否可清理。生效前提是 segment 已关闭（非 active 状态）：
- 优先用毫秒级精度：配置 log.retention.ms（如 259200000 表示 3 天），它会覆盖 log.retention.hours / minutes / days；生产环境建议只设这一个，避免单位混用导致误判。
- 判断依据是段内最后一条消息时间戳（largestTimeStamp），不是文件修改时间。所以即使系统时间被调整，只要消息自带时间戳，保留逻辑依然准确。
- 延迟删除：标记为可删后，还要等 log.segment.delete.delay.ms（默认 60000，即 1 分钟）才真正从磁盘移除文件，这是安全保护机制。
空间上限怎么控：防止磁盘打满
大小策略独立于时间策略，也是“或”关系，按 Partition 单独计算：
- 设 log.retention.bytes（如 1073741824 = 1GB），表示该分区所有 segment 总大小上限；超限后，最老的完整 segment 被整段删除。
- 这个值对每个 Partition 生效，不是整个 Topic 或 Broker。12 分区 Topic 设为 1GB，理论峰值约 12GB（不含副本）。
- 设为 -1 表示不限大小，仅靠时间策略控制——线上慎用，必须配强监控，否则容易触发磁盘告警。
清理动作怎么选：delete 还是 compact？
最终执行什么操作，由 log.cleanup.policy 决定：
- delete（默认）：过期或超限的 segment 直接物理删除。
- compact：只对有 key 的消息有效，保留每个 key 的最新值；需同时开启 log.cleaner.enable=true，否则策略不生效。
- delete,compact：先压缩再按时间/大小裁剪冗余段，适合既要保状态又要控体积的场景（如用户资料 + 行为日志混合 Topic）。
