Redis Function 怎样保存可复用的原子逻辑

如果一段库存扣减、配额校验或状态迁移逻辑需要被多个客户端重复调用，Redis 7 及以上可以把它写成 Lua Function，放进一个 Function library，再通过函数名调用。这样应用侧只依赖稳定的入口，不必每次携带脚本文本或管理脚本 SHA。

官方地址：https://redis.io/docs/latest/develop/programmability/functions-intro/

本文用一个“库存足够才扣减”的例子说明保存方式。示例只访问调用方显式传入的 key，函数保持短小；它是结构说明和命令示例，不代表本文已经在本机执行过。

Redis Function 为什么适合沉淀原子逻辑

我在拆分库存接口时最容易遇到的问题，是多个客户端各自维护一份 EVAL 字符串：代码能跑，但脚本版本、加载时机和错误处理分散在业务代码里。Function 的思路是先把逻辑作为数据库的一部分加载，再让客户端只调用一个命名入口。

这里的“原子”不是让慢逻辑变快，而是函数执行时 Redis 会阻塞其他服务器活动。因此它适合把一次短的读改写组合起来，不适合在函数里做长循环、等待网络或访问宿主机文件系统。

先写一个可复用的库存扣减函数

Function library 的第一行用 shebang 声明 Lua 引擎和库名，随后用 redis.register_function 注册入口。下面的函数接收一个库存 key 和一个扣减数量：库存不足返回 0，扣减成功返回 1。

#!lua name=stock_lib

-- 注册一个短小的库存扣减入口，所有变量都保持在函数局部。
redis.register_function{
  function_name = 'reserve_stock',
  callback = function(keys, args)
    -- keys[1] 是调用方显式传入的库存 key，args[1] 是扣减数量。
    local current = tonumber(redis.call('GET', keys[1]) or '-1')
    local required = tonumber(args[1])

    -- 非法数量或库存不足时不改数据，返回 0 表示未扣减。
    if not required or required 

把这段内容保存为 stock_lib.lua 后，用 FUNCTION LOAD 加载。开发环境迭代同名库时可以使用 REPLACE；生产发布则应把加载动作当作一次有记录的部署操作。

# 把 library 一次加载到 Redis；-x 从标准输入读取最后一个参数。
redis-cli -x FUNCTION LOAD REPLACE 

用 FCALL 传入 key 和业务参数

加载成功后，应用不需要再发送 Lua 源码，只调用函数名。FCALL 的第二个参数是 numkeys：它决定后面有多少个输入会被当作 key，剩余输入才进入普通参数。这个分界对单机和集群都重要，函数访问的每个 key 都要由调用方显式声明。

# 先准备一个库存 key；示例值表示还有 5 件库存。
redis-cli SET stock:sku-100 5

# 1 表示后面第一个输入是 key，2 是普通扣减数量。
redis-cli FCALL reserve_stock 1 stock:sku-100 2

# 再读回库存，预期得到 3；这只是读命令示例，不是本文的运行结果。
redis-cli GET stock:sku-100

在 Lua 回调中，Function 使用 keys 和 args 两个参数表，而不是临时脚本里的全局 KEYS、ARGV。把 key 名称误放进普通参数，或者在函数内部拼出未声明的 key，都会让调用契约变得不可靠，集群场景尤其容易出问题。

替换、兼容和性能边界怎么判断

• 版本：Redis Functions 从 Redis 7.0 起提供。低于这个版本的实例不能直接依赖 FUNCTION LOAD 和 FCALL。
• 替换：FUNCTION LOAD REPLACE 会按整个 library 更新，不能只替换其中一个函数；因此库内函数要一起考虑兼容性。
• 只读函数：只有确实不写数据的函数才考虑注册 no-writes 并配合 FCALL_RO；库存扣减函数不能标成只读。
• 执行时间：函数会阻塞 Redis 的其他活动，避免在其中做不可控的大循环。若逻辑已经很长，应先拆分数据范围和调用粒度。
• 沙箱：函数只能通过 Redis 提供的 API 处理 Redis 数据和输入参数，不要把它当成可以访问文件系统或网络的通用 Lua 运行时。

几个容易混淆的问题

Redis Function 和 EVALSHA 的主要区别是什么？

EVALSHA 依赖脚本缓存和客户端的 SHA 管理；Function 先以 library 形式加载，应用侧按命名函数调用。两者都可以提供原子执行，但 Function 更适合把可复用入口作为独立部署对象管理。

FCALL 的 numkeys 为什么不能随便写？

因为它决定参数从哪里开始由普通参数变成 key 名称。函数访问的 key 必须全部放在这个边界之前，并保持与回调中 keys 的位置一致；数量写错时，轻则读取错误对象，重则在集群中触发跨槽或路由问题。

落地时可以按“先写一个短 library、明确 key/参数契约、FUNCTION LOAD、FCALL、再用 FUNCTION LIST 检查”的顺序推进。真正需要关注的不是把更多代码塞进 Redis，而是让一个小而稳定的原子入口被多个客户端复用。