Redis Function避免重复加载逻辑

避免 Redis Function 重复加载，关键是把 FUNCTION LOAD 放进发布或环境初始化步骤，让业务请求只调用已经注册的函数。不要每个请求上传源码，也不要每个应用副本启动时都无条件替换同一个库。函数按名称调用，库则作为版本化发布物管理。

官方地址：https://redis.io/docs/latest/develop/programmability/functions-intro/，命令参考：https://redis.io/docs/latest/commands/function-load/。Redis Functions从Redis 7开始提供；下文给出原创Lua与调用片段，未在本机执行。

把任务拆成发布与调用两种操作

接入这种能力时，我会先把两个使用者分开：发布人员关心哪个库、哪个版本加载到了哪些节点；业务调用方关心函数名、参数和返回值。让二者共享一段“失败就重新加载”的逻辑，往往会使请求错误变成发布竞争。

可以把交互理解为两个独立操作。发布操作上传一个稳定库；调用操作提交键与普通参数。用户输入变化只影响调用参数，不应该产生一份新Lua源码。这样才能避免把用户ID、字段名或默认值拼入代码，导致每种输入都重新加载。

实现一个名称稳定的只读函数

示例读取Hash字段，不存在时返回调用方指定的默认文本。把下面内容保存为 profile_lookup_v1.lua，第一行必须是库声明，不能在它之前添加说明文字。库名是profile_lookup_v1，公开函数名则是profile_field_or_default_v1，二者不是同一个标识。

#!lua name=profile_lookup_v1
-- 保存为profile_lookup_v1.lua；库名和函数名是版本化发布标识。
local function field_or_default(keys, args)
    if #keys ~= 1 or #args ~= 2 then
        return redis.error_reply('ERR expected one key, field and fallback')
    end
    -- 所有访问键都来自keys，字段名和默认值来自普通参数。
    local value = redis.call('HGET', keys[1], args[1])
    if value == false then
        return args[2]
    end
    -- 空字符串是已有值，不应误当作字段缺失。
    return value
end

redis.register_function{
    function_name = 'profile_field_or_default_v1',
    callback = field_or_default,
    flags = {'no-writes'}
}

函数只接受一个键和两个普通参数，明确限制了调用契约。HGET在缺失字段时返回的Lua假值与空字符串不同，所以代码不会把已有空字符串覆盖成默认值。键若存在但不是Hash，会返回相应类型错误，不能把这种错误伪装成“没有昵称”。

no-writes标记声明它不写数据，因此可以使用FCALL_RO。这里不需要增加页面、组件或按钮：对调用者来说，清晰的函数名和错误含义就是接口体验。返回约定应写进客户端封装，而不是让每个调用点自行猜测。

让发布步骤加载业务请求只调用

# 发布步骤：仅在目标测试实例加载本次保存的Lua文件。
# -x 将标准输入作为最后一个参数，不在shell中拼接Lua源码。
redis-cli -x FUNCTION LOAD 

示例命令默认连接本地测试Redis；真实环境应使用项目已配置的连接与认证方式，避免把密码直接写入命令或脚本。若演示键不存在，调用按设计返回Guest；如果字段存在，则返回其原值。这是代码预期，不是实测回执。

第一次加载使用FUNCTION LOAD；重复提交已存在的库名会失败，不意味着需要每次加REPLACE。计划升级同名库时，REPLACE用于替换整个库，并不是只修改其中某个函数。它也不能解决另一个库已经占用相同公开函数名的问题。

发布任务应记录目标节点、版本和执行结果。库名带v1时，源码内容应保持该版本的发布约定；不兼容变更可以使用v2库及不同公开函数名，先部署新库再切换调用。应用副本扩容不应触发所有副本同时重装库。

设计可理解的失败与恢复状态

不要把任意异常都当作缺库，更不要在请求处理器里循环FUNCTION LOAD。发布权限与业务调用权限可以分开配置，业务账户无需为了调用一个函数而获得整套函数库管理权限。参数和错误记录也不要包含口令或敏感业务值。

如果确实需要自动恢复库，由单一受控发布任务负责，并在环境就绪前完成。应用自己维护一个“已经加载”布尔值并不可靠：它只属于一个进程，不知道Redis是否被替换，也不知道别的节点上是否有库。

多节点发布与常见问题

Redis会把已加载函数传播到副本；但Redis Cluster不会自动替你把库部署到所有独立分片，发布流程仍需覆盖各主节点及其复制关系。不要认为redis-cli的普通集群重定向选项能把一次加载自动广播到所有主节点。

函数可随Redis持久化与复制机制保存，不等于所有无持久化临时实例重启后都一定还在。全新缓存环境需要预置库，恢复备份也要包含相应函数状态。多键函数还要遵守集群键槽约束；本文只访问显式声明的一个键。

Functions能彻底消除执行成本吗？

不能。它减少反复上传与管理源码的需要，函数执行本身仍占用Redis执行时间。应限制输入规模和循环工作量，不要把耗时批处理搬进函数。

客户端断开连接后需要重新加载吗？

不因为这一次断开而需要。库位于服务端，不属于某条客户端连接。应依据环境生命周期处理部署，而不是按连接建立次数加载。

调用函数要携带库名吗？

FCALL或FCALL_RO传入的是公开函数名，后面是numkeys、键和普通参数。本例的1表示只有紧随其后的一个参数是键。

执行报错会自动回滚之前的写入吗？

不要把函数的原子执行误认为关系数据库事务回滚。本文函数只读；将来扩展为写入逻辑时，应先处理输入错误并设计失败语义，不依赖运行时异常撤销已发生的写操作。