登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Lua 与 Functions 选择怎么配置或排查

来源:17golang原创

时间:2026-09-13 10:16:01 177浏览 收藏

Redis 里的 Lua 脚本和 Functions 都能把一段逻辑放到数据附近执行,但它们解决的不是同一个维护问题。临时的、由应用版本一起发布的逻辑,通常从 EVALEVALSHA 开始;需要被多个客户端稳定调用、希望由 Redis 保存并复制的逻辑,更适合 Redis 7+ 的 Functions。两者都会原子执行,运行期间也会阻塞其他客户端,所以“能不能写”不是唯一判断标准。

官方地址:https://redis.io/docs/latest/

要点速览
  • Redis 6.2 及以下主要使用 Lua 脚本;Redis 7+ 才有 Functions。
  • 脚本缓存是易失的,遇到 NOSCRIPT 要重新加载,不能把 SHA 当成永久部署物。
  • Functions 以 library 和函数名为接口,更新时替换整个 library;慢逻辑仍会造成 BUSY

先按代码归属判断:一次调用还是数据库能力

Functions 并不是另一种 Lua 语法,而是 Redis 7 引入的服务端管理方式。EVAL 脚本被视为应用的一部分:客户端发送源码,或者先用 SCRIPT LOAD 得到 SHA1,再调用 EVALSHA。Functions 则先把 Lua library 加载进 Redis,随后客户端只依赖公开的函数名。

判断维度优先 Lua 脚本优先 Functions
生命周期随应用部署、短期实验或单个服务使用跨客户端长期复用
调用接口EVALSHA 与脚本摘要FCALL 与有意义的函数名
故障恢复应用负责重新加载缓存Redis 管理 library 的保存、复制与可用性
版本前提Redis 2.6+ 的脚本能力Redis 7.0+ 的 Functions

如果只是把一段条件更新封装在一次请求里,不必为了“新”而迁移;如果同一业务逻辑被多个语言客户端重复携带,Functions 能把维护边界收回 Redis。

Redis Lua EVAL 脚本与 Functions library、FCALL 调用边界的技术关系示意图
图1:操作示意图,左侧是应用持有的 EVAL/EVALSHA 脚本,右侧是 Redis 7+ 管理的 Functions library 与 FCALL 接口。

Lua 脚本怎么配置并排查 NOSCRIPT

脚本要参数化:key 放在 KEYS,普通输入放在 ARGV,不要在业务代码里不断拼接新的脚本文本。下面的示例把“设置一个值”作为最小骨架;注释解释的是部署意图,命令本身仍是操作示意。

# 先加载固定脚本,减少重复传输源码
SCRIPT='return redis.call("SET", KEYS[1], ARGV[1])'
SHA=$(redis-cli SCRIPT LOAD "$SCRIPT")

# 正常路径只发送摘要和参数
redis-cli EVALSHA "$SHA" 1 demo:status ready

# 重启、故障转移或 SCRIPT FLUSH 后可能出现 NOSCRIPT,重新加载源码
redis-cli EVAL "$SCRIPT" 1 demo:status ready

NOSCRIPT 说明当前节点的缓存里没有这个 SHA,不等于脚本语法错误。应用应在收到它时重新加载同一份源码并重试;在 pipeline 中不能假设后续请求能立刻处理这个错误,客户端通常需要回退到参数化的 EVAL

Functions 怎么加载,为什么排查重点不同

Functions 要先声明 library,并在 Lua 中注册至少一个入口函数。library 的源码以 shebang 提供引擎和名称;加载成功后使用函数名调用,而不是把整段源码再次发送给 Redis。

#!lua name=counterlib

-- 只把计数器的读取和递增封装成一个稳定入口
redis.register_function('add_count', function(keys, args)
    -- tonumber 让输入意图清楚,缺省值避免空参数变成非法运算
    local step = tonumber(args[1]) or 1
    return redis.call('INCRBY', keys[1], step)
end)
# 以整个 library 为单位加载或替换,不是只替换某一个函数
redis-cli -x FUNCTION LOAD REPLACE 

看到 ERR No functions registered,先检查 shebang、library 名称和 redis.register_function 是否存在。看到 ERR unknown command 'FCALL',先确认服务端版本与实际连接节点,而不是继续修改 Lua 代码。library 内容按整体更新,函数之间可以共享 library 内部代码,这正是 Functions 比散落脚本更适合长期维护的地方。

Redis Functions library 中的 add_count 注册函数与 FCALL 参数结构关系示意图
图2:结果示意图,展示 library、注册入口、KEYS/ARGV 参数和 FCALL 调用之间的静态关系,不代表本机真实执行结果。

配置或排查时,先看这张清单

现象第一检查点处理方向
NOSCRIPT脚本缓存是否被清空或节点是否变化重新加载同一源码,再调用摘要
No functions registeredlibrary 是否注册入口补齐 redis.register_function 后整体加载
CROSSSLOT声明的 key 是否落在不同槽位优先调整 key 设计,让一次调用落在同一槽位
BUSY循环和批量访问是否过长缩短逻辑;不要把超时阈值当成性能方案

脚本和 Functions 默认都应把执行时间控制在很短的范围内。Redis 到达脚本执行时间阈值后不会自动安全终止写入逻辑;读操作才可能被 SCRIPT KILLFUNCTION KILL 中断。生产排查先找无界循环、大批量 key 和跨槽设计,再考虑配置项。

最后用四个问题做取舍

这段逻辑是否只属于一个应用?是否需要多个客户端共享同一套业务接口?重启或故障转移后,是否希望 Redis 自己保留它?团队是否愿意把 library 的发布纳入 Redis 运维流程?前一个问题多数回答“是”,就先用参数化 Lua;后三个问题多数回答“是”,再考虑 Functions。

常见问题

EVALSHA 比 EVAL 更可靠吗?

它减少源码传输,但不改变脚本缓存的易失性。必须保留源码,并准备好处理 NOSCRIPT

Redis 7+ 还能继续使用 EVAL 吗?

可以。Functions 是面向长期管理的补充,不会要求已有脚本立即迁移。

Functions 会让慢脚本不再阻塞吗?

不会。Functions 仍在 Redis 服务端原子执行,长循环和大批量访问仍会阻塞其他客户端。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>