Redis FCALL 怎么调用 Lua 函数：KEYS 参数、只读命令与脚本迁移边界

开发过程中用Redis调用Lua脚本，从旧版EVAL切到7.0以上的FCALL函数调用机制时，很容易在参数传递、多键访问、读写权限控制这几个环节踩坑，按照官方规则梳理清楚就能避开大部分常见问题。

调用FCALL时紧跟函数名的第一个整数参数就是numkeys，它会把排在它后面对应数量的参数划入Lua上下文的KEYS数组，其余剩下的所有参数自动划入ARGV数组；纯只读的Lua逻辑场景下，用FCALL_RO命令替代普通FCALL即可，集群环境下如果需要同时操作多个KEY，要提前确保所有键落在同一个哈希槽内，脚本才能正常执行。

把一段 Lua 逻辑从应用代码搬到 Redis Functions 后，调用方不再每次传脚本文本，而是通过函数名和参数调用。真正容易出错的地方不是 Lua 语法，而是 FCALL function numkeys key... arg... 这一行里，哪些参数会被 Redis 当成键名、集群为什么要求显式声明，以及只读函数为什么还需要注册标记。

先把 FCALL 的最小调用写对

Redis Functions 是 Redis 7.0 引入的服务端函数机制。函数属于一个库，库加载成功后，客户端只需要记住函数名。最小的无键函数可以这样调用：

FCALL knockknock 0

这里的 0 不是业务参数，而是键名数量。它后面没有键名，也没有普通参数，所以函数侧看到的 KEYS 和 ARGV 都为空。

一旦函数需要操作 Hash，就必须把键名放在 numkeys 划出的区域内：

FCALL user_touch 1 user:42 nickname Alice

函数里对应的是 KEYS[1] = "user:42"、ARGV[1] = "nickname"、ARGV[2] = "Alice"。如果误写成 FCALL user_touch 0 user:42 nickname Alice，Redis 不会替你猜哪个是键；这些值会全部落入 ARGV，而函数读取 KEYS[1] 时就会得到错误结果。

把函数注册成稳定的调用接口

实际部署时先加载带库名的 Lua 代码，再用 FCALL 调用注册函数：

#!lua name=profile_lib
redis.register_function{
  function_name = 'user_touch',
  callback = function(keys, args)
    redis.call('HSET', keys[1], args[1], args[2])
    return redis.call('HGET', keys[1], args[1])
  end
}

FUNCTION LOAD REPLACE "#!lua name=profile_lib
redis.register_function('user_touch', function(keys, args)
  redis.call('HSET', keys[1], args[1], args[2])
  return redis.call('HGET', keys[1], args[1])
end)"
FCALL user_touch 1 user:42 nickname Alice

成功的可见状态是：加载命令返回库名，调用返回 Alice，随后用 HGET user:42 nickname 可以再次读到相同值。库是整体更新单位，不能只替换其中一个函数；发布新版本时应把所有注册函数一起放进新的库内容中。

KEYS 和 ARGV 不是命名习惯，而是路由边界

Redis Cluster 需要提前知道函数会访问哪些键，才能把请求路由到正确节点。因此函数访问的每个键名都必须作为 KEYS 输入传入，不能把键名藏在普通参数里，也不要在函数内部拼接出未声明的键名。

FCALL transfer 2 account:{42}:cash account:{42}:ledger 15

这个写法把两个键都显式放进 KEYS，金额 15 放进 ARGV。两个键带有相同的 hash tag {42}，在集群中会落到同一个槽，适合做需要原子性的扣款与流水写入。若两个键不在同一槽，函数调用可能在集群路由阶段失败，不能靠 Lua 代码补救。

常见误区是把前缀写进函数：

-- 不建议：键名未作为输入显式提供
local key = 'account:' .. args[1]
redis.call('HGET', key, 'cash')

更稳妥的接口是由调用方传入完整键名，函数只消费 KEYS 中的键；业务 ID、字段名、阈值等非键数据放进 ARGV。这样代码审查、集群路由和测试输入都更清晰。

只读函数要同时满足两个条件

只读并不等于把调用命令改成 FCALL_RO 就结束了。默认情况下 Redis 假设注册函数可能写数据，因此只读调用需要函数注册时声明 no-writes，然后再用只读入口：

redis.register_function{
  function_name = 'user_snapshot',
  callback = function(keys, args)
    return redis.call('HMGET', keys[1], 'nickname', 'level')
  end,
  flags = { 'no-writes' }
}

FCALL_RO user_snapshot 1 user:42

验收时看两件事：函数没有调用写命令，且注册信息确实带有 no-writes。如果遗漏标记，Redis 会拒绝把它当只读函数运行；如果函数实际上会写入，却强行标为只读，则是接口设计错误，不应为了通过副本读取而掩盖它。

从 EVAL 迁移时别只替换命令名

EVAL 更像一次性提交脚本，脚本文本或脚本摘要由应用侧管理；Functions 则把逻辑作为库的一部分加载、持久化并复制。迁移时可以按下面的最小清单检查：

1. 把脚本入口改成库加载格式，并给每个公开函数取稳定名称。
2. 逐个盘点脚本访问的键，把键名放进 KEYS，业务参数放进 ARGV。
3. 确认多键调用的 hash tag 和槽位，不要把跨槽原子性当成函数特性。
4. 把纯读取函数注册为 no-writes，需要副本读取时再使用 FCALL_RO。
5. 在 Redis Cluster 的每个主节点完成库加载；集群不会替管理员自动把函数库加载到所有主节点。

上线前用一组小输入做验收

先用单键写函数验证 numkeys=1 的切分，再用两个带相同 hash tag 的键验证集群路由。随后故意把 numkeys 改成 0，确认测试能发现 KEYS 为空的问题；最后用只读函数调用 FCALL_RO，检查返回值和副本侧行为。

这组测试比只看“命令返回 OK”更有价值：它同时覆盖参数契约、原子性前提、只读声明和集群部署边界。函数执行期间会阻塞 Redis 的其他活动，函数体应保持短小；复杂计算或长循环不要直接塞进服务端函数。

相关问题

FCALL 的 numkeys 可以省略吗？

不可以。它决定后续参数如何划分为 KEYS 和 ARGV，即使函数不访问键，也应明确传入 0。

函数能不能在 Redis Cluster 中随意访问多个键？

不能。所有访问键都应显式传入，并满足集群路由要求；需要原子操作时，通常让相关键使用同一个 hash tag。

什么时候继续用 EVAL？

临时、低频且不值得作为服务端库维护的逻辑可以继续用 EVAL；需要稳定命名、复用、持久化和独立部署的逻辑更适合 Redis Functions。

小结

FCALL 的核心不是记住一条命令，而是把调用接口设计清楚：前面的 numkeys 划出全部键名，普通参数进入 ARGV，多键操作先满足同槽，纯读取函数再配合 no-writes 和 FCALL_RO。按这条边界迁移，Redis Functions 才能同时兼顾原子执行、集群路由和后续维护。