秒杀库存扣减不能仅靠数据库行锁，因高并发下事务排队、锁等待和主从延迟会导致超卖或响应飙升；应结合Redis原子操作（如DECR）前置判断资格，并通过唯一索引、异步幂等落库与定期对账保障最终一致性。
秒杀库存扣减为什么不能直接用数据库行锁？
高并发下 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 —— 这些地方没日志、没监控，就等于没保护。
