消息保留时间应该如何设置？

简化版

保留时间应覆盖最长故障恢复、消费积压、回滚重放和审计需求，并受磁盘与合规约束。容量粗算为 生产字节率 × 保留秒数 × 副本数 / 压缩比，再加索引、段文件和安全余量；不能只凭“保留越久越安全”。

详细版

不同 Topic 按业务分级：交易事件可能需要较长在线保留与归档，临时通知可短保留，含敏感数据还受最短删除期限约束。时间保留和大小保留通常同时生效，磁盘水位可能先触发删除，所以配置 7 天不代表任何时候都能读到 7 天。

监控最老消息年龄、磁盘增长、分区倾斜、删除速率和消费者最大 lag；保留期变更先计算容量并灰度。长期重放使用对象存储归档，配 Schema、校验和和索引，避免用昂贵 Broker 热存储承担永久档案。

完整版教学

一、从恢复目标反推

如果周末无人值守最长 48 小时、修复和追赶还需 24 小时，在线保留至少应超过 72 小时并留余量。保留期短于最大中断窗口，消费者恢复时消息已删除，再多实例也无法补回。

记忆钩子：保留期是可恢复窗口，不只是磁盘清理参数。

二、容量公式与算例

raw = bytes_per_second * retention_seconds
disk ≈ raw * replication_factor / compression_ratio + overhead

写入 50MB/s、保留 3 天、3 副本、压缩比 2，数据约 50×259200×3/2=19,440,000MB，约 19.44TB；还需索引、段和高水位余量。

计算应使用 Broker 实际落盘的压缩后字节率校准；若生产端上报的是压缩前大小，再除一次压缩比会低估容量。

三、时间与大小策略谁先触发

策略	触发	风险
时间保留	消息超过年龄	容量随流量波动
大小保留	分区超过字节	高峰缩短实际天数
日志压缩	按 key 保留较新值	不保完整历史
外部归档	转冷存储	重放链路复杂

多数 Broker 满足任一删除条件就可清理，必须核对产品语义。

四、Consumer Lag 与保留期

只看 lag 条数不够，消息大小和最老 lag 年龄更关键。消费者落后 2 天，而 Topic 保留 3 天，看似还有一天，但恢复速度若只比生产快 20%，可能来不及追上删除边界。

应告警“距离删除边界的剩余时间”，并在危险时扩容、降生产或延长保留。

五、压缩不是历史归档

Log compaction 保留每个 key 的较新值和 tombstone 语义，适合重建最新状态，不保证所有中间事件存在。订单状态审计若需要完整变更链，不能依赖压缩 Topic。

删除 tombstone 的时机还会影响离线消费者是否能看到删除事实，需要结合最大离线时间配置。

六、合规、归档与变更

个人数据可能要求到期删除，金融审计可能要求多年留存，两者应通过字段最小化、加密和分层归档同时满足。归档保存 Schema 版本、校验和、分区/offset 索引，并定期演练恢复。

延长保留先算未来峰值与 N-1 容量；缩短前确认所有消费组、DLQ 和重放任务，避免立即删掉尚需数据。

副本重建会同时占用磁盘和跨节点带宽，保留规划必须给修复过程留临时空间，不能把正常态水位长期顶在删除阈值附近。

七、常见误区与追问

• 误区：配置 7 天就一定保留满 7 天。 大小限制和磁盘保护可能更早删除。
• 误区：保留越久越安全。 成本、隐私和故障恢复时间都会上升。
• 误区：日志压缩等于永久历史。 它会清理同 key 的旧版本。
• 误区：只看 lag 条数即可。 字节和最老消息年龄同样关键。
• 追问：容量怎么算？ 字节率×秒数×副本数÷压缩比，再加开销余量。
• 追问：长期重放怎么办？ 冷存储归档并维护 Schema 与位置索引。
• 追问：何时允许缩短？ 所有消费与恢复需求确认后，经过审批和影响评估。

八、加强记忆

保留策略沿“最长故障窗口—追赶时间—容量公式—删除条件—合规归档”制定。时间和大小条件共同决定真实窗口，压缩只保状态不保全历史；用最老 lag 与删除边界监控，才能保证消费者真的来得及恢复。