如何实施一次秒杀活动

秒杀活动的难点在于应对高并发流量、防止库存超卖、保证系统稳定性和优化用户体验。为了达成以上目标，整个秒杀链路都需要进行优化：

一、前端限流防抖：减少无效请求发送

核心目标：从用户交互层过滤重复/无效请求，降低后端压力。
具体实现：

1. 按钮防抖： 用户点击秒杀按钮后，立即禁用按钮（如设置1秒内不可再次点击），防止短时间内重复提交（如手抖导致的连续点击）。
2. 前端限流：记录用户对单个商品的请求频率（如LocalStorage存储用户ID+商品ID的最近请求时间），限制每分钟最多发起5次请求，超过则提示“操作过频”。
3. 静态资源优化：秒杀页面的图片、文案等静态资源提前预加载到本地缓存，避免请求时额外加载资源导致的延迟。

二、Nginx负载均衡：请求分发与入口限流

核心目标：将请求均匀分发到应用集群，同时拦截超量请求。
具体实现：

1. 负载均衡策略
   • 采用“加权轮询”算法，将请求分发到多台应用服务器（根据服务器性能设置权重，性能高的服务器权重更高）。
   • 对热点商品（如10万级抢购商品）单独配置路由规则，将其请求定向到专用应用集群，避免影响其他商品。
2. 入口限流
   • 通过Nginx的limit_req模块设置全局限流阈值（如每秒10万请求），超过阈值的请求直接返回503或“系统繁忙”页面，不转发到应用层。

三、参数校验：过滤非法请求

核心目标：在业务逻辑处理前，验证请求的合法性，避免无效请求进入核心链路。
具体实现：

1. 基础参数校验
   • 校验商品ID是否存在、秒杀活动是否在有效期内（开始时间≤当前时间≤结束时间）、请求数量是否为1（秒杀通常限1件）。
2. 用户合法性校验
   • 校验用户是否在黑名单（如历史作弊用户）、是否已参与过该商品秒杀（通过Redis的Set结构存储user:seckill:{商品ID}，存在则拦截）。
3. 防篡改校验
   • 客户端请求时携带timestamp（时间戳）和sign（签名，如MD5(商品ID+用户ID+timestamp+密钥)），服务端验证签名有效性，防止伪造请求。

四、Redis预扣减库存：防超卖核心

核心目标：通过Redis快速判断库存是否充足并预扣减，避免直接操作数据库导致的性能瓶颈。
具体实现：

1. 库存预热
   • 秒杀开始前30分钟，将商品库存从数据库加载到Redis（如SET seckill:stock:{商品ID} 1000），确保秒杀时直接从Redis读取库存。
2. 原子化扣减
   • 使用Redis的DECR命令或Lua脚本实现“判断库存+扣减库存”的原子操作（避免并发下超卖）：

     -- KEYS[1] = 商品库存键，ARGV[1] = 扣减数量
     local stock = redis.call('get', KEYS[1])
     if not stock or tonumber(stock) < tonumber(ARGV[1]) then
         return 0  -- 库存不足
     end
     return redis.call('decrby', KEYS[1], ARGV[1])  -- 扣减库存并返回剩余数量

   • 若返回值≥0，说明预扣减成功；否则返回“库存不足”。

五、MQ排队下单：异步完成订单创建

核心目标：通过消费消息队列中的秒杀成功消息，异步完成订单创建和数据库库存扣减，保证数据一致性。
具体实现：

1. 消费端处理流程
   • 订单服务作为消费者，从消息队列中逐条拉取消息，按顺序处理：
     ① 数据库库存最终扣减：执行UPDATE product_stock SET stock = stock - 1 WHERE product_id = ? AND stock > 0（双重校验，防止Redis异常导致的超卖）。
     ② 创建订单：在订单表插入记录（状态为“待支付”），与库存扣减放在同一数据库事务中，确保原子性。
     ③ 发送通知：调用短信/推送服务，通知用户“秒杀成功，尽快支付”。
2. 消费限流
   • 限制消费端的处理速度（如每秒1000单），避免数据库压力过大；若消息堆积，可临时扩容消费端实例。

六、离线对账：确保Redis与数据库库存一致

核心目标：解决分布式系统中可能出现的库存数据不一致问题（如Redis扣减成功但数据库未扣减）。
具体实现：

1. 对账时机
   • 秒杀活动结束后1小时内，执行全量对账；日常每小时执行一次增量对账（针对仍在进行中的秒杀）。
2. 对账逻辑
   • 从Redis中读取商品剩余库存（GET seckill:stock:{商品ID}），与数据库product_stock表的库存进行对比。
   • 若不一致（如Redis库存 < 数据库库存），以数据库为准，修正Redis库存（SET seckill:stock:{商品ID} 数据库库存值），并记录差异日志（用于排查原因，如消息丢失、消费失败等）。
3. 异常处理
   • 对差异订单进行人工核查，若属于Redis误扣，则恢复用户秒杀资格；若属于数据库未扣减，则补扣库存并同步至Redis。