Kafka Tiered Storage：面试如何设计本地与远端保留策略？

题干与适用场景

面试官可能会问：“如果 Kafka 主题需要保留多年历史数据，你会如何设计 Tiered Storage 的本地与远端保留策略？”

题目核心不是背一个配置名，而是解释日志段在本地层和远端层之间的生命周期。KIP-405 的模型保留 Kafka broker 上的本地层，同时把完成的日志段上传到外部存储；本地保留时间或大小可以短于远端保留，以降低 broker 磁盘压力。回答还必须覆盖远端对象存储故障、历史读取延迟、删除责任和回滚路径。

面试官考察点

• 是否理解 tiered storage 是日志段级别的冷热分层，而非把 Kafka 直接变成对象存储。
• 是否能区分集群级能力、主题级 remote.storage.enable 和本地/远端保留策略。
• 是否能估算热数据磁盘、远端容量、上传滞后和历史读取带宽。
• 是否考虑远端存储不可用、元数据一致性、分区迁移和消费者重放。
• 是否明确远端数据删除的责任边界，避免误删或无限增长。

回答前需要澄清的问题

• 哪些主题需要远端历史，是否所有主题都启用？
• 热读延迟目标和历史回放吞吐是多少？
• 本地磁盘预算、远端存储类别、跨区域要求和合规保留期是什么？
• 远端对象存储故障时，生产、实时消费和历史消费分别如何降级？
• 删除策略按时间、大小、合规事件还是租户保留策略执行？

30 秒回答框架

可以这样回答：

我会把 Kafka 的本地层当作低延迟热缓存，把已完成日志段复制到远端层，再分别定义本地和远端保留。主题按需开启 remote.storage.enable，先用本地保留时间控制 broker 磁盘，再用远端保留满足审计和回放期限。设计中要量化上传滞后、远端读取延迟、对象存储故障和分区迁移，并明确远端对象由谁清理。实时消费走本地路径，历史重放接受额外延迟并设置限速和监控。

分步骤深入解答

先建立两层生命周期

Kafka 仍以分区日志段为基本单位。活跃段写入本地层；滚动完成后，远端日志管理组件把段及其索引信息写入配置的远端存储。客户端不应假设每个历史字节都还在 broker 本地磁盘：

producer -> leader broker local segment
                    | segment roll
                    v
             remote object store
consumer <---- local cache or remote fetch

本地层适合低延迟消费，远端层承担较长保留期。上传完成和本地删除之间需要可观测的安全窗口，不能以“对象已创建”就忽略索引或元数据状态。

用主题级开关控制范围

Apache Kafka 文档说明集群侧完成配置后，主题仍需通过 remote.storage.enable 选择是否使用 tiered storage。回答时应说明默认关闭或按主题启用的治理方式，避免把所有主题都迁移到远端而放大成本与故障面。

分离本地与远端保留

本地保留可以按时间或大小设为较小窗口，保证热数据和重平衡所需的读取能力；远端保留覆盖审计、回放和合规期限。两个窗口必须满足业务不变量：在远端上传确认、元数据可读和恢复演练通过之前，不能删除本地唯一副本。远端删除也要有独立审计和失败重试。

设计读路径与故障降级

实时消费者优先读取本地层，跨越本地窗口的 offset 触发远端读取。远端变慢时，限制历史回放并保护实时流量；远端不可用时，明确哪些 offset 暂不可读、如何告警和如何恢复。分区迁移、leader 变更和 broker 重启都应验证本地缓存与远端元数据的重建时间。

高质量示范回答

我先确认主题的热读窗口、历史回放吞吐、保留期和合规要求。架构上按 KIP-405 把 broker 本地层作为热缓存，日志段滚动后上传到远端对象存储；只有需要历史的主题开启 remote.storage.enable。本地保留按磁盘预算和实时重放需求设置，远端保留按审计期限设置，两者之间以“远端对象、索引和元数据可验证”为删除前置条件。消费者读取本地窗口时保持原有低延迟，超出窗口的回放走远端并限速，防止拖垮实时流。我要监控上传滞后、远端读取延迟、缓存命中、对象与元数据不一致、删除失败和不可读 offset，并演练对象存储故障、broker 重启和分区迁移。远端对象清理必须有明确 owner、审计和恢复流程，不能依赖 broker 磁盘删除自动完成。

常见错误

• 说 tiered storage 会把所有 Kafka 数据实时写入对象存储，忽略日志段滚动和本地热层。
• 只给集群级开关，不提主题级 remote.storage.enable。
• 只计算对象存储成本，不估算远端读取延迟、上传滞后和回放带宽。
• 认为删除 broker 本地文件会自动删除远端对象，忽略 KIP-405 的清理责任。
• 远端故障时让历史回放抢占实时消费资源。
• 没有对象、索引和远端元数据一致性的监控与恢复演练。

追问及应对

1. 本地保留时间应该如何确定？

从实时消费者最大回溯窗口、磁盘预算、重平衡恢复时间和故障期间的安全余量倒推。不要只按平均消费延迟设置；应覆盖峰值回放和 broker 维护窗口。

2. 远端对象存储短暂不可用怎么办？

暂停或限速跨窗口读取，保留本地可读范围并告警上传和读取失败。生产与实时消费继续按已验证的本地容量运行，远端恢复后再补偿历史读取；对不可读 offset 提供明确状态，不能伪造空数据。

3. 如何验证删除不会造成数据丢失？

在删除本地段前验证远端对象、索引和元数据可读取，并记录段范围。删除远端对象时执行保留策略审计、抽样读取和恢复演练；把删除失败、孤儿对象和元数据缺口纳入告警与定期盘点。