Redis FUNCTION DELETE 删除函数库后的调用失效处理

Redis FUNCTION DELETE 删除的是整个函数库以及库内全部函数。删除后，仍用原函数名发起的 FCALL 会找不到函数；处理办法是先确认目标实例、库名与原注册函数名，再从受控的完整库源码恢复。库已经不存在时，继续执行 DELETE 只会报错，不能恢复调用。

官方地址：https://redis.io/

以下命令适用于支持 Functions 的 Redis 7.0 及以上环境。示例用于解释语义，未在本文中实际执行；其中删除操作只针对独立测试实例里的演示库。生产恢复要使用自己的原始发布制品，不能拿演示代码覆盖业务库。

先确认被删除的是哪个库和哪些函数

先保护两类资产：服务端函数接口的可用性，以及可追溯的库源码。库名、函数名和应用版本应分别登记。例如库 service_meta 内注册了 svc_build_tag 和 svc_echo_label，删除该库会同时影响两个入口。应用调用时使用的是注册函数名，不是库名。

# 仅查询指定库；先确认 redis-cli 的连接配置确实指向故障实例
redis-cli FUNCTION LIST LIBRARYNAME service_meta

# WITHCODE 返回库源码，仅在受控终端保存，避免进入公开故障日志
redis-cli FUNCTION LIST LIBRARYNAME service_meta WITHCODE

重点看 library_name、functions 中的 name，需要源码时再取 library_code。查询不到库只说明当前目标没有这个匹配项，不能独立证明谁执行过删除。若已经删掉且没有源码，FUNCTION LIST 无法重新提供它，必须回到版本库或发布制品。

误删通常来自名称混用和发布权限过宽

最小删除写法只有 FUNCTION DELETE 库名。把函数名当成库名传入，可能得到库不存在错误；如果名称恰好对应另一个真实库，也可能删错对象。因此不要从错误消息里的函数名直接拼接删除命令。

另一种风险是业务账户同时持有调用和库管理权限。应用运行时原本只需要调用已部署函数，若还允许删除、加载或清空函数库，一段错误的清理逻辑就可能扩大影响。部署脚本还应约束目标实例与库名，避免把测试环境清理参数带到生产环境。

DELETE 的对象是函数库，不是业务键，也不是业务事务回滚。恢复库源码只能恢复函数定义，不能撤销函数此前已经完成的数据写入。不要为修复单库调用异常改用 FUNCTION FLUSH；那会扩大需要恢复的函数范围。

按错误现象区分恢复优先级

这些现象对应不同处理分支。尤其是函数不存在时，不应把失败当作普通网络波动无限重试；同一节点缺少定义期间，重试不会补回函数。对于可能写数据的业务调用，还要区分明确的函数未找到错误与网络超时：超时并不能证明业务逻辑没有执行，是否重试必须服从业务幂等设计。

用受控源码恢复函数库并收紧权限

下面是独立测试用的 service_meta.lua。首行声明库名，两个入口都不访问数据库键，便于只观察函数定义的存在性。它不是任何生产库的恢复文件。

#!lua name=service_meta
-- 固定版本标识，用于区分演示库制品
redis.register_function('svc_build_tag', function(keys, args)
    return 'demo-r1'
end)

-- 参数检查只服务演示，不读取或写入数据库键
redis.register_function('svc_echo_label', function(keys, args)
    if #args ~= 1 then
        return redis.error_reply('ERR label argument required')
    end
    return 'label:' .. args[1]
end)

在独立测试实例中，依次运行下列命令。沿用同一连接目标；实际有鉴权或 TLS 时使用所在环境的受控配置，不把密码拼进命令记录。

# 从文件读取完整源码，库不存在时加载它
redis-cli -x FUNCTION LOAD 

按示例定义，加载后的两个调用分别应返回 demo-r1 和 label:audit；删除后不能调用，重新加载后恢复。这些是语义上的预期现象，不是运行记录。

实际恢复时，先找回与应用版本匹配的完整库源码。若库确已不存在，使用普通 FUNCTION LOAD；如果同名库仍存在，则先比较制品和接口再决定是否使用 REPLACE。FUNCTION LOAD REPLACE 替换同名库，但不能解决与另一个库重复注册函数名的问题，也不能保证被替换库的接口保持兼容。

# 仅在确认需要替换当前同名库、且已保存其源码后使用
redis-cli -x FUNCTION LOAD REPLACE 

权限配置应把业务调用身份与库发布身份分开。Redis 7.0 起支持用竖线表达命令子项权限，例如 -function|delete。实际策略还要覆盖 LOAD、FLUSH、RESTORE 等库变更能力，并检查用户选择器和其他授权来源，不能仅凭一个拒绝规则就宣布隔离完成。业务身份所需的底层命令和键范围则按实际函数设计授予，避免直接放开整个 scripting 分类。

留下能定位节点与版本的变更记录

记录至少包含：变更操作者、目标环境、节点标识、库名、原注册函数清单、源码版本、新旧应用版本、命令成功或失败结果。错误记录保留原始错误文本与关联请求标识，但不记录密码、令牌、完整敏感参数或整份库源码。库名之外，还要保留恢复文件的制品标识，防止“同名恢复、逻辑不同”。

在 Redis Cluster 中，官方要求管理员把函数加载到各节点，不能假定在一个主节点恢复后其他主节点也具备同样的定义。应按当前部署拓扑列出承载请求的主节点，由发布工具逐个管理并记录结果；主从复制传播与跨主节点部署是不同范围。出现有时成功、有时失败时，把客户端实际路由节点与库清单关联起来，检查是否为节点间部署差异。

不要让每个业务请求在发现函数缺失时自行加载源码。这样会把发布权限扩散到应用，还会在并发恢复时引入版本竞争。恢复操作应由单一受控发布任务负责，业务侧只报告缺失和采取预先设计的失败处理。

恢复后还要核对什么

• 目标库存在，原注册函数名齐全，与当前应用调用名称一致。
• 恢复的是匹配应用的完整源码版本，同库其他函数也已纳入检查。
• 各相关节点的部署结果明确，业务观察没有继续出现函数缺失错误。
• 使用无副作用探针或隔离测试数据检查接口；带写入的调用另行考虑幂等与清理。
• 业务身份不能执行库变更命令，恢复制品与变更记录可追溯。

库不存在错误能直接忽略吗？

如果经过目标实例和库名确认，任务目的就是让该库不存在，发布工具可以把“已经不存在”记录为目标已满足。若业务仍依赖该库，忽略错误只会掩盖缺失；语法错误、权限不足和连接失败也不能被一并吞掉。

重新加载同名库，应用就一定恢复了吗？

不一定。库名一致不代表注册函数名、参数约定和返回结构一致，还要确认应用连接到的各节点确实已部署正确版本。

更换数据库编号能找回函数吗？

Functions 属于服务端管理的库资产，不是某个业务键。排障应核对实例、节点和库部署记录，不应把切换数据库编号当作恢复手段。

官方参考：FUNCTION DELETE、FUNCTION LIST、FUNCTION LOAD、FCALL、Functions 管理与集群、ACL 子命令权限。