降级的本质：有损服务
服务降级的有损服务思想，在秒杀场景被放大到极致：链路上没有组件永远可靠——Redis 会故障切换、MQ 会堆积、风控会超时——预案的目的不是不出故障，而是故障发生时损失可控、动作明确、切换够快。没有预案的秒杀活动，故障恢复靠的是现场临时写代码——那是把事故变成事故 Plus。
降级清单：每一项都要有触发条件与动作
把链路逐段过一遍，每一段写下三个字段：触发条件、降级动作、恢复条件。Redis 不可用（预扣失败率突增）→ 动作：入口切换到排队页模式，请求暂存不发预扣，同时告警抢修——活动暂停一分钟好过超卖一万件；MQ 堆积（消费延迟超阈值）→ 动作：收紧网关限流阈值，少放行，让消化能力追上——上游阀门是现成的降级工具；风控服务超时 → 动作：旁路放行加后置清算——风控慢了不能挡着真人下单，疑似黑产留给延迟核验兜底；支付回调延迟 → 动作：关单时间窗自动顺延，避免误关已支付订单。
// 预案不是文档，是配置中心里的开关
seckill:
degrade:
redis-unavailable-mode: QUEUE_PAGE # Redis 故障 -> 排队页
mq-backlog-threshold: 50000 # MQ 积压阈值
mq-backlog-action: TIGHTEN_GATEWAY # 触发动作：收紧网关
risk-timeout-mode: PASS_AND_REVIEW # 风控超时 -> 放行+后置清算
// 触发条件由监控指标自动判断，动作一键切换，恢复条件同样明确预案的三个等级
预案按影响面分级：P0 级——核心链路不可用，动作是暂停活动切排队页，宁可"今天先不抢了"也不能出超卖；P1 级——部分能力受损，动作是有损继续（旁路风控、收紧限流）；P2 级——指标劣化未损功能，动作是观察加微调。分级对应不同的决策人：P0 一线值班即可执行，P2 要值班负责人确认。预案的另一半是恢复条件——什么时候切回来、切回前要验证什么，没有恢复条件的降级就是永久降级。
体面的失败：页面与话术
兜底不光在系统层，还在体验层：排队页告诉用户"前面还有多少人"、售罄页明示"已抢完，可登记候补"、降级页说明"系统繁忙，稍后再试"——每一类失败都有一句对应的话术与一个去向。模糊的"系统错误"是舆情燃料，明确的"已售罄可候补"是体验设计。文案与开关一起进预案清单，别等出事再让客服现编。
预案写在演练里
大促前必须做一次预案演练：把 Redis 停掉、把 MQ 注入延迟、把风控掐断——演练验证的不是预案写得对不对，而是开关真的能切、动作真的生效、恢复真的干净。演练出的坑（开关没接、降级后幂等失效）在演练里暴露是彩排，在活动里暴露是事故。预案体系就绪后，还差最后一块：容量从哪来——全链路压测。
评论 (0)