防住了超卖，却输给了“少卖”？

最新推荐文章于 2025-12-17 20:46:39 发布

原创最新推荐文章于 2025-12-17 20:46:39 发布 · 2k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#redis #java #安全

JavaWeb 专栏收录该内容

16 篇文章

订阅专栏

在这里插入图片描述

兄弟们，大家做电商或者秒杀系统时，第一反应防什么？肯定是**“超卖”**对吧？

毕竟，库存只有 100 个，结果卖出去 101 个，不仅要赔钱，搞不好还要被老板请去喝茶。于是我们搬出了 Redis，祭出了 Lua 脚本，觉得稳如老狗。

但你有没有想过，还有一种情况比超卖更让老板心痛？那就是——“少卖”。

少卖：库存明明显示扣掉了，Redis 里也没货了，但数据库里订单压根没生成！货烂在仓库里卖不出去，原本能赚的钱飞了。

今天我们就来扒一扒这个“少卖”是怎么发生的，顺便聊聊在订单支付环节，如何用状态机+乐观锁把并发问题治得服服帖帖。

库存到底什么时候扣？

在写代码之前，产品经理通常会跑过来问你一个哲学问题：“咱们是下单减库存，还是支付减库存？”

这不仅仅是技术实现的问题，更是业务体验的选择。我们先来看看这两种流派的爱恨情仇：

1. 支付减库存（Pay-to-Deduct）

逻辑：用户下单随便下，库存不改。只有当用户真正付完钱那一刻，才去扣库存。
优点：绝对不会产生“恶性占库存”的情况，卖出去的都是真金白银。
缺点：用户体验极差。想象一下，你双11抢到了手机，开开心心去付款，结果银行卡扣款时告诉你“没货了，退款吧”。用户绝对会炸毛。而且在并发高时，这会导致严重的超卖风险（因为大家都能下单）。

2. 下单减库存（Order-to-Deduct）

逻辑：用户只要下单成功，库存就锁住。
优点：用户体验好，只要下单成功，就一定能买到（除非他不付钱）。
缺点：容易被“恶作剧”或者“竞对”恶意刷单，把库存占满但不付款，导致真正想买的人买不到。

最终方案：Redis 预扣 + 数据库实扣

在高并发/秒杀场景下，我们通常采用折中方案：

下单阶段（Redis 预扣）：为了抗住流量，我们在 Redis 里进行库存扣减（也就是上面的“下单减库存”逻辑）。只要 Redis 扣成功，就告诉用户“抢到了”。
支付阶段（DB 实扣）：用户支付成功后，我们再异步或者同步地去扣减数据库里的真实库存。

这就引出了我们接下来的核心技术点——如何在 Redis 里安全地扣库存？

第一回合：Redis 挡在最前面（防超卖）

在秒杀场景下，直接怼数据库肯定是找死。通常我们会在 Redis 里做缓存扣减。

为了保证“查库存”和“扣库存”这两个动作中间不被别人插队，我们通常会用 Lua 脚本。这就好比你去买奶茶，店员看库存、收钱、给号这一套动作必须是一口气做完的，中间不能接电话。

Redis Lua 扣减脚本

-- KEYS[1]: 商品库存Key
-- ARGV[1]: 要购买的数量

local stock = tonumber(redis.call('get', KEYS[1]))
local amount = tonumber(ARGV[1])

if stock and stock >= amount then
    -- 库存充足
    redis.call('decrby', KEYS[1], amount)
    return 1 -- 成功
else
    return 0 -- 库存不足
end

利用 Redis 单线程执行 Lua 脚本的特性，我们完美解决了原子性问题，超卖？不存在的。

在这里插入图片描述

第二回合：隐秘的角落——“少卖”是怎么来的？

上面那步做完，Redis 库存是扣了，接下来我们要把订单落库。为了不把数据库打挂，我们通常是异步的。

问题就出在这个异步链路里。

正常流程 vs 少卖流程

结果就是： Redis 里的库存已经少了（被你扣了），但数据库里并没有生成订单。

这就像是你去买票，售票员把票撕下来给你留着（Redis库存-1），结果你付钱的时候断网了，人走了。这张票就被“锁死”在售票员手里，别人买不到，你也买不走。这就是“少卖”。

怎么解决？
除了保证 MQ 的可靠性投递（本地消息表、ACK机制），最稳妥的办法是引入**“库存回补”机制或者“对账”**。如果一定时间内订单没创建成功，要把 Redis 里的库存加回去。

第三回合：支付与关单的“生死时速”（状态机+乐观锁）

好，假设现在库存没问题，订单也生成了，状态是 PENDING（待支付）。

这时候，真正的并发大坑来了。

场景模拟：
用户小明在订单快超时（比如 30 分钟）的最后一秒，点击了支付。

线程 A（支付回调）： 收到银行通知，用户钱付了，要把订单改成 PAID。
线程 B（定时任务）： 巡逻发现这单 30 分钟没付钱，要把它改成 CLOSED（关单）并释放库存。

如果这两个线程同时执行，会发生什么？如果不加控制，可能出现：用户钱付了，订单却被关闭了。

解决方案：状态机 + 乐观锁

我们不能让订单状态随意跳转，必须按规矩办事。

1. 状态机设计（立规矩）

我们要定义好状态流转的方向，不能逆行。

2. 乐观锁实现（加版本号）

我们在更新数据库时，利用 SQL 的原子性做一个 CAS（Compare And Swap）操作。不要只是简单的 update，而是要带上前置条件。

Java 伪代码感受一下：

// 支付成功的处理逻辑
public boolean paySuccess(long orderId) {
    // 只有当前状态是 PENDING 的时候，才允许改成 PAID
    // 这里的 where status = 'PENDING' 就是乐观锁的精髓
    int rows = orderMapper.updateStatus(
        orderId, 
        "PAID",   // 目标状态
        "PENDING" // 期望的前置状态
    );
    
    if (rows == 1) {
        return true; // 支付状态更新成功
    } else {
        // 更新失败，说明订单可能已经被定时任务抢先关闭了！
        // 这时候应该发起退款逻辑，而不是强行改状态
        return false; 
    }
}

同理，定时关单的逻辑也是一样：

-- 只有在订单还是 PENDING 状态时，才允许改成 CLOSED
UPDATE orders 
SET status = 'CLOSED' 
WHERE id = 10086 AND status = 'PENDING';

谁先抢到谁赢：

如果是支付先到： 状态变为 PAID。稍后定时任务执行，发现 where status = 'PENDING' 不满足，更新 0 行，关单失败。（符合预期，用户支付成功）
如果是关单先到： 状态变为 CLOSED。稍后支付回调执行，发现 where status = 'PENDING' 不满足，更新 0 行。系统检测到更新失败，发起自动退款。（符合预期，避免了单子关了钱没退的尴尬）