Redis FUNCTION LOAD 如何做脚本版本切换：函数库替换与回滚验收

线上把一段 Lua 逻辑改成 Redis Function 后，最容易出问题的不是语法，而是发布顺序：新库还没验收，就用同名库覆盖；回滚时又只记得函数名，忘了 Redis 按“函数库”保存和替换。把加载、调用、核对、回退拆开，切换就能变成一组可复查的命令。

先用新库名完成加载和调用验收，确认函数结果后再用 FUNCTION LOAD REPLACE 覆盖同名库；如果替换后的结果不对，回滚的是完整旧库，而不是单个函数。

Redis FUNCTION LOAD 的风险，通常出在同名库覆盖

Redis 7 及以上可以用 Redis Functions 管理服务端 Lua 逻辑。与每次发送脚本的 EVAL 不同，函数属于一个命名库，加载后通过 FCALL 或 FCALL_RO 调用。官方命令的语法是 FUNCTION LOAD [REPLACE] function-code，其中 REPLACE 只表示替换同名库，并不表示可以只替换库里的一个函数。

线上看到“函数返回旧结果”时，先不要重复覆盖。先查库名、函数名和当前调用参数，这三项能把“没加载”“调用了别的函数”和“新库逻辑本身有问题”分开。

先做一次不覆盖的最小加载

把函数源码放在版本库中，例如下面的 mylib-v2.lua。shebang 中的 name=mylib_v2 是库名，函数通过 redis.register_function 注册。示例只读取订单状态并返回结果，方便验收。

#!lua name=mylib_v2

redis.register_function('order_status', function(keys, args)
    local status = redis.call('HGET', keys[1], 'status')
    if not status then
        return 'missing'
    end
    return status
end)

先执行不带 REPLACE 的加载。返回库名时，说明 Redis 接受了源码并完成了函数注册；如果报错，先修复 shebang、重复函数名或 Lua 语法，不要用 REPLACE 把问题盖过去。

FUNCTION LOAD "#!lua name=mylib_v2\nredis.register_function('order_status', function(keys, args) return redis.call('HGET', keys[1], 'status') or 'missing' end)"
FUNCTION LIST
FCALL order_status 1 order:1001

验收时看三件事：FUNCTION LIST 能看到 mylib_v2，FCALL 返回预期的 paid 或 missing，并且传入的 key 数量与函数代码中的 keys[1] 一致。

同名切换时，REPLACE 只放在已验证的发布动作里

如果业务固定调用的是 order_status，而旧库名也是 mylib，新源码应先在隔离库名或测试实例完成调用验证。确认结果后，再执行同名库的 FUNCTION LOAD REPLACE。注意：函数库是整体不可变的发布单元，不能只更新其中一个函数。

FUNCTION LOAD REPLACE "#!lua name=mylib\nredis.register_function('order_status', function(keys, args) return redis.call('HGET', keys[1], 'status') or 'missing' end)"
FUNCTION LIST
FCALL order_status 1 order:1001

替换后的检查要与替换前使用同一组测试 key 和参数。这样看到结果变化时，才知道是版本逻辑导致，而不是测试数据变化。函数执行会在 Redis 服务端保持原子性，同时阻塞其他服务端活动；函数体应保持短小，不能把网络等待或长循环塞进来。

失败时按完整函数库回滚

回滚前先保留旧库的完整源码，而不是只保存某一个注册函数。若新库已经替换成功但业务结果异常，使用旧源码重新加载同名库；如果只是测试库，可以先用 FUNCTION DELETE 清掉测试库，再按记录重新加载。

FUNCTION DELETE mylib_v2
FUNCTION LOAD "#!lua name=mylib\nredis.register_function('order_status', function(keys, args) return redis.call('HGET', keys[1], 'status') or 'missing' end)"
FUNCTION LIST
FCALL order_status 1 order:1001

回滚验收至少包括：库名仍是预期值，函数名仍可调用，已知订单返回旧版本的正确状态，未知订单仍返回 missing。不要在没有旧源码的情况下凭记忆手写一份“差不多”的函数，这会让回滚变成新的变更。

告警和复盘要看哪些信号

• 加载阶段：记录 FUNCTION LOAD 的返回值和库名，错误信息原样留存。
• 切换阶段：记录 FUNCTION LIST 的库名、函数名，以及一组固定测试 key 的 FCALL 结果。
• 运行阶段：关注函数调用错误和 Redis 延迟；函数逻辑越长，对其他客户端的阻塞越明显。
• 回滚阶段：确认旧库源码、加载时间和验证结果都有记录，避免下一次只能依赖线上现状。

相关问题

FUNCTION LOAD 不写 REPLACE 会覆盖旧库吗？

不会。同名库已经存在时，不带 REPLACE 会返回错误；只有明确带上 REPLACE 才会替换同名库。

可以只替换 Redis Functions 里的一个函数吗？

不可以把库当成可逐函数更新的集合。Redis Functions 按库整体加载和替换，相关函数需要一起发布。

FCALL 和 EVAL 应该怎么选？

需要长期管理、复用和随数据持久化的服务端逻辑时，可以评估 Redis Functions；一次性或仍处于试验阶段的逻辑则要单独评估 EVAL 的管理成本。

发布前最后一遍核对

把新旧函数库源码、库名、函数名和固定测试 key 一起放入变更记录。先加载、再 FUNCTION LIST、再 FCALL，结果稳定后才执行 REPLACE；如果结果异常，按完整旧库源码回滚并重复同一组调用验收。