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

Redis Function 和临时 Lua 脚本有什么部署区别

来源:17golang原创

时间:2026-09-07 09:21:30 326浏览 收藏

Redis Function 和临时 Lua 脚本都能把多条命令放到 Redis 服务端原子执行,但部署责任不同:Function 是 Redis 数据库的一部分,函数库会随持久化数据保存并复制;临时脚本属于应用侧源码,Redis 只保留易失的脚本缓存。需要跨重启、故障转移或多个应用复用时,优先考虑 Function;只在一个调用方里快速封装一段逻辑时,EVAL/EVALSHA 更轻量。

要点速览
  • Function 以 library 为发布单元,依赖 FCALL/FCALL_RO 调用,适合稳定的服务端 API。
  • EVALSHA 只是脚本缓存的 SHA1 入口,缓存丢失后必须用源码重新 SCRIPT LOAD。
  • 两者都会原子执行并阻塞 Redis,选择 Function 不代表可以写长时间运行的逻辑。

一、先看 Redis Function 和 EVAL 的生命周期差异

最容易混淆的是“脚本已经加载过”和“脚本已经部署到 Redis”并不是一回事。EVAL 执行的源码会进入脚本缓存,SCRIPT LOAD 也只是预加载;这个缓存不属于数据库数据,重启、主从切换或 SCRIPT FLUSH 都可能让它消失。应用若只保存 SHA1,不保存源码,下一次 EVALSHA 收到 NOSCRIPT 就无法自愈。

Function 的边界相反。它被装入命名 library,函数是库中的注册对象,Redis 会把函数作为数据库能力处理,随 RDB/AOF 保存并向副本复制。函数和脚本仍然都在服务端原子执行,执行期间会阻塞其他客户端,所以“持久化”解决的是部署和恢复问题,不会改变长脚本的阻塞风险。

Redis Function 与 EVAL 脚本在应用源码、函数库、数据库持久化和副本之间的静态部署边界
图1:看清应用源码、Function library、RDB/AOF 与副本的静态关系,判断逻辑由谁负责恢复。

二、Redis Function 怎么做库级发布与版本管理

把业务逻辑升级为 Function 后,建议将 Lua 源码放进应用仓库,用一次库级加载完成发布,再让各个客户端只依赖函数名。一个最小的库存扣减函数可以这样组织:

#!lua name=inventory_v1

-- 只让 Redis 通过 KEYS 和 ARGV 接收外部输入,避免把键名写死在函数里
local function reserve_stock(keys, args)
  local stock = redis.call('GET', keys[1])
  local amount = tonumber(args[1])
  if not stock or not amount or tonumber(stock) 

部署时用 FUNCTION LOAD 把完整库送入 Redis,发布后用 FUNCTION LIST 检查库名和函数名,再由客户端调用 FCALL reserve_stock 1 stock:sku-1 2。库内函数不能单独更新,版本变更应重新提交完整 library;这让发布记录更清晰,也提醒团队不要只在某一台节点手工改函数。

如果 Redis 只是缓存、没有把普通数据当作可靠持久化对象,仍要设计启动时的函数预加载。Redis 官方文档给出的方向是导出 functions-RDB,在启动阶段恢复函数,而不是把“缓存模式”误认为“函数自动永远存在”。

Redis Function library、reserve_stock、FCALL 客户端契约和 Redis 原子执行边界的静态关系
图2:函数库、函数名、FCALL 和原子执行边界共同构成稳定的服务端调用契约。

三、临时 Lua 脚本怎么处理 EVALSHA 失效

临时脚本适合变化快、复用范围小的逻辑。生产调用不要把一段动态拼接的 Lua 源码塞进每个请求,而是把固定源码随应用发布,并先 SCRIPT LOAD 得到 SHA1,正常路径调用 EVALSHA。遇到 NOSCRIPT 时重新加载同一份源码,再重试一次:

script_sha = SCRIPT_LOAD(script_source)

-- 正常请求只发送摘要和参数,减少重复传输
reply = EVALSHA(script_sha, key_count, keys, args)
if reply == NOSCRIPT then
  -- 缓存是易失的,使用仓库中的原始源码恢复
  script_sha = SCRIPT_LOAD(script_source)
  reply = EVALSHA(script_sha, key_count, keys, args)
end

这里的恢复逻辑要放在客户端封装层,不能让每个业务方法各写一份。还要避免运行时为每个订单拼出不同脚本,因为每个不同源码都会产生新的缓存条目;参数应该通过 KEYS 和 ARGV 传入。Redis 7.4 起脚本缓存还可能按策略清理,更不能把 SHA1 当作永久部署版本。

四、按部署压力选择方案

判断点Redis FunctionEVAL/EVALSHA
恢复与复制随函数库持久化、复制缓存易失,应用负责重载
发布单元完整 library单份脚本源码与 SHA1
调用方式FCALL,按函数名EVAL 或 EVALSHA
适合场景多应用共享、长期稳定的 Redis API单应用短逻辑、试验性或频繁变化逻辑

判断时先问三个问题:这段逻辑是否必须在重启后立即可用?是否有多个应用需要共享同一个服务端 API?是否愿意为整库替换建立发布流程?前两个答案为“是”时,Function 通常更稳;如果逻辑只服务一个调用方,且应用已经具备源码重载和 NOSCRIPT 处理,临时脚本并不低级。无论选哪种,都把脚本源码、键名约定、参数顺序和兼容策略放进版本库。

相关问题

Redis Function 能否只更新其中一个函数?

不要按单函数热改来设计。函数属于 library,发布时应提交完整库,并为库级变更保留版本记录。

EVALSHA 返回 NOSCRIPT 是数据丢失吗?

通常不是业务数据丢失,而是脚本缓存缺失。只要应用还保留原始源码,就可以 SCRIPT LOAD 后重新调用。

Function 和 Lua 脚本能否跨多个 Redis Cluster 分片键执行?

默认仍受集群键槽约束。应让相关键落在同一 hash slot,不要把 Function 当成绕过分片规则的工具。

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