Redis Functions 部署怎么验收：FUNCTION LOAD、FCALL 与重启恢复

线上库存接口偶尔出现“扣减成功但没有留下操作记录”的争议时，问题不一定在业务代码。把一段 Redis Lua 逻辑临时装进脚本缓存，重启、故障转移或多客户端首次调用都可能让部署边界变得模糊。Redis Functions 的思路是先把函数库作为数据库对象加载，再让客户端只依赖稳定的函数名调用。

从临时脚本到可验收的函数库

Redis Functions 最有价值的地方不是少写几行 Lua，而是把服务端逻辑从某个应用实例的启动流程里拿出来。函数库有自己的名称，函数有稳定的入口，库内容会随 Redis 数据一起持久化并复制到副本。这样，客户端不需要在每次连接时猜测“脚本是否已经装过”。

这也带来一个明确的运维责任：加载函数库是部署动作，不是业务请求的隐式副作用。发布前要知道库名、函数名、读写属性、涉及的键，以及重启后如何验收。

先做一个带边界的库存函数

示例函数把库存键和操作记录键都作为输入键，库存不足时返回明确结果，不在函数内部拼接新的键名。这里用 stock:{sku} 保存数量，用 stock-log:{sku} 保存最近一次扣减记录。

#!lua name=stock_lib

redis.register_function('reserve_stock', function(keys, args)
  local stock_key = keys[1]
  local log_key = keys[2]
  local amount = tonumber(args[1])
  local request_id = args[2]

  if not amount or amount 

代码中有两个容易被忽略的约束。第一，keys[1] 和 keys[2] 必须来自调用参数，而不是由函数根据 SKU 自己拼接；第二，函数在 Redis 内是原子运行的，但它会阻塞其他客户端，所以不要把网络访问、长循环或大批量遍历塞进去。

FUNCTION LOAD 成功不等于发布完成

把上面的内容保存为 stock_lib.lua 后，先在预发布实例加载。库声明必须从 #!lua name=stock_lib 开始，并且至少有一个 redis.register_function 入口。空库、重复函数名、Lua 编译错误都会在加载阶段暴露，这正是它比临时缓存更适合做部署门禁的原因。

redis-cli -h 127.0.0.1 -p 6379 FUNCTION LOAD "$(cat stock_lib.lua)"
redis-cli FUNCTION LIST stock_lib
redis-cli SET stock:sku-42 8
redis-cli FCALL reserve_stock 2 stock:sku-42 stock-log:sku-42 3 req-1001
redis-cli MGET stock:sku-42 stock-log:sku-42

期望看到库名 stock_lib、函数名 reserve_stock，调用返回 reserved 和剩余数量 5，最后一次读取能拿到 req-1001。如果把 2 改成 1，第二个键名会被当成普通参数，函数读取到的键就不再是预期对象；这类错误要在验收脚本里固定下来。

FCALL 的键名边界要和集群一起检查

FCALL function numkeys [key ...] [arg ...] 的第二个参数不是随便填的计数器。它告诉 Redis 后面有多少个键名，之后的内容才进入普通参数。单机上参数顺序错了可能只是得到错误结果，集群环境还会影响路由和跨槽判断。

因此，函数里访问的每一个键都应出现在调用的键名区域，并且同一业务对象的键最好使用同一个 hash tag，例如 stock:{sku-42} 与 stock-log:{sku-42}。不要让函数从数据库里的值拼出另一个未声明的键；这会让调用契约和集群可定位性都变差。

用替换和恢复演练证明升级可控

函数库不是逐个函数打补丁，而是以库为单位更新。新版本可以把返回值增加为 { 'reserved', left, request_id }，发布前先在预发布环境用 FUNCTION LIST stock_lib WITHCODE 核对源码，再用带 REPLACE 的加载动作替换同名库。调用方要先兼容新旧返回结构，不能把库替换和客户端切换绑成一个不可回退的动作。

恢复演练至少做两次核对：先确认库能被列出，再用固定库存数据调用一次。Redis 官方文档说明函数库会被持久化并复制，但这不意味着可以跳过故障转移验收；如果部署使用的是缓存型实例或特殊持久化策略，还要按实际运维方案确认函数库的保存方式。

redis-cli FUNCTION LIST stock_lib
redis-cli FCALL reserve_stock 2 stock:{sku-42} stock-log:{sku-42} 1 req-recovery
redis-cli GET stock:{sku-42}
redis-cli GET stock-log:{sku-42}

把这组命令放进发布后的验收脚本，分别在主实例重启、主从切换和新客户端连接后运行。验收重点不是“命令返回 OK”这一行，而是函数入口仍存在、库存只减少一次、记录键写入正确，错误参数不会意外扣库存。

常见问题

Redis Functions 从哪个版本开始可用？

官方文档将 Redis Functions 标记为 Redis Open Source 7.0.0 起可用。低于这个版本的实例不能按本文命令直接部署，应先核对升级路径。

为什么 FUNCTION LOAD 后还要运行 FUNCTION LIST？

加载返回库名只能证明加载请求通过，FUNCTION LIST 能进一步确认库名、入口函数和需要时的源码内容，适合作为发布门禁。

FCALL 的 numkeys 可以写成 0 吗？

可以，但前提是函数确实不访问 Redis 键。只要函数读写键，就应把所有键先列在 numkeys 后面，普通业务参数放在键名之后。

函数库能不能只更新其中一个函数？

不能按单个函数选择性替换，更新应以整个库为单位。建议给库内容做版本记录，先兼容调用方，再在维护窗口替换。

把验收结果留在发布记录里

Redis Functions 的稳定性来自清晰的部署契约：库名和函数名固定，键名显式传入，函数保持短小，替换按库执行，恢复用真实调用验证。把 FUNCTION LIST、一次成功调用、一次失败分支和重启后的复查结果写入发布记录，后续排查就不会只剩一句“Redis 里应该已经有脚本了”。