我不会直接画架构图，会先确认目标、规模和一致性要求。从流量削峰、库存预扣、异步下单、防超卖和容灾完整设计秒杀系统。秒杀系统的核心是把远大于库存的瞬时流量挡在核心链路之外，通过资格校验、限流和缓存快速失败，用 Redis 或专用库存服务原子预扣库存，再通过消息队列异步创建订单，并依靠唯一约束、幂等、超时释放和对账保证不超卖、不少卖与最终一致。

容量有了以后，再把入口、核心处理和数据落点串起来。 Redis Lua/Stream：预扣与待投递证据。 订单 UNIQUE(requestid)：最终不超卖裁决。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。阶跃百万请求并注入 Redis、MQ、消费者和关单故障，按 requestid 对账。

正常链路之外，还要设计失败补偿和可验证的恢复流程。高峰时 MQ 客户端超时，接口已扣 Redis 库存却没有订单事件。Lua 同时写待投递 Stream/状态记录，后台扫描补发；超过恢复窗口仍无订单的请求才幂等回补库存。 库存分桶后余量碎片导致少卖：边缘到库存各层淘汰率：失败请求尽早结束。 Redis 故障时全量降级到数据库：Redis Lua P99：预扣+事件可恢复记录。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「各层淘汰率」为主基线，记录值应满足「记录活动/稳态基线」；同时保存 边缘到库存各层淘汰率、Redis Lua P99，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。秒杀首先保证不超卖和核心链路存活，再通过补偿减少少卖；任何降级都不能把被挡住的洪峰直接转移到数据库。