直接回答：秒杀的总思路是层层拦截、尽早拒绝：前端（按钮置灰、答题/验证码错峰）→ CDN/边缘（静态化商品页）→ 网关（限流、黑名单）→ 服务层（库存预减在 Redis 完成，DB 只承担最终一致）。库存正确性的标准方案：预热阶段把库存加载到 Redis，下单用 Lua 脚本原子执行"判断库存>0 则减一并记录"，扣减成功才发 MQ 异步创建订单；DB 侧最终扣减用 UPDATE ... SET stock = stock - 1 WHERE stock > 0 兜底防超卖。

展开解析：细节决定成败。超卖防线：Redis 原子扣减是第一道，DB 的条件更新是不可逾越的最后防线——两层之间 MQ 丢消息用对账任务兜底。少卖问题：Redis 减了但订单创建失败（用户未支付），要靠超时未支付自动回滚库存（延迟消息扫描订单状态）。流量整形：MQ 把瞬时百万下单摊平到 DB 能消化的小时级消费，排队页面（虚拟等候室）把用户体验从"502"变成"第 N 位排队"。热点问题：单商品库存 key 是天然热点——拆桶（库存拆 100 份到不同 key，总量控制稍复杂）或本地库存预分配。隔离原则：秒杀系统与主站资源隔离（独立集群、独立库），它的雪崩不能带走正常业务；活动结束记得资源回收与库存回流主链路。

追问方向：Redis 集群模式下 Lua 扣减的分片约束？如何设计幂等防重复下单？对账任务的频率与口径？

（约 470 字）