这道压力题我通常放在面试后半段：大促零点，监控显示两件事同时发生——某爆款超卖了 200 单（题设数字），支付页 P99 延迟从平时的几百毫秒涨到六秒，客服群已经开始刷屏。技术问你，先修哪个。
很多人会选卡顿，因为「用户体验」听起来更正当，而且六秒这个数字很刺眼。我一般会先追问：这两件事各自会造成什么后果，哪个还能补救。
本系列第 5/10 篇 · 上一篇：搜出三万件商品，排序听谁的 · 下一篇：退货率涨了，先别急着收紧政策
排序看的是「能不能撤回」
我用的判断标准很简单：先处理不可逆、且会向外产生承诺的事。
超卖意味着平台已经收了钱、承诺了发货，但货不存在。它往后会变成缺货赔付、投诉、平台处罚和商家纠纷，处理窗口过去之后，选项只剩赔钱和道歉。卡顿则是可恢复的体验损失：限流、排队、页面静态化都能把它压下去，用户等几秒还能回来，甚至大促期间大家对等一会儿有心理预期。
所以我的第一优先级是止住超卖继续扩大：把该商品的售卖入口关掉或转为预售/到货通知，冻结剩余库存的扣减，确认已生成订单的边界。同时让技术去压延迟，但不必等延迟恢复才动库存。
这里有个条件我期待候选人主动说：如果超卖只有两单，而支付页已经全面不可用、影响几十万用户，排序会反过来。判断不是背口诀，是量级和可逆性的比较。能说出这个反转条件的人，比直接给答案的人更让我放心。
还有一类容易被忘的不可逆：价格错了。标错价被批量下单，后果和超卖类似，甚至更麻烦。大促前我会要求把「一键下架」「一键关活动」「一键停发券」都做成可操作的开关，并且提前指定谁能按。
超卖不是数据库的一个 bug
追问到成因，我不期待候选人写分布式锁，但期待他知道库存是在哪几段之间丢的。
常见的断点有这么几处：缓存里的库存和数据库不一致，读的是旧值；下单预占与支付成功后实扣分两步，中间超时释放和支付回调撞车；多仓、多店铺共享同一份库存，聚合时各扣各的；秒杀商品和大促常规商品共用一个库存池；上游重试导致同一订单扣了两次。
产品侧能定的取舍是扣减时机。下单预占，用户不容易遇到「付了钱没货」，但要设计预占时长、超时释放、以及释放瞬间支付成功的冲突处理；支付成功后扣减，不超卖，却会让一批用户付完钱收到退款，这在体验上更伤。多数平台选预占，那就要把冲突当正常路径写进流程：以支付回调为准、库存不足时进入补偿队列、给用户确定的告知时限。
我会加一问：这 200 单里，哪些算真的超卖。未支付的不算，取消的不算，风控拦截的不算，跨仓可调拨的也许不算。先定义清楚统计口径，再谈赔付规模，否则补偿方案会按一个虚高的数字做，成本和公告口径全跟着错。
降级阶梯得在零点之前写好
大促的预案不是「多加机器」，是一张有触发条件、动作、决策人和回滚条件的 ladder。我要求它写进 PRD，而不是留在运维的脑子里。
| 级别 | 触发条件（示意） | 产品侧动作 | 谁可以按 |
|---|---|---|---|
| L1 | 支付 P99 超阈值持续 5 分钟 | 关闭非关键推荐与评价加载，商详静态化 | 值班产品 |
| L2 | 下单错误率继续上升 | 开启排队页、限流新会话、暂停发券 | 值班负责人 |
| L3 | 库存/价格出现不一致 | 关爆款入口、冻结活动价、切人工审核 | 产品 + 运营双签 |
| L4 | 大面积支付不可用 | 停止新下单，保留已支付订单查询与公告 | 值班指挥 |
表里最容易被省掉的是「谁可以按」和「按了看什么」。零点的会议室里最贵的成本是决策时间，等三级审批走完，二十分钟过去了。同样重要的是每一级的回滚条件——流量回落之后，谁把推荐和发券恢复，恢复前要确认哪些指标，别让降级状态一直挂到第二天上午。
还有一类纯产品的预案：排队页要显示预计等待和可退出路径，超时未支付订单要有明确提示，公告文案要提前备好模板。这些都是我在评审会上会逐条问的东西，因为它们决定了系统降级时用户看到的是「平台在有序处理」还是「页面白屏」。
补偿方案不是客服话术
止住之后是已产生订单的处理，我要求分档，而不是一句「联系用户协商」。
未支付订单：直接关闭，说明库存原因，给一张有时间窗的补偿券，注意别和仍在进行的活动叠加造成二次资损。
已支付、明确无货：按承诺时限告知，给「全额退款 + 补偿」和「换同价位商品」两个选项，别让用户自己去申请；涉及价差时，价格以订单快照为准。
可调拨或部分有货：优先履约给付款时间靠前的订单，其余走上面一档，规则要能解释、能审计。
对外口径和内部口径要一致：客服、公告、App 推送说的是同一个数字和同一个时限。我见过最伤信任的做法，是公告说「系统异常」，客服私下告诉用户「卖超了」，两边对不上，第二天就变成截图。
复盘那部分我会要求落到可验证的改动：压测是否覆盖了这个爆款的库存模型、预占时长是不是太长、上下游有没有对账、预案有没有在预演里真按过一次开关。大促预案不演练，等于没写。
我怎么听这道题
及格线是不慌，能按影响面和可逆性排优先级，知道先止血再修体验。
好一档会说清库存预占与实扣的取舍、超卖订单的统计口径、以及降级阶梯的触发阈值和决策人。
最强的一档通常多做两件事：把赔付和公告当成产品设计的一部分提前写好，以及指出这类事故的根因往往不在零点，而在几周前那次「为了赶活动把对账任务延后」的排期决定。
我收尾会问一句完全不技术的问题：明年大促，你会在需求评审上砍掉哪一件事。答「加机器」的我不置可否；答「砍掉两个临时加的营销玩法，留出压测和预案演练的时间」的，我会记下来。
评论