Redis Lua 脚本怎样保证读改写原子性

Redis 里最容易出现超卖的写法，是先用 GET 读库存，在客户端判断够不够，再用 DECRBY 扣减。两个命令之间可能插入另一个请求，两个客户端都读到“库存足够”，最后一起扣减。把检查和更新放进同一个 Lua 脚本，Redis 会在服务端连续执行整段脚本，其他命令不能插入这段执行过程，读改写才真正成为一个原子单元。

官方地址：https://redis.io/docs/latest/develop/programmability/eval-intro/

客户端读改写为什么不安全

先看旧写法：客户端执行 GET stock:sku:42，把结果拿回应用层；应用层判断库存大于等于本次数量后，再发送 DECRBY。问题不在单个命令，而在判断发生在 Redis 之外。请求 A 和请求 B 都可能在扣减前读到同一个旧值，随后分别执行更新。

Lua 的关键不是“把多条命令写在一段字符串里”，而是让 Redis 把这段脚本当作一次服务端执行单元。官方文档说明，脚本运行期间 Redis 会阻塞其他服务活动，因此脚本的效果要么尚未发生，要么已经完整发生。脚本必须短小，不能把网络调用、复杂循环或大量无关业务塞进来。

写一个原子扣减脚本

把库存键作为 KEYS[1]，把扣减量作为 ARGV[1]。脚本先读取并转成数字；库存不足返回 0，库存足够才执行 DECRBY，并返回 1 和扣减后的剩余值。检查、分支和更新都在同一个脚本边界内。

-- KEYS[1] 是库存键，ARGV[1] 是本次要扣减的数量
local stock = tonumber(redis.call('GET', KEYS[1]) or '0')
local amount = tonumber(ARGV[1])

-- 参数无效时直接返回错误，避免把错误输入当成扣减成功
if not amount or amount 

用 redis-cli 调用时，--eval 后先写脚本文件，再写键参数，逗号后写普通参数。这个分隔关系很重要：键名进入 KEYS，扣减量才进入 ARGV。

# 第一个参数是脚本文件，逗号前传入 KEYS，逗号后传入 ARGV
redis-cli --eval quota.lua stock:sku:42 , 3

从 EVAL 迁移到 EVALSHA

开发阶段可以直接用 EVAL 发送脚本文本。脚本稳定后，可先用 SCRIPT LOAD 把脚本放进 Redis 的脚本缓存，再用返回的 SHA1 调用 EVALSHA，这样重复请求不必反复传输同一份源码。参数仍然保持不变：键在前，业务参数在后。

# 先加载固定脚本，返回值是后续 EVALSHA 使用的 SHA1
redis-cli SCRIPT LOAD "$(cat quota.lua)"

# 使用脚本摘要执行，仍然显式传入键和普通参数
redis-cli EVALSHA  1 stock:sku:42 3

脚本缓存不是持久化数据。Redis 重启、主从故障切换或执行缓存清理后，EVALSHA 可能返回 NOSCRIPT。客户端应捕获这个错误，重新加载固定脚本，再重试一次；不要为每个请求动态拼出一份新脚本，否则会让脚本缓存持续膨胀。

迁移清单与常见误区

还要区分 Lua 与事务的职责。MULTI/EXEC 能按顺序执行排队命令，但客户端无法把“读到的值是否满足条件”直接变成事务内的服务端分支；使用 WATCH 则需要处理乐观锁失败和重试。需要把读取、判断、更新组合成一次服务端决策时，Lua 更直接。

迁移前先确认脚本只处理必要的键和参数，再固定返回协议；迁移后重点回归库存刚好足够、库存不足、数量非法、脚本缓存丢失和集群多键槽位这几类边界。这样保证的是业务决策的原子性，而不是替代幂等键、重复请求保护或整体业务事务。

常见问题

Lua 脚本执行时 Redis 会不会被其他客户端插入命令？

脚本执行期间不会插入其他命令，这正是读改写能够保持原子的原因。但脚本越长，其他请求等待越久，所以应把逻辑限制在短小、确定的服务端数据操作内。

为什么不能在脚本里自己拼接 Redis 键名？

脚本访问的键应该由调用方显式放入 KEYS。这让 Redis 和集群能够知道脚本涉及哪些键，也让脚本的输入边界清楚。

EVALSHA 返回 NOSCRIPT 后应该怎么办？

重新用固定源码执行 SCRIPT LOAD，拿到新的摘要后再调用 EVALSHA。不要把动态业务数据拼进脚本源码。