题目重点：处理奖励机制引发的高 QPS 故障，拆解短期恢复与长期容量设计。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 未给奖励类型/金额/请求量；先问有限库存、公平性、重复领取和不可丢失要求。
- 奖励查询、资格检查与实际发放是不同路径。
解题路线
- 故障中先看错误率、连接/线程池、数据库与重试量，暂停活动放量或启用准入，保护核心服务。不要只扩机器而任由客户端重试放大。
- 缓存只适合可接受陈旧的展示/规则，奖励余额与领取状态需原子约束。按(activity,user)唯一键或幂等记录防重复，库存扣减与领取落账在明确事务内。
- 入口限流、排队和背压控制下游，领取accepted/pending不是已经到账。worker重试使用同幂等键，过期资格和库存失败有最终状态。
- 容量按峰值和热点key设计，避免所有请求打同一库存行；可预分配库存但需要总量与回收协调。发布演练包括重复/超时/队列积压和恢复后的补偿。
手动走一遍
一次领奖超时，用户重试不能再发一份；查询应能读同一request状态。库存仅100却涌入百万次请求，先限制进入实际发放层，而非让数据库逐条拒绝。
规模与取舍
设入口λ、处理μ，λ>μ时积压约(λ−μ)t，队列必须有容量与等待期限；扩容受热点/数据库瓶颈限制。
易错点与追问
容易失分的边界
- 缓存发奖结果但没有事务幂等。
- accepted就承诺到账。
- 无限重试和无限队列。
继续深挖
- 如何保持公平而不过度同步？
- 故障恢复后怎样对账未决领取？
