Redis Lua脚本与Functions如何选择

我在给 Redis 增加服务端原子操作时，最容易纠结的不是 Lua 语法，而是“这段逻辑到底应该临时执行，还是成为 Redis 实例的一部分”。如果只是一次请求里的小计算，EVAL 或 EVALSHA 往往足够；如果逻辑要被多个服务稳定复用、需要明确发布和回滚，Redis Functions 更合适。

官方地址：https://redis.io/docs/latest/develop/

本文不把两者理解成“旧 API 和新 API”的简单替换，而是从生命周期、调用方式和发布责任出发做选择。一个实用判断是：变化在每次调用里，优先脚本；变化在版本发布里，优先 Functions。

先看生命周期差异

Lua 脚本通常通过 EVAL 发送源码，Redis 会按脚本内容计算 SHA1；后续可以用 EVALSHA 调用已经加载到脚本缓存中的版本。这个缓存服务于当前实例的执行入口，应用需要准备好“缓存未命中时重新加载”的处理。

Functions 则以库和函数为单位管理。客户端先用 FUNCTION LOAD 把带库名的 Lua 代码加载到 Redis，再通过 FCALL 调用库里的命名函数。它的重点是把逻辑变成一个有名字、可列举、可部署的服务端能力，而不是让每个调用方记住一段源码或 SHA。

两者都在 Redis 服务端原子执行，但“原子”不等于“生命周期相同”。脚本缓存和函数库应该分别纳入部署、重启、故障切换和回滚方案。

用 EVAL/EVALSHA 完成一次原子操作

适合脚本的场景通常具备三个特征：逻辑短小，调用频率高但复用边界不稳定；参数会决定脚本具体行为；应用可以接受脚本缓存丢失后重新加载。比如“只有库存足够才扣减并返回剩余量”，就是典型的单次原子判断。

# 第一次直接发送源码：KEYS[1] 是库存键，ARGV[1] 是扣减数量
redis-cli EVAL "local stock = tonumber(redis.call('GET', KEYS[1]) or '0'); local want = tonumber(ARGV[1]); if stock  1 counter:book 1

示例中的脚本只使用传入的键和参数，调用方不需要把业务键名硬编码在脚本里。实际客户端要处理 EVALSHA 的缓存未命中：可以在同一个发布流程中重新 SCRIPT LOAD，然后重试一次原子调用。

脚本方式的优点是上手快、调用入口直接；代价是脚本源码或 SHA 往往散落在应用发布物中，多个服务都需要维护相同的加载策略。只要脚本内容经常随业务变更，Functions 的集中管理优势就会变得明显。

用 FUNCTION LOAD/FCALL 管理可复用逻辑

Functions 更适合稳定的业务能力：函数有明确名字，多个客户端共享同一实现，部署时可以一次加载库并检查库是否存在。下面的 Lua 库包含一个名为 reserve 的函数，使用 redis.register_function 注册后才能被 FCALL 找到。

# 把函数放进名为 inventory_lib 的库；库名是部署和排查时的重要边界
redis-cli FUNCTION LOAD REPLACE "#!lua name=inventory_lib
redis.register_function('reserve', function(keys, args)
  -- 读取库存并拒绝负数扣减，保持检查和写入在 Redis 内完成
  local stock = tonumber(redis.call('GET', keys[1]) or '0')
  local want = tonumber(args[1])
  if stock 

FUNCTION LOAD REPLACE 适合明确的发布动作，但它不是“随便覆盖生产逻辑”的理由。库名、函数名和参数契约都应该像接口一样管理，发布前先确认调用方兼容，回滚时也要知道当前库由哪一版代码提供。

Redis Functions 会作为函数库管理，并支持复制和持久化语义；这让它更适合长期存在的服务端能力。但它仍然受 Redis 版本、集群部署方式、脚本执行时间和命令限制影响，不能因为用了 Functions 就省略容量和超时设计。

按场景做选择

我会先问四个问题：这段逻辑是否跨多个服务复用？是否需要集中发布？Redis 实例重启后是否希望逻辑仍然可直接调用？调用方是否能稳定依赖一个函数名和参数契约？答案越多是“是”，越偏向 Functions。

例如，限流、库存扣减、幂等判断这类逻辑如果只有一个服务使用，短脚本可以降低部署成本；同一套权限判断、订单状态推进或多步数据变换被多个服务调用时，命名 Functions 更容易形成统一入口。

建立上线与清理流程

无论选择哪种方式，都建议把加载和调用分开记录。脚本方案至少记录脚本内容对应的 SHA，并在缓存未命中时有明确回退；Functions 方案则在发布阶段检查库和函数是否存在，再让应用切换到新的函数契约。

# 脚本方案：应用启动或部署时预加载，避免首次业务请求承担加载抖动
SCRIPT_SHA=$(redis-cli SCRIPT LOAD "return redis.call('GET', KEYS[1])")

# Functions 方案：发布后确认目标库和函数，再交给业务调用
redis-cli FUNCTION LIST | grep inventory_lib
redis-cli FCALL reserve 1 stock:book 1

# 只在确认无调用方依赖时清理指定函数库，清理动作要进入发布记录
redis-cli FUNCTION DELETE inventory_lib

最后一条命令尤其要谨慎：Functions 的清理是部署动作，不是排障时随手执行的“刷新缓存”。如果需要替换逻辑，优先设计兼容函数名或明确的迁移窗口；如果只是脚本缓存丢失，则重新加载脚本，不要把函数库当作脚本缓存去清空。

常见问题

Redis Functions 能完全替代 EVAL 吗？

不能简单这样理解。一次性、调用时才确定的短逻辑用 EVAL 更直接；Functions 解决的是可命名、可复用和可部署的长期逻辑。

EVALSHA 找不到脚本时应该怎么办？

让客户端用同一份源码重新执行脚本加载，再重试原子调用；不要只把 SHA 换成另一个猜出来的值。

为什么函数库加载成功，应用仍然调用失败？

检查库名、函数名、键数量和参数契约是否一致，同时确认调用目标 Redis 实例和发布库的实例相同。

我的判断标准是什么？

把“逻辑是否稳定、是否跨服务复用、是否需要集中发布”放在第一位。不要单纯按 Lua 代码长短选，而要按生命周期和运维责任选。