题干与适用场景
你负责一个数据平台，接收用户行为事件并供多个消费者实时处理。流量平时平稳、活动期间突增，业务不能接受持续节流，但也不想为低谷预付过多容量。假设可以读取生产者吞吐、读取延迟、节流和消费者积压指标，并能在维护窗口切换容量模式。
面试官考察点
面试官关注你是否理解容量模式改变的是运营责任与成本模型，而不是交付语义。强回答会先用历史峰值和突发形状判断是否需要自动扩展，再核对单个分片的吞吐边界、消费者数量、重试与积压恢复；普通回答只说“流量波动就选按需”。
回答前需要澄清的问题
- 峰值持续多久，是否可预测？短促且不可预测的尖峰更适合自动管理容量。
- 写入和读取是否同时受限？写入、读取、记录数和消费者模型要分别测量。
- 是否存在严格的成本上限或容量预算？预算紧张且流量稳定时，预置模式更容易优化。
- 消费者是共享吞吐还是需要独占读取？多个消费者会改变读取侧的配额与成本。
- 是否允许切换期间短暂更新状态？切换与突发重试需要明确运行手册。
30 秒回答框架
“我先按小时统计写入 MB/s、记录数、读取 MB/s、积压和节流，区分可预测峰值与突发峰值。稳定且可预测的流量用预置容量并预留扩缩容窗口；不可预测尖峰用按需模式，但要验证自动扩展的爬升、成本和配额。无论选哪种，都以节流率、积压恢复时间、端到端延迟和月度成本做灰度验收。”
分步骤深入解答
- 建立容量基线。 将写入与读取按分钟聚合，标记 P50、P95、P99、峰值持续时间和热点分区键；平均值不能代表尖峰。
- 核对吞吐边界。 AWS 文档给出的默认分片上限是每秒写入 1 MB 或 1000 条记录、读取 2 MB；分别计算记录大小和批量请求带来的压力。
- 选择模式。 稳定负载可用预置模式配合扩缩容计划；负载变化快或难以预测时优先按需模式，并记录模式自动调整的延迟。
- 评估消费者。 共享读取、增强型扇出、重试和重复消费会影响读取配额；消费者积压必须纳入容量而非只看生产端。
- 建模成本。 对预置模式计算分片小时与扩缩容余量，对按需模式计算实际吞吐与峰值账单；把重放和突发双写列入情景。
- 灰度与回滚。 选择一个非关键流先切换，观察节流率、积压恢复、P99 延迟和月度成本；越过护栏时回到已验证模式并保留数据保序与重试策略。
替代方案包括拆分热点分区键、批量写入、降低事件大小、使用 Firehose 做缓冲，或为可预测活动提前扩容。容量模式不能修复分区键倾斜、慢消费者或无限重试。
高质量示范回答
“我会先查看过去 30 天每分钟写入与读取曲线，算出 P95/P99、峰值持续时间和分区键倾斜。按 AWS 的分片边界把记录大小折算为写入 MB/s 与记录数，再检查消费者共享吞吐和积压恢复。若峰值可预测且连续数小时，我会用预置容量加活动前扩容；若峰值短促且无法预测，我会用按需模式，但先在非关键流灰度，要求节流率低于 0.1%、积压恢复 p99 小于 5 分钟、端到端延迟不超过基线 20%，并设月度成本上限。任何模式都要监控热点分区和重复消费，否则换模式只会掩盖根因。”
常见错误
- 错误表现： 只用平均吞吐估算 → 失败原因： 尖峰和热点分区会造成局部节流 → 修正方法： 使用 P95/P99、峰值持续时间和分区键分析。
- 错误表现： 把按需模式当成无限吞吐 → 失败原因： 仍受服务配额和扩展过程影响 → 修正方法： 验证爬升、配额和突发测试。
- 错误表现： 只算生产端成本 → 失败原因： 消费者、重试和重放也会放大吞吐 → 修正方法： 建立端到端成本情景。
- 错误表现： 忽略数据语义 → 失败原因： 容量模式不改变至少一次投递和重复处理风险 → 修正方法： 保留幂等、检查点与积压恢复设计。
追问及应对
按需模式仍然节流，先调什么？
先区分总吞吐不足、热点分区键和单个消费者落后；检查写入记录数、分区键分布与扩展事件，再决定限流、重分区或增加消费者。
什么时候预置容量更便宜？
当写入和读取曲线稳定、峰值可提前安排且长期利用率高时，按分片小时和扩缩容余量建模；不要只比较单价。
活动流量翻十倍怎么办？
先验证按需模式的服务配额和历史爬升能力；对可预测活动提前扩容，设置生产者退避与消费者积压告警，并准备降级非关键事件的策略。
如何证明选型正确？
用灰度前后同口径比较节流率、积压恢复 p99、端到端延迟、重复率和月度成本；连续两个业务周期达标后再推广。