促销商品如何同步库存？

Question

在高并发促销场景下，如何保证商品库存的准确同步是一个核心难题。常见问题是：多个用户同时下单抢购同一促销商品时，由于缓存与数据库之间存在延迟，或分布式服务间数据不一致，导致超卖现象——即实际销量超过库存数量。此外，库存扣减操作若未加分布式锁或未采用原子操作，可能引发重复扣减或遗漏。特别是在秒杀活动中，瞬时流量激增，传统数据库读写压力剧增，进一步加剧库存同步延迟。如何通过Redis缓存预减库存、消息队列削峰填谷、数据库乐观锁或分布式锁机制，实现最终一致性与高性能的平衡，是系统设计的关键挑战。

Answer 1

高并发促销场景下商品库存准确同步的系统设计与实践

1. 问题背景与核心挑战

在大型电商平台的促销活动中，如“双11”、“618”等，瞬时流量可达百万级QPS。用户集中抢购有限数量的促销商品，极易引发库存超卖问题。超卖的根本原因在于：多个请求几乎同时读取相同库存值，在未完成扣减前均判断为“有库存”，从而导致重复下单。

典型问题包括：

• 缓存与数据库之间的延迟导致数据不一致
• 分布式服务间缺乏统一协调机制
• 库存扣减操作非原子性，易出现竞态条件
• 传统数据库在高并发写入时性能瓶颈明显
• 事务隔离级别设置不当引发幻读或脏读

2. 常见技术方案对比分析

方案	优点	缺点	适用场景
数据库悲观锁（SELECT FOR UPDATE）	强一致性保障	性能差，并发低	低并发、关键业务
数据库乐观锁（version机制）	高并发下性能较好	失败重试成本高	中等并发场景
Redis原子操作预减库存	高性能，毫秒级响应	需处理缓存穿透/雪崩	秒杀、高并发预扣
分布式锁（Redis/ZooKeeper）	控制临界区访问	复杂度高，存在死锁风险	资源竞争激烈场景
消息队列异步扣减（Kafka/RocketMQ）	削峰填谷，解耦系统	引入最终一致性延迟	订单创建后异步处理

3. 分层架构设计：从缓存到数据库的协同机制

采用“Redis + DB + MQ”三层架构实现库存精准控制：

1. 促销开始前将商品库存加载至Redis，使用INCRBY/DECRBY进行原子预扣
2. 前端请求先访问Redis判断是否还有库存
3. 预扣成功后生成订单并发送消息到MQ
4. 消费者从MQ拉取消息，异步执行数据库真实扣减
5. 定时任务校对Redis与DB库存差异，防止长期不一致
6. 异常订单触发回滚流程，释放Redis及DB库存
7. 使用Lua脚本保证Redis多命令的原子性
8. 结合限流组件（如Sentinel）防止恶意刷单
9. 启用缓存穿透保护（布隆过滤器）避免无效查询冲击DB
10. 通过TTL和降级策略应对Redis宕机情况

4. 核心代码示例：Redis预减库存的原子操作

-- Lua脚本确保原子性
local stock_key = KEYS[1]
local user_key = KEYS[2]
local required = tonumber(ARGV[1])
local uid = ARGV[2]

-- 检查是否已抢购过
if redis.call('SISMEMBER', user_key, uid) == 1 then
    return -1
end

local current_stock = tonumber(redis.call('GET', stock_key))
if not current_stock or current_stock < required then
    return 0
end

-- 原子扣减
redis.call('DECRBY', stock_key, required)
redis.call('SADD', user_key, uid)

return 1
    

5. 流程图：秒杀库存处理全流程

graph TD
            A[用户发起秒杀请求] --> B{Redis是否有库存?}
            B -- 否 --> C[返回“已售罄”]
            B -- 是 --> D[执行Lua脚本预减库存]
            D --> E{预减成功?}
            E -- 否 --> C
            E -- 是 --> F[检查是否已下单]
            F --> G[生成临时订单]
            G --> H[发送MQ消息]
            H --> I[MQ消费者扣减DB库存]
            I --> J{DB扣减成功?}
            J -- 是 --> K[更新订单状态为成功]
            J -- 否 --> L[触发库存回滚]
            L --> M[退还Redis库存]

6. 最终一致性保障机制

为解决Redis与数据库之间的数据不一致问题，需引入以下机制：

• 双写一致性：在订单落库后主动刷新缓存或删除旧缓存（Cache Aside Pattern）
• 异步补偿：通过定时Job比对Redis库存与DB实际销量，自动修复偏差
• 消息广播：利用Canal监听MySQL binlog，实时同步库存变更事件
• 幂等设计：所有库存变更接口必须支持幂等，防止重复消费造成误扣
• 监控告警：对库存负数、Redis过期等情况实时报警
• 灰度发布：新版本上线前通过小流量验证库存逻辑正确性
• 压测演练：定期模拟百万级并发测试库存系统的稳定性
• 降级预案：当Redis不可用时切换至数据库直接扣减模式
• 审计日志：记录每一次库存变更的操作人、时间、来源IP
• 容量规划：根据历史数据预测热点商品，提前扩容Redis集群