Redis用Lua脚本防数据竞争，提升稳定性

Redis通过Lua脚本实现真正的原子性操作，从根本上解决高并发场景下“先查后改”导致的数据竞争与丢失问题——它并非依赖Lua的线程安全，而是由Redis单实例串行调度机制保障整个脚本作为不可分割的单元执行；相比WATCH+MULTI/EXEC的乐观锁在多key、复杂条件判断时重试成本高、逻辑难收敛，Lua将读、判、改压缩进一次无中间态的调用，显著提升数据一致性与系统稳定性；但需警惕阻塞命令禁用、用户输入注入风险、集群key路由限制、数值类型转换陷阱及EVALSHA因实例重启或主从不同步引发的NOSCRIPT异常，并始终牢记：Lua只负责Redis内部的原子性，跨系统事务需靠补偿或最终一致性兜底。

为什么 EVAL 要用原子性保证竞态安全

Redis 执行 Lua 脚本时，整个脚本在单个 Redis 实例的命令执行上下文中运行，不会被其他客户端请求打断。这不是“Lua 本身线程安全”，而是 Redis 主动把脚本当做一个不可分割的操作来调度——哪怕脚本里有 GET、INCR、SET 多步，也等价于一个原生命令。

常见错误是以为“先查再改”加个 WATCH 就够了，结果在高并发下仍丢数据：因为 WATCH + MULTI/EXEC 只对 key 级别乐观锁有效，一旦涉及多个 key 或条件判断（比如“余额 > 扣款额才扣”），失败重试成本高、逻辑难收敛；而 Lua 把判断和修改压进一次原子调用，没重试、没中间态。

• 脚本里不能调用阻塞命令（如 BLPOP），否则整个 Redis 实例卡住
• EVAL 的 script 参数必须是纯字符串，不能拼接用户输入，否则有注入风险（例如把用户传的 key 名直接插进 Lua 字符串）
• Redis 7.0+ 支持 FCALL 调用已注册函数，但首次仍需 EVAL 或 EVALSHA 加载，别漏掉缓存 hash 的同步逻辑

怎样写一个带条件扣减的 Lua 脚本（以库存扣减为例）

典型场景：扣库存前检查是否充足，充足则扣减并返回成功，否则返回失败。不能靠应用层两次 RTT（先 GET 再 DECR），网络延迟和并发会让判断失效。

正确做法是把“读-判-改”全放在 Lua 里，用 redis.call() 调用 Redis 命令：

if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then
  redis.call("DECRBY", KEYS[1], ARGV[1])
  return 1
else
  return 0
end

调用时用：EVAL "..." 1 stock:123 5，其中 KEYS[1] 是 stock:123，ARGV[1] 是扣减量 5。

• 所有 key 必须显式传入 KEYS 数组，Redis 集群模式下不支持脚本里硬编码 key（会路由失败）
• ARGV 是字符串数组，数值要用 tonumber() 转，否则比较会出错（比如 "10" > "2" 在 Lua 里是 false）
• 别在脚本里用 redis.pcall() 捕获异常来“兜底”，它只捕获 Redis 命令错误，不解决逻辑错误；该返回什么业务码，由脚本自己决定

EVALSHA 缓存脚本后为什么还会报 NOSCRIPT

用 SCRIPT LOAD 加载脚本得到 SHA1 值，再用 EVALSHA 调用，本意是省去每次传大段字符串。但线上常遇到 (error) NOSCRIPT No matching script. Please use EVAL.。

根本原因是：Redis 实例重启后脚本缓存清空；主从切换时从库没同步到脚本（尤其在旧版 Redis 中 SCRIPT LOAD 不写 AOF）；集群中不同节点没各自加载。

• 别假设 SCRIPT LOAD 一次就永久生效，每次调用 EVALSHA 前，必须做好 fallback 到 EVAL 的逻辑
• 应用启动时预加载常用脚本（用 SCRIPT LOAD），但得监听 Redis 连接断开事件，重连后重新加载
• 如果用连接池，注意不是每个连接都共享脚本缓存——Redis 脚本缓存是实例级的，只要连的是同一个 server 就行，不用每连接 load 一遍

本地开发调试 Lua 脚本的三个实际卡点

写完脚本不能直接扔生产，本地验证容易踩坑：语法没错，但语义或边界不对。

最有效的调试方式是用 redis-cli --eval 直连本地 Redis，配合 print() 输出中间值（注意：只有在 redis-cli 下 print() 才真输出到终端，生产环境用 redis.log() 会写日志但不可控）。

• print() 输出的内容不会作为脚本返回值，别指望靠它“看到结果”——返回值只能靠 return
• 测试时用 DEL 清掉测试 key，但别在脚本里写 redis.call("DEL", ...) 来“清理现场”，这会污染真实逻辑
• 时间相关逻辑（比如“过期前才能操作”）慎用 redis.call("TIME")，它返回的是 Redis 服务器时间，可能和应用服务器有偏移，且无法 mock

真正难的不是写对语法，而是想清楚“这个脚本在极端并发下是否仍满足业务不变量”。比如扣库存成功后发消息，消息发送失败要不要回滚？Lua 本身做不到跨系统事务，这部分得靠补偿或最终一致性设计——脚本只管 Redis 内的原子性，别让它背不该背的责任。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis用Lua脚本防数据竞争，提升稳定性》文章吧，也可关注golang学习网公众号了解相关技术文章。