Redis Lua 脚本封装库存扣减的原子边界

Redis Lua 可以把“读取库存、判断是否足够、扣减”放进一次原子执行，但这个边界只覆盖脚本内的 Redis 操作，不等于订单和支付也在同一事务里。我会把键名明确放进 KEYS，把扣减数量放进 ARGV，并把脚本限制成一次读取、一次有条件写入，不在 Redis 中运行完整业务流程。

这里选择一个商品一个字符串库存键的示例，讨论参数和耗时，不假称某次线上事故或压测已经验证了方案。官方入口：https://redis.io/docs/latest/。脚本和命令均为原创教学内容，本文没有实际连接 Redis 执行。

我会把 Lua 留给最小的条件更新

单独 DECRBY 本来就是原子命令，但它不表达“库存不足则不扣减”的完整条件。把 GET 和 DECRBY 分成两次客户端调用，又会在两次调用之间留下其他请求修改库存的机会。这个很短的条件更新，是我愿意交给 Lua 的部分。

我不愿把数据库下单、远程请求和长时间计算一起塞进去。脚本执行期间占用 Redis 的执行资源，调用次数变少并不表示系统代价消失。原子执行表达的是不被其他命令插入执行，不是运行时错误触发自动补偿或回滚。

KEYS 放键名，ARGV 放扣减数量

本例接口只有两个位置：KEYS[1] 是完整库存键名，ARGV[1] 是数量字符串。不要把商品编号传进 ARGV 后，在脚本里拼出另一个库存键；脚本访问的键应当由调用方明确提供。也不要把运行时商品值直接拼进 Lua 源码，参数变化不需要制造新脚本。

客户端直接调用 EVAL 时，脚本后面的 numkeys 决定后续多少个参数进入 KEYS；剩下的才进入 ARGV。下文的 redis-cli --eval 用逗号做分界，这是命令行工具的约定，不是 Lua 语法。

示例键使用 demo:stock:{sku42}。单键脚本不需要为多键槽位设计展开额外逻辑；如果以后增加去重键或日志键，就必须重新讨论集群同槽要求和失败路径，不能只改参数个数后继续沿用单键结论。

把检查放在唯一写操作之前

将下列脚本保存为 stock-decrement.lua。为了让示例容易推理，它只接受规范的非负整数库存，数量必须为正整数；库存上限为十亿，单次扣减上限为一百万。这是主动选择的示例业务范围，不是 Redis 整数存储能力的上限。

-- 只允许一个库存键和一个扣减数量，先固定调用契约。
if #KEYS ~= 1 or #ARGV ~= 1 then
    return redis.error_reply("ERR expected one key and one quantity")
end

-- 只接收规范的非负十进制串，主动缩小数值与输入长度范围。
local function bounded_uint(text, maximum)
    if type(text) ~= "string" or #text == 0 or #text > 10 then
        return nil
    end
    if not string.match(text, "^%d+$") then
        return nil
    end
    if #text > 1 and string.sub(text, 1, 1) == "0" then
        return nil
    end
    local value = tonumber(text)
    if not value or value > maximum then
        return nil
    end
    return value
end

local quantity = bounded_uint(ARGV[1], 1000000)
if not quantity or quantity == 0 then
    return redis.error_reply("ERR invalid quantity")
end

-- GET类型错误会在写入前返回；缺失库存单独表示，不能默认为可扣。
local raw = redis.call("GET", KEYS[1])
if not raw then
    return {-1, 0}
end
local stock = bounded_uint(raw, 1000000000)
if not stock then
    return redis.error_reply("ERR invalid stock")
end
if stock 

返回数组第一项为状态：1 表示成功，0 表示不足，-1 表示键不存在；第二项在成功时是剩余库存，在不足时是当前库存。缺失库存的第二项只是占位，不代表真实库存为零。参数或数据格式不符返回错误，不与库存不足混为一谈。

我更看重这段写法的边界清楚，而不是它看起来“功能很多”。检查都在写入前，成功路径只有最后一次 DECRBY。若键保存成列表等错误类型，GET 会报错并结束，此时还没有发生扣减。若以后在扣减之后再加其他命令，就必须重新分析部分写入风险，不能指望 redis.pcall 自动把之前的写入撤销。

数值范围刻意小于 Lua 浮点整数精度容易混淆的范围，同时拒绝指数、小数、负数和前导零等输入。它不是任意大整数库存方案；业务范围更大时需要重新设计数值表示，不能仅把上限常量改大。

脚本短，不代表可以忽略耗时

这段脚本没有循环扫描键，也没有返回整个集合；输入格式检查的长度有明确上限。它的 Redis 命令数量固定，但实际耗时仍受实例负载、数据大小和运行环境影响，不能在没有测量时承诺微秒级响应。

脚本运行时间阈值不是“到点自动回滚”。长脚本会影响实例可用性，SCRIPT KILL 也有未修改数据等限制。不要把它当作写脚本的普遍安全取消按钮，更不应通过调大阈值掩盖持续阻塞。

客户端超时又是另一件事：没有收到回复，不能推断服务器没有执行扣减。当前示例不记录请求标识，同样参数再执行一次，可能再次扣减。原子性与幂等性是两份契约，本文只实现前者的单键条件更新。

适合谁，以及我会保留的约束

这个方案适合能统一库存写入规则、只需短条件更新的调用方。若其他代码仍能直接写负库存或绕过约定，脚本不能替全系统维持一致规则；若业务需要跨数据库事务或请求去重，也不应把这个示例直接当成完整解法。

# 仅连接隔离的测试实例；初始化命令使用NX，避免覆盖已有键。
redis-cli SET 'demo:stock:{sku42}' 9 NX

# 只有初始化返回OK才继续；逗号两边分别是KEYS和ARGV。
redis-cli --eval stock-decrement.lua 'demo:stock:{sku42}' , 2

# 观察剩余库存；这些命令会真实写入测试数据，不用于生产库存。
redis-cli GET 'demo:stock:{sku42}'

在初始值为 9、且没有其他写入的隔离测试里，扣减 2 后应返回成功与剩余 7；这只是供读者核对的预期，不是本文运行输出。继续可用超过当前库存的数量观察不足分支，并检查值未改变。缺失、格式异常和错误类型应使用另外的测试键，不修改生产数据。

库存键不存在，能让 DECRBY 自动创建吗？本文策略不允许，缺失表示数据尚未准备好，而不是可以从零开始扣成负数。

EVALSHA 和 EVAL 会改变原子边界吗？不会因为传源码还是摘要而改变这段条件更新的设计；客户端还要正确处理脚本缓存缺失，但不要把缓存重载与网络超时后的业务重试混在一起。

能在脚本里遍历所有商品补库存吗？不建议沿用这个方案扩展。它的价值正是单键、固定参数、固定数量的命令；批量工作应另设有上限的任务设计。

参考：Redis 脚本的原子执行与参数化；EVAL 参数定义；Lua API 的调用与错误返回；DECRBY 整数扣减；redis-cli 的脚本文件调用方式。