Workerman实现秒杀库存异步扣减方法

秒杀场景下，单纯依赖数据库行锁扣减库存极易因高并发导致事务排队、锁等待和主从延迟而引发超卖或响应雪崩；本文提出基于 Workerman 常驻内存特性和 Redis 原子命令（如 DECR）的异步扣减方案——将资格判断前置到 Redis 内存层实现毫秒级原子校验，通过唯一索引、异步幂等落库与定时对账构建多层防护，既规避了进程间状态不一致问题，又保障了最终一致性，真正兼顾高性能、高可靠与可运维性。

秒杀库存扣减为什么不能直接用数据库行锁？

高并发下 UPDATE stock SET num = num - 1 WHERE id = 1 AND num > 0 看似安全，实际会因事务排队、锁等待、主从延迟导致超卖或响应飙升。Workerman 的常驻内存特性正好用来避开 DB 层的锁竞争，把“扣减资格判断”前置到内存中做。

• 扣减逻辑必须原子：不能靠 PHP 的 $stock--，要用 Atomic 或 Redis 的 DECR
• 库存初始值需双写：启动时从 DB 加载进内存，同时写入 Redis 作为权威源
• 扣减失败不等于业务失败：要区分「库存不足」和「系统异常」，后者需记录日志并允许重试

用 Workerman + Redis 实现原子扣减的最小可行路径

核心是把库存数存在 Redis 的 DECR 命令里，配合 INCR 回滚（如果后续校验失败），再异步落库。

• 启动时用 Redis::set('seckill:stock:123', 100) 初始化库存
• 用户请求到达 Worker 进程后，调用 $redis->decr('seckill:stock:123')
• 若返回值 ≥ 0，说明抢到了；若为 -1，说明已售罄
• 成功后立即发消息到队列（如 AMQP 或 Redis List），由单独消费者进程异步更新 MySQL 的 order 和 stock 表

注意：DECR 是 Redis 原生命令，天然原子，不需要 WATCH/MULTI，也不依赖 PHP 进程间同步。

Workerman 进程间库存状态怎么保持一致？

Workerman 默认多进程，每个进程都有独立内存，不能靠全局变量存库存。

• 绝对不要用 static $stock = 100 或 global $stock，进程 fork 后各自一份，互相不可见
• 必须依赖外部存储：Redis 是首选，Atomic 类只适合单机单进程场景（比如测试）
• 如果用 Atomic，仅限于「本地计数器」用途（如限流），不能替代库存主数据
• 多台服务器部署时，Redis 必须是同一实例，且 key 命名带业务前缀（如 seckill:stock:{goods_id}）

异步扣减后怎么防止超卖和重复下单？

Redis 扣减只是第一道闸门，后面还有三件事必须做：

• 订单生成必须走唯一索引：MySQL 的 user_id + goods_id 联合唯一键，避免重复插入
• 异步消费端要幂等：检查订单是否已存在，再决定是否插入；用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
• Redis 库存和 DB 库存要定期对账：比如每分钟跑一次脚本比对 seckill:stock:123 和 SELECT num FROM goods WHERE id = 123，差值大时告警
• 补单机制要预留接口：人工发现漏单时，能通过后台调用 SeckillService::forceDecr($goodsId) 手动扣减并补单

Redis 的 DECR 很快，但真正容易出问题的是异步链路断开、消费者 crash、或者 DB 写失败后没回滚 Redis —— 这些地方没日志、没监控，就等于没保护。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Workerman实现秒杀库存异步扣减方法》文章吧，也可关注golang学习网公众号了解相关技术文章。