库存管理高并发实战：从MySQL行锁到Redis Lua脚本的架构演进

库存管理是电商、零售、供应链等众多系统的“心脏”，是连接用户、订单与商品的枢纽。它既不像“Hello World”那样基础，也不像“自研分布式数据库”那样高深，而是广大中高级工程师在业务开发与系统演进中必须攻克、且充满挑战的核心领域，兼具普适性与深度。

一、开篇：一个价值百万的“超卖”事故

深夜，报警短信像催命符一样轰炸着你的手机。“库存告急！”“订单量异常激增！”你冷汗直冒地打开监控，发现一款热门商品竟然卖出了库存量的200%。这不是业绩狂欢，而是一场灾难——超卖。无法发货的用户投诉、黄牛套利造成的资损、品牌商誉的崩塌……所有技术人都知道，库存管理是红线，但为什么这条红线如此容易被踩断？

许多人第一个想到的是：“在SQL里用 UPDATE stock SET quantity = quantity - 1 WHERE product_id = ? AND quantity > 0 不就行了吗？” 在低并发下，这确实有效。但在高并发、分布式部署的洪流下，这行简单的SQL会瞬间失效，因为它无法应对多个请求同时读到同一份“充足库存”的幻象。

本文将带你亲历一个库存模块的完整进化史。我们从最原始的单体应用起步，一步步剖析为何简单的方案会失败，如何权衡选型，最终如何落地一个既能抗住流量洪峰、又能严格保证数据一致性的分布式库存系统。这不仅是技术的迭代，更是一场关于严谨性、架构视野和权衡艺术的思维锻炼。

二、第一幕：单体时代的朴素坚守——数据库行锁

在项目初期，流量有限，系统单体部署。此时的库存管理，核心目标是正确性和快速实现。

方案：悲观锁（行锁）
我们直接在数据库层面，利用 SELECT ... FOR UPDATE（MySQL）或类似行锁机制，在事务内锁定要扣减的商品库存行。

BEGIN;
-- 关键步骤，使用FOR UPDATE锁定目标行，阻止其他并发事务修改
SELECT stock FROM inventory WHERE product_id = 123 FOR UPDATE;
-- 应用层判断库存是否充足
UPDATE inventory SET stock = stock - 1 WHERE product_id = 123;
COMMIT;

生活化类比： 这就像一家只有一个收银台的小卖部。每个顾客（请求）结账时，老板（数据库）会把对应商品的库存本（数据行）拿到柜台后面锁起来，算完账、修改好库存后才放回去。下一个顾客必须等待。这保证了绝对正确，但效率低下。

痛点浮现：

1. 性能瓶颈： 所有扣减串行化，商品成为热点，QPS天花板极低。
2. 数据库连接耗尽： 大量长事务持有锁，耗尽连接池，引发系统雪崩。
3. 不具备扩展性： 应用一旦集群部署，数据库行锁无法跨实例协调。

避坑指南： 在此阶段，最容易忽略的是锁的粒度。错误地对商品列表页进行 FOR UPDATE 查询，或忘记给 WHERE 条件加上索引，会导致表锁，灾难性地拖垮整个数据库。务必确保锁只作用于唯一索引的键上。

三、第二幕：寻求性能突破——读写分离与乐观锁

随着流量增长，我们引入缓存（如Redis）来承载读请求，数据库主写从读。库存扣减的写压力仍然在数据库。

方案演进：乐观锁（CAS - Compare And Set）
我们放弃物理锁，改用版本号或库存值本身作为“令牌”。

UPDATE inventory 
SET stock = stock - 1, version = version + 1
WHERE product_id = 123
AND version = #{oldVersion}; 
-- 核心的CAS操作，在更新时校验版本，防止基于旧数据的更新
-- 检查 affected_rows，如果为0，表示扣减失败（库存不足或版本冲突），需重试或返回失败。

选型权衡：

• 优点： 避免了长事务，数据库并发度提升。
• 缺点： 在高并发抢购场景下，大量请求的CAS操作会失败，需要频繁重试（在应用层或数据库连接层），给数据库带来巨大压力，且用户体验不佳（失败率高）。

此时，我们面临一个关键抉择：继续优化数据库，还是将核心扣减逻辑迁移出去？ 当QPS达到数千甚至更高，且业务要求毫秒级响应时，数据库（即使是分库分表后的主库）已然成为瓶颈。我们必须引入一个更快的“裁判”——分布式缓存 Redis。

四、第三幕：分布式架构下的核心战役——Redis登场

将库存扣减的主战场转移到Redis，是质的飞跃。Redis的内存操作性能极高，但其单线程模型和丰富的原子命令，为我们实现安全的扣减提供了可能。

1. 选型之争：预扣库存 vs. 实时扣减

• 预扣库存（购物车模式）： 用户下单时先预占库存，支付成功后转为真实扣减，失败则释放。优点是防止库存被未支付订单长期占用，体验好。复杂度在于状态的维护和超时释放（需要延时任务）。
• 实时扣减（秒杀模式）： 下单即真实扣减，后续环节失败再回滚。优点是逻辑简单直接，适合瞬时高并发。风险是回滚机制和资损控制。

我们以最经典、挑战最大的秒杀实时扣减为例，展开落地过程。

2. 第一版落地：Redis DECR 命令与判空

// 伪代码 - 问题版本
public boolean deductStock(Long productId) {
    String key = "stock:" + productId;
    // 问题1：非原子操作中的判断毫无意义
    Integer currentStock = redisTemplate.opsForValue().get(key);
    if (currentStock == null || currentStock <= 0) {
        return false;
    }
    // 问题2：DECR是原子的，但和上面的GET组合起来就不是了
    Long afterDecr = redisTemplate.opsForValue().decrement(key);
    return afterDecr >= 0;
}

致命缺陷： GET 和 DECR 之间的间隙，其他请求可能已修改库存。在高并发下，必然超卖。

3. 关键进化：Lua脚本——原子性的救世主
Redis Lua脚本将多个命令作为一个原子单元执行，是解决分布式库存一致性的关键。它完美契合了构建健壮的分布式系统对原子性和一致性的核心诉求。

-- 库存扣减Lua脚本
local key = KEYS[1] -- 库存键
local change = tonumber(ARGV[1]) -- 变化量，扣减时为负数，如-1
local current = redis.call('GET', key)
if (not current) then
    return -1 -- 库存键不存在
end
current = tonumber(current)
if (current + change < 0) then
    return 0 -- 库存不足，扣减失败
else
    redis.call('INCRBY', key, change) -- 原子性扣减
    -- 扣减成功后，可以发送事件或记录流水，这里是可扩展点
    -- redis.call('RPUSH', 'stock_record_queue', ...)
    return 1 -- 扣减成功
end

// Java中调用Lua脚本
private static final String DEDUCT_SCRIPT = "上述Lua脚本内容";
private static final DefaultRedisScript<Long> SCRIPT = new DefaultRedisScript<>(DEDUCT_SCRIPT, Long.class);

public boolean deductStock(Long productId, Integer quantity) {
    String key = "stock:" + productId;
    Long result = redisTemplate.execute(SCRIPT,
                                        Collections.singletonList(key), // KEYS
                                        -quantity); // ARGV
    return result != null && result == 1;
}

实战经验： 在一次大促压测中，我们最初使用了 WATCH/MULTI 事务。但在极端压力下，出现了大量乐观锁失败导致的订单提交失败。在将核心逻辑改为Lua脚本后，扣减成功率的曲线立刻变得平滑而稳定。教训： 在分布式协调中，能用一个原子操作完成的，绝不要拆成多个依赖外部协调的步骤。

五、一致性维护：架构的最终考验

将库存放在Redis，数据库怎么办？如何保证缓存与数据库的最终一致性？这是分布式库存系统稳定性的生命线。

核心策略：Redis为主，数据库为从（异步同步）
我们确立Redis为“权威数据源”（Source of Truth）进行实时扣减。数据库库存作为持久化副本和查询备份，通过异步消息同步。

// 1. 扣减成功后，发送异步消息
@Transactional(rollbackFor = Exception.class)
public void createOrder(Order order) {
    // 1. 调用上述Lua脚本扣减Redis库存
    boolean success = deductStock(order.getProductId(), order.getQuantity());
    if (!success) throw new RuntimeException("库存不足");

    // 2. 本地事务创建订单（状态为“待同步库存”）
    orderMapper.insert(order);

    // 在事务提交后，发送库存同步消息。若消息发送失败，有补偿机制。
    stockSyncEventPublisher.publish(new StockDeductEvent(order.getId(), ...));
}

// 2. 消息消费者：异步更新数据库库存
@EventListener
public void handleStockDeductEvent(StockDeductEvent event) {
    // 使用SQL：UPDATE inventory SET stock = stock - ? WHERE product_id = ?
    // 这里可以加入幂等性处理，防止消息重复消费导致多次扣减
    String idempotentKey = "stock_sync:" + event.getOrderId();
    if (redisTemplate.opsForValue().setIfAbsent(idempotentKey, "1", 1, TimeUnit.HOURS)) {
        inventoryService.syncStockToDatabase(event.getProductId(), event.getQuantity());
    }
}

面试官追问： “如果消息队列积压，数据库库存很久没更新，这时运营在后台基于数据库库存看到了不准确的数据并进行了补货操作，会有什么问题？如何解决？” （提示：这涉及到“多权威数据源”冲突，解决方案可以是：运营后台的库存查看也走Redis；或补货操作同样发送消息，由同一个消费者顺序处理，避免覆盖；或引入更复杂的版本合并机制）。

六、实战总结

1. 理解本质： 库存一致性本质是对共享资源的并发修改控制。在分布式下，需借助一个高性能的中央协调器（如Redis）和原子操作（如Lua脚本）来实现。
2. 迭代路径： 从数据库行锁（保证正确）-> 读写分离+乐观锁（提升并发）-> Redis Lua原子扣减（扛住峰值），是随着流量和架构复杂度演进的经典路径。
3. 核心方案： Redis Lua脚本是分布式实时扣减的黄金标准。务必用 SCRIPT LOAD 预加载，用 EVALSHA 执行以提升性能。
4. 一致性维护： 采用 “Redis主扣，异步同步至DB” 模式。通过事务后发消息+消费端幂等保证核心链路最终一致，通过定时对账修复极端不一致。
5. 配置是灵魂： Redis库存键的过期时间要长于最长的订单支付窗口；连接池、重试策略、消息队列的堆积监控，一个都不能少。

文中涉及的多种技术方案和架构思路，正是 云栈社区 开发者们经常探讨的核心话题。从数据库的锁机制到分布式缓存的应用，每一次技术选型背后都是对系统稳定性和性能的深度思考。希望这篇关于库存架构演进的梳理，能为你正在设计的系统提供有价值的参考。