秒杀系统是分布式高并发架构的试金石。电商大促、限时抢购场景下，短时间涌入海量请求，瞬时 QPS 可达数十万甚至百万级别。本文由外向内逐层拆解完整架构，覆盖 流量拦截、限流、多级缓存、库存扣减、异步削峰 全链路方案，附带工程落地实践。
流量处理遵循前置拦截、层层过滤原则，尽可能在离用户更近的上层丢弃无效请求，避免请求穿透到后端业务与数据库。下方为六层架构的流量削减路径——百万 QPS 在抵达数据库前已被收敛至百级。
绝大多数秒杀活动页面（商品图片、活动静态页面、秒杀倒计时页面）属于静态资源。在这一层把羊毛党、爬虫、脚本请求直接挡掉，不进入业务网关。
将秒杀活动首页、商品静态信息部署至 CDN，用户直接访问边缘节点，不会到达源站，大幅降低源站压力。动态倒计时可以前端本地时间兜底，配合接口轻量同步。
通过 WAF 识别爬虫、高频刷接口、恶意脚本攻击：
请求通过外层防护后到达网关（Spring Cloud Gateway / Nginx），这一层核心做流量整形。秒杀不能简单粗暴直接拒绝流量，采用令牌桶算法平滑流量。
提前根据服务器承载能力设置最大 QPS；匀速发放令牌，只有拿到令牌的请求才能进入下游服务；超出容量的请求直接返回"活动火爆，请重试"。
秒杀场景下，商品基础信息、是否开启秒杀、剩余库存标记属于高频读、低频写数据，依靠多级缓存挡下海量查询请求。L1 本地缓存挡住进程内查询，L2 Redis 承担核心状态。
超卖是秒杀最致命问题。如果分开执行"查询库存 → 判断库存 → 扣减库存"，多线程并发下会出现竞态条件，最终库存扣多。解决方案：Lua 脚本原子执行。
Lua 脚本在 Redis 内部单线程执行，整条命令具备原子性，中间不会被其他命令打断。
执行成功仅代表具备下单资格，不代表订单创建完成。
Lua 脚本返回抢购成功后，不直接同步创建订单。同步创建订单会大量并发请求数据库，直接压垮 MySQL。改造为异步消费模式。
数据库是整个架构最薄弱环节。原则：能不查库就不查库。
五类高频踩坑场景，每一类都直接对应一次线上事故。规避的成本远低于复盘的成本。
一个秒杀请求从用户发起至最终订单生成的完整链路。整套架构通过流量层层削减，把百万 QPS 原始流量逐步收敛，最终仅有少量有效请求抵达数据库。