从线上事故看订单系统库存扣减的幂等设计

订单系统的库存扣减是电商交易的核心环节，也是线上事故的高发区域。据统计，超过80%的订单异常与库存扣减的幂等失效有关。幂等设计一旦缺失，重复扣减、超卖、资金损失等问题就会接踵而至。因此，在订单系统架构中，库存扣减的幂等性必须作为第一优先级设计，而不是事后补救的优化项。

数据库乐观锁实现库存扣减幂等

数据库乐观锁是实现订单系统库存扣减幂等最基础且可靠的方式，但它在高并发下性能表现不佳。其核心思路是在库存表中增加版本号字段，每次扣减时检查版本号是否匹配，匹配则更新并递增版本号，否则重试。这种方式能保证在同一时刻只有一个线程成功扣减，从而避免超卖。但问题在于，当并发量较高时，大量线程会因为版本号冲突而重试，导致数据库连接池耗尽和响应时间飙升。因此，数据库乐观锁适用于低并发或对一致性要求极高的传统业务场景，例如B2B订单系统或少量SKU的实体商品交易。

-- 库存表增加版本号字段
ALTER TABLE inventory ADD COLUMN version INT DEFAULT 0;

-- 扣减库存并检查版本号
UPDATE inventory
SET stock = stock - 1, version = version + 1
WHERE id = ? AND stock > 0 AND version = ?;

上述SQL中，通过version = ?条件确保只有版本号匹配的线程能执行更新，同时stock > 0防止超卖。如果影响行数为0，则说明版本号冲突或库存不足，客户端需要重试或返回失败。据美团技术团队对订单系统的调研，单纯依赖数据库乐观锁的订单系统在双十一流量下，数据库锁冲突率超过30%，导致接口超时比例上升至15%，因此大型电商通常不会单独使用此方案。

Redis原子操作实现库存扣减幂等

Redis的原子操作配合Lua脚本，是订单系统应对高并发库存扣减的常用手段，它能在保证幂等的同时提供极高的吞吐量。通过Redis单线程模型保证命令的原子性，并结合库存预扣和回滚机制，可以实现无锁的幂等扣减。核心思路是：先使用DECRBY命令扣减库存，如果扣减后库存小于0则回滚，否则将扣减记录标记为成功。但需要注意，Redis的持久化机制可能导致数据丢失，因此通常需要与数据库进行最终一致性同步。

-- Lua脚本：原子扣减库存并返回结果
local stock = redis.call('GET', KEYS[1])
if not stock or tonumber(stock) < tonumber(ARGV[1]) then
    return 0  -- 库存不足
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1  -- 扣减成功

这段Lua脚本在Redis中原子执行，确保扣减逻辑的幂等性。订单系统在收到请求时，先执行该脚本，若返回0则直接拒绝；若返回1，则将订单信息异步写入数据库，最终通过补偿机制保证一致性。据阿里巴巴技术团队《万亿级订单系统架构》文章指出，Redis原子操作支撑了双十一期间每秒数十万次的库存扣减请求，峰值时系统可用性仍保持在99.99%以上。但该方案引入了一定的复杂性，如Redis宕机后需要从数据库恢复库存，且存在短暂的不一致窗口。

分布式锁方案及其适用场景

订单系统中使用分布式锁进行库存扣减，适用于对一致性要求极高但并发量相对可控的场景。分布式锁通过第三方协调者（如Redis或ZooKeeper）确保同一时刻只有一个服务实例操作库存，天然实现幂等。但分布式锁的引入会带来额外的网络开销和运维复杂度，且锁的粒度选择不当容易导致死锁或性能瓶颈。

// 使用Redisson实现分布式锁
RLock lock = redissonClient.getLock("inventory_lock_" + skuId);
try {
    if (lock.tryLock(5, 10, TimeUnit.SECONDS)) {
        // 执行库存扣减逻辑
        int stock = inventoryService.getStock(skuId);
        if (stock > 0) {
            inventoryService.decreaseStock(skuId, 1);
            orderService.createOrder(...);
        }
    }
} finally {
    lock.unlock();
}

上述代码中，锁的key是唯一SKU，保证同一商品的操作串行化。但分布式锁的缺点也很明显：锁的获取和释放需要多次网络往返，在高并发场景下会成为瓶颈。据Gartner报告显示，采用分布式锁的订单系统在每秒超过1万次请求时，锁竞争导致的平均延迟增加超过200ms。因此，分布式锁更适合资金安全敏感且并发量不高的业务，如金融交易或高价商品抢购。

三种方案对比与选型建议

在设计订单系统的库存扣减时，需要根据业务规模、一致性要求和硬件成本进行权衡。下表从几个关键维度对比三种方案：

从实际落地经验来看，大多数订单系统采用混合方案：Redis原子操作负责前置扣减库存，数据库乐观锁用于最终一致性校验，分布式锁仅用于特殊场景（如限量秒杀）。这种分层设计既保证了高并发下的性能，又通过数据库兜底确保了数据不会丢失。无论选择哪种方案，幂等性都是订单系统库存扣减的基石，任何忽视这一点的设计最终都会在线上事故中暴露出来。