日期：2026-09-27
标签：#面试 #场景设计 #消息队列 #Kafka
难度：简单
来源：牛面场景题
答案说明：独立整理（站内题目标记为 VIP，未读取会员答案）
一句话答案
当短时流入速率超过下游可持续处理速率、但业务允许等待时，用队列缓冲突发并按下游能力消费；同时必须设容量和过载边界。
面试口语版（约 60 秒）
典型例子是秒杀后的通知或订单后处理。入口瞬间每秒几千条，而数据库或第三方接口稳定只能处理更少，把请求全部同步压过去会超时甚至拖垮下游。可以先完成必要的资格校验与可靠入队，向用户返回“已受理”，消费者按可持续速率处理。设计前要估算峰值持续多久、会积压多少、多久能清完，再按磁盘、保留时间和业务时效设置限流与拒绝策略。队列只是把压力转成等待，不会创造处理能力；若长期平均流入仍大于处理能力，积压会一直增长。
原理与容量估算
flowchart LR
P[突发流量] --> G[限流与准入]
G --> Q[持久化队列]
Q --> W[受控消费者]
W --> D[数据库或下游]
Q --> M[积压量与最老消息年龄]设峰值流入速率为 A、下游处理速率为 C、峰值时长为 T；若 A > C，粗略新增积压 B ≈ (A − C) × T。峰值结束后正常流入 A₀ < C，预计清空时间约 B ÷ (C − A₀)。这些是稳态近似，实际还要按消息大小、重试、分区偏斜与下游性能波动留余量。
具体案例与失败分支
假设某活动 10 分钟内平均每秒产生 5,000 个可异步处理任务，下游稳定只能处理 1,000 个/秒，理论新增积压约 240 万条。之后正常流入 200 条/秒，若仍保持 1,000 条/秒处理能力，理论清理时间约 50 分钟。若业务只允许 10 分钟内完成，当前方案不满足目标：要提前扩下游、减少任务、调整活动入口速率，或改变承诺。若 Broker 存储逼近上限，应触发背压或拒绝新任务，不能让入队成功成为虚假的承诺。
取舍与易错点
- 适合允许异步完成的任务；支付授权、库存最后确认等通常需要同步或明确的状态机。
- Kafka 有保留策略与存储约束，不能想当然把它当无限容量缓冲池。
- 应同时看积压条数、积压字节、最老消息年龄与下游错误率；只看队列长度可能忽视超时。
- 消费并行度受分区数、同键顺序和下游承载力约束；扩大消费者数不一定提速。
面试官递进追问
- 削峰与解耦的区别？ 削峰关注速率差和排队时间；解耦关注调用依赖。
- 如何估算所需队列容量？ 按净流入差、峰值时长、消息大小和重试放大估算，再留故障余量。
- 长期流入大于消费能力怎么办？ 增加真实处理能力或限流、降级；排队本身无法解决。
自测
- 用 A、C、T 推出峰值积压公式，并解释为什么它只是近似值。
- 给一个需要“已受理”而非“已完成”的接口响应示例。
- 列出存储快满和消息即将过期时的处置动作。
参考资料
核对日期：2026-09-27。
Maintained by · YihuiEdit on GitHub