Redis Lua脚本的原子性源于单线程串行执行，非加锁实现；脚本内所有redis.call()原子执行、不回滚；KEYS须显式声明以支持集群；严禁耗时操作，超时会阻塞主线程；错误不自动回滚，需客户端兜底。
Redis Lua脚本的原子性不是靠锁，而是靠单线程串行执行
Redis 执行 EVAL 或 EVALSHA 时，整个 Lua 脚本在服务端单个 Lua 解释器中一次性跑完，期间不会被其他客户端命令打断。这不是“加锁实现的原子性”，而是 Redis 事件循环模型天然决定的——命令排队、脚本独占执行窗口。
这意味着：哪怕脚本里调用了 10 次 redis.call("GET") 和 3 次 redis.call("SET")，它们作为一个整体要么全执行完，要么因错误中断（但已执行的部分不回滚）。
- 脚本内所有
redis.call()调用直接进内部执行队列，跳过网络解析和排队环节，延迟更低 - 不支持
print、os.time()、math.random()等标准库函数，调试需用redis.log() - 返回值类型要小心：
nil和false都会被转成 Redis 空回复，容易误判，建议统一用tonumber()或type()判断
KEYS 必须显式声明，否则集群模式直接报错
Redis 集群要求同一个脚本操作的所有 key 必须落在同一个 slot 上，而校验依赖你提前把 key 名通过 KEYS 数组传入。如果在脚本里拼接 key（比如 "user:" .. ARGV[1]），Redis 就无法预判 slot 分布，集群下抛 CROSSSLOT Keys in request don't hash to the same slot。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- ✅ 正确写法：
EVAL "return redis.call('GET', KEYS[1])" 1 user:1001——KEYS[1]明确声明了 key - ❌ 错误写法：
EVAL "local k = 'user:' .. ARGV[1]; return redis.call('GET', k)" 0 1001——KEYS为空，且 key 动态生成 -
ARGV可传任意字符串，适合数值、flag、JSON 序列化数据等，但不能替代KEYS做 key 名传递
别让脚本变慢，否则会阻塞整个 Redis
Lua 脚本一旦执行时间过长，就会卡住 Redis 的主线程，后续所有请求排队等待，严重时触发 SCRIPT_KILL 或超时断连。这不是并发问题，是资源独占导致的雪崩前兆。
- 禁止在脚本里做 for 循环遍历大量 key（如上万次
redis.call("HGETALL", ...)） - 避免字符串拼接、正则匹配、JSON 解析（Redis 内置 Lua 不带
cjson，硬加会拖慢且不可靠） - 所有耗时预处理（比如参数校验、格式转换、本地缓存 fallback）必须放在客户端，Lua 脚本只保留“读-算-写”三步轻量逻辑
- 用
lua-time-limit配置项设上限（默认 5 秒），超时自动终止，但最好从设计上杜绝超时可能
脚本出错不会回滚，得靠客户端兜底
Lua 脚本的“原子性”仅指执行过程不被中断，**不等于事务意义上的 ACID 回滚**。一旦脚本中途报错（比如 redis.call("INCRBY", "stock", -10) 导致负数），前面已执行的 GET 或 SET 不会撤销。
- 用
pcall()包裹关键段落，捕获异常并返回明确错误码，例如：local ok, res = pcall(redis.call, "DECRBY", KEYS[1], ARGV[1]) - 对库存、余额等敏感操作，建议脚本返回当前值或状态码（如
-1表示不足），由客户端判断是否重试或告警 - 高可靠场景（如支付扣款）需搭配异步对账：脚本只做快速预扣，最终一致性靠消息队列+DB 对账补偿
真正难的不是写对脚本，而是判断哪些逻辑该放进去、哪些必须挪到客户端——边界模糊的地方，往往就是线上事故的起点。
