Redis Lua 原子扣减和过期 怎样处理

Redis 做库存、次数或临时额度扣减时，单独发送“读取—判断—写回—设置过期”四条命令，会在并发请求之间留下窗口。更稳妥的做法是把判断、DECRBY 和必要的 EXPIRE 放进一个 Lua 脚本，让 Redis 在同一脚本期间保持原子执行。

推荐把扣减量和初始 TTL 作为 ARGV 传入，把库存键作为 KEYS[1] 传入；首次成功创建 key 时设置过期，后续扣减保持原有 TTL，并用明确的返回码区分成功与库存不足。

适用范围：本文只讨论单 key 的 Redis Lua 原子扣减与过期，不延伸到跨槽事务、限流算法或库存补偿系统。

先把原子扣减的返回契约定下来

脚本先校验两个数值参数：扣减量必须大于 0，初始 TTL 也必须大于 0。这样可以把业务错误挡在数据写入之前。库存不存在时，本文把它视为库存不足；如果业务需要“首次自动建库存”，应由上游先写入初始库存，避免脚本凭空生成库存。

返回值建议保持稳定：-2 表示参数非法，-1 表示 key 不存在或库存不足，非负整数表示扣减后的剩余库存。客户端只处理这个契约，不要用一次 TTL 查询来推断扣减是否成功。

Lua 中怎样同时处理库存与 TTL

下面的脚本把库存键放在 KEYS[1]，扣减量放在 ARGV[1]，初始 TTL 放在 ARGV[2]。redis.call 遇到 Redis 命令错误会直接让脚本返回错误；因此参数校验和类型边界要先完成。

-- KEYS[1] 是库存键，ARGV 只承载业务参数
local stock_key = KEYS[1]
local delta = tonumber(ARGV[1])
local initial_ttl = tonumber(ARGV[2])

-- 先拦截非法扣减，避免把错误参数写入 Redis
if not delta or delta 

这里的关键不是把命令写得更短，而是让“读取当前库存、判断是否足够、扣减、补充过期”处在同一个脚本执行边界内。Redis 官方文档说明脚本执行期间服务器会阻塞其他活动，因此脚本应保持短小，不能在其中放慢操作或大范围遍历。

首次建 key 与重复扣减要分开判断

EXPIRE 默认会更新已有 TTL。若每次扣减都无条件执行 EXPIRE key seconds，连续请求会不断刷新倒计时，库存可能一直不自动清理。上面的做法先读取 TTL：返回 -1 代表 key 存在但没有过期时间，才补上初始 TTL；返回非负值则保持原倒计时。

如果业务语义是“每次成功扣减都延长有效期”，可以明确改成每次刷新，但这已经是滑动过期，不是固定过期。若需要更严格的条件更新，Redis 7 之后的 EXPIRE 还支持 NX、XX、GT、LT，应先确认目标 Redis 版本和客户端参数映射。

上线前怎样确认过期语义没有漂移

先确认脚本只访问通过 KEYS 声明的键，其他输入都放入 ARGV。这不仅让脚本契约清晰，也符合 Redis Cluster 对脚本键名的要求。再确认脚本返回值已被客户端映射：负值走业务拒绝或参数错误，非负值才进入订单或额度确认。

还要特别检查两种边界：扣减后剩余数量为 0 时是否仍需保留 key 直到 TTL 到期；以及脚本传入过期秒数为 0 或负数时是否提前返回。Redis 文档规定非正的过期时间会直接删除 key，事件语义也不同，因此不要把它当作“立即过期但仍保留 key”。

如果脚本通过 EVALSHA 调用，客户端需要处理 NOSCRIPT：脚本缓存可能因重启、故障转移或显式刷新而消失。生产代码应准备重新加载并重试一次，而不是把它误判为库存不足。

常见误区与处理清单

• 把读取、扣减和设置过期拆成多个客户端命令，导致并发窗口。
• 用 DECRBY 处理不存在的 key，结果得到负库存；应先判断存在性或由业务初始化。
• 每次扣减都刷新 TTL，把固定过期误写成滑动过期。
• 把所有参数都塞进 KEYS，或在脚本内部拼接动态键名，破坏 Cluster 的键声明。
• 忽略 NOSCRIPT，只部署脚本文本而没有准备缓存丢失后的加载路径。

相关问题

为什么不直接用 MULTI/EXEC？它能把命令排队后一次执行，但条件判断仍需要脚本表达；Lua 更适合把读取结果直接用于后续判断。

库存归零后应该删除 key 吗？取决于业务是否需要保留“已售罄”状态。若删除，应在脚本中明确处理，并重新定义下次请求的初始化规则。