Redis多key原子更新必须用Lua脚本，因MULTI/EXEC在集群下不支持跨slot操作，且无法实现条件判断；Lua脚本在服务端原子执行，需通过KEYS/ARGV传参、{}做hash tag对齐key，并避免动态拼接。
Redis 多 key 原子更新为什么必须用 Lua
因为 MULTI/EXEC 在 Redis 集群模式下不支持跨 slot 的多个 key，而单机版虽支持事务，但事务中的命令只是排队、不校验 key 是否存在或条件是否成立——比如“仅当 A=1 且 B>5 时才把 C 设为 10”，这种带逻辑判断的原子操作，MULTI/EXEC 做不了。EVAL 执行 Lua 脚本才是唯一可靠方式：脚本在服务端原子执行，中间不会被其他客户端打断，且能自由读写多个 key（只要它们在同一节点，集群下需用 {} 对 key 做 hash tag 对齐）。
Lua 脚本里怎么安全读写多个 key
必须显式把涉及的 key 作为 KEYS 参数传入，不能硬编码在脚本里（否则无法被 Redis 正确识别和路由）。脚本内通过 redis.call() 调用命令，失败会直接抛出异常并中断整个脚本。
-
KEYS[1],KEYS[2]对应调用时传入的 key 列表，顺序严格一致 -
ARGV[1],ARGV[2]传非 key 的参数（如数值、条件值），避免字符串拼接引入注入风险 - 所有 key 必须提前确定，不能用变量动态拼接 key 名（
redis.call("GET", "user:"..ARGV[1])是非法的，Redis 无法预判依赖哪些 key） - 读操作用
redis.call("GET", KEYS[1])，写操作同理；返回值可赋给 Lua 变量做判断
示例：仅当 balance ≥ 100 且 status 为 "active" 时，扣款并记录日志：
if redis.call("GET", KEYS[1]) >= ARGV[1] and redis.call("GET", KEYS[2]) == ARGV[2] then
redis.call("DECRBY", KEYS[1], ARGV[1])
redis.call("LPUSH", KEYS[3], ARGV[3])
return 1
else
return 0
end
集群环境下多 key 脚本执行失败的常见原因
报错 CROSSSLOT Keys in request don't hash to the same slot 就是典型信号——说明传入的多个 key 被分配到了不同 slot。Redis 集群强制要求一个请求的所有 key 必须落在同一分片上。
- 用
{}包裹 key 共同前缀，例如user:{123}:balance和user:{123}:status，确保 hash 计算只基于123 - 不要混用带 tag 和不带 tag 的 key（如
user:123:balance和user:{123}:status），hash 结果必然不同 - 客户端 SDK（如 Jedis、redis-py）调用
EVAL时，传入的KEYS数组长度必须与脚本中实际引用的 key 个数一致，少传会导致KEYS[n]为nil，调用失败 - 脚本超过 512 MB 或运行超时（默认 5 秒）会被强制终止，复杂逻辑建议拆解或加超时控制
本地调试 Lua 脚本的实用技巧
别等上线再试，用 redis-cli --eval 直连本地 Redis 快速验证：
redis-cli --eval update_balance.lua user:{123}:balance user:{123}:status user:{123}:log , 100 active "deduct_100"
注意逗号前后空格：逗号前是 KEYS，逗号后是 ARGV，且 ARGV 中含空格的字符串需加引号。调试时可在脚本开头加 redis.log(redis.LOG_WARNING, "debug: "..KEYS[1])，日志输出到 Redis 的 redis-server 控制台（需配置 loglevel warning）。
真正难的不是写对语法，而是想清楚哪些状态要一起读、哪些变更必须捆绑写——比如账户余额和冻结金额更新，漏掉一个就可能引发资金误差。Lua 脚本越短越好，逻辑尽量前置到应用层判断，只把真正需要原子性的核心步骤塞进去。
