论电商秒杀系统架构设计

在活动入口设计中，我们采用 CDN 与入口削峰来减少无效流量，满足秒杀开始阶段高并发访问和后端保护的要求

秒杀活动开始前后，用户会频繁刷新活动页面并集中点击购买，如果所有请求都直接进入后端交易服务，不但会造成网关和订单服务压力陡增，也会使大量无效请求占用核心处理资源

为解决这一问题，我们将活动页面、商品图片和规则说明等静态内容提前发布到 CDN 和缓存节点，用户浏览页面时尽量由边缘节点直接响应；对于必须进入后端的抢购请求，则通过 Spring Cloud Gateway 按用户、活动和接口维度进行限流，并对明显超过处理能力的请求返回排队或活动繁忙提示

为解决这一问题，我们将活动页面、商品图片和规则说明等静态内容提前发布到 CDN 和缓存节点，用户浏览页面时尽量由边缘节点直接响应；对于必须进入后端的抢购请求，则通过 Spring Cloud Gateway 按用户、活动和接口维度进行限流，并对明显超过处理能力的请求返回排队或活动繁忙提示

以用户进入活动页并点击抢购为例，浏览类请求大多命中 CDN 或前端缓存，真正进入交易链路的只有通过时间窗口、登录状态和活动资格校验的请求

通过 CDN 与入口削峰，系统把大量重复刷新和无效访问挡在核心链路之外，降低了后端服务在活动开始瞬间被冲垮的风险

在库存控制方面，我们采用 Redis 库存校验来减少数据库压力，满足低库存商品快速校验和防止超卖的要求

秒杀商品库存有限，如果每个抢购请求都直接访问 MySQL 扣减库存，大量并发写操作会集中到同一商品记录上，容易造成数据库锁等待、响应变慢甚至超卖风险

为解决这一问题，项目组在活动开始前将秒杀商品库存、活动状态和用户资格信息预热到 Redis，并使用原子操作或分布式锁控制库存预扣

具体运行时，请求进入后先校验活动状态、用户资格和缓存库存；库存不足或资格不符的请求直接返回结果，只有预扣成功的请求才进入后续订单处理流程

以某热门商品秒杀为例，系统先在 Redis 中完成库存余量判断和预扣，再把通过校验的请求送入订单处理流程，数据库只承担最终订单和库存结果的确认

通过 Redis 库存校验，秒杀阶段的数据库压力得到有效控制，也降低了高并发扣减库存时出现超卖和长时间等待的可能

在订单生成和后续处理方面，我们采用消息队列异步下单来实现削峰填谷，满足订单生成、支付确认和异常恢复的要求

用户通过库存预扣后，如果系统同步完成订单生成、支付引导、消息通知和运营统计等全部操作，用户请求会长时间等待，活动高峰期还会进一步放大服务压力

为解决这一问题，我们将通过库存预扣的请求写入 RocketMQ，由后台订单处理模块按照系统处理能力逐步生成订单，并通过 xxl-job 处理超时未支付和异常订单

具体运行时，用户抢购成功后先获得受理结果，订单模块随后消费消息生成订单并引导支付；如果订单生成失败或用户超时未支付，系统会释放预扣库存并记录处理状态

以用户抢购成功但迟迟未支付为例，定时任务发现订单超过支付时限后触发关闭处理，库存模块确认该订单的预扣记录未释放后再恢复库存，避免重复释放

通过消息队列异步下单，系统既能利用队列削峰填谷，又能保证秒杀结果可追溯、可恢复