redis 7.0 functions 替换 eval 失败主因是版本不达标、模块未加载或跨库/跨节点未同步;需确认≥7.0.0、module list含redis_function、按库加载并预热调用。

Redis 7.0 Functions 替换 EVAL 时,脚本加载失败报 ERR Unknown command 'FUNCTION'
说明:这个错误不是脚本写错了,而是 Redis 实例压根不支持 Functions 功能——它只在 7.0+ 启用,且默认开启,但你连的可能是旧版本服务,或者用了未启用模块的 Docker 镜像(比如某些 alpine 版本没编译 redis_function 模块)。
实操建议:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先确认版本:
redis-cli INFO server | grep redis_version,必须 ≥7.0.0 - 检查模块是否加载:
redis-cli MODULE LIST | grep function,应看到name:redis_function - Docker 用户注意:
redis:7-alpine有些小版本缺失 Functions 支持,换用redis:7.2或redis:7.2-bookworm更稳 - 云数据库(如阿里云、腾讯云)需确认控制台是否已升级到 7.0+ 并开启「函数功能」开关,部分厂商默认关闭
把老 EVAL 脚本改写成 FUNCTION LOAD 时,Lua 环境差异导致运行异常
说明:Functions 不再共享全局 Lua 状态,redis.call() 行为一致,但 redis.pcall() 错误结构变了;更重要的是,Functions 默认禁用 redis.log() 和 math.random(),且不能用 KEYS/ARGV 全局表——参数全靠显式传入。
实操建议:
- 别直接复制
EVAL "return redis.call('GET', KEYS[1])" 1 foo过去;改用:FUNCTION LOAD lua "redis.register_function('get_key', function(keys, args) return redis.call('GET', keys[1]) end)" -
keys和args是 table,不是数组索引从 1 开始的“伪数组”,但 Lua 里仍用keys[1]取第一个 key——这点和 EVAL 一样,容易误以为要改下标 - 若原脚本依赖
math.random(),得换成math.randomseed(redis.sha1hex(ARGV[1] or ''))再调用,否则报attempt to call a nil value - 调试时加
redis.log(redis.LOG_WARNING, 'debug: '..cjson.encode(keys)),但上线前删掉——Functions 的日志默认不输出到 slowlog,也不进 MONITOR
迁移后发现 FUNCTION LIST 返回空,或新函数调用报 ERR Unknown function
说明:Functions 是按库(database)隔离的,不是全局注册。你在 db 0 FUNCTION LOAD,却在 db 1 FCALL,就会找不到;另外,FUNCTION FLUSH 默认只清当前库,不是全实例。
实操建议:
- 所有
FCALL前,先SELECT到对应 db,或明确指定 db 连接(如 redis-py 的redis.Redis(db=1)) - 批量迁移时,用
FUNCTION LIST WITHCODE导出函数定义,再用FUNCTION LOAD逐库重载,别指望一次加载全库通用 - 集群模式下,Functions 必须在每个 shard 上单独
FUNCTION LOAD,官方不自动同步——漏掉某个节点,就会出现「有时能调、有时报错」的诡异现象 - CI/CD 中不要用
FUNCTION FLUSH清环境,改用FUNCTION DELETE <name></name>精确移除,避免误删其他服务部署的函数
性能对比:为什么 FCALL 比 EVAL 慢了 10%?
说明:Functions 引入了额外的沙箱校验、签名验证和上下文隔离,冷启动确实略慢;但真正影响大的是「首次调用」——后续 JIT 缓存生效后,差距基本消失。如果你压测看到持续慢,大概率是没预热或用了太小的 lua-time-limit。
实操建议:
- 上线前做一次预热:
FCALL myfunc 1 keyname跑几遍,让 LuaJIT 编译缓存就位 - 检查配置:
lua-time-limit默认 5000ms,Functions 对超时更敏感,若脚本含循环或大 key 扫描,可临时调高,但别关(0)——关了会失去中断保护 - 避免在 Functions 里做网络请求、文件读写、或调用阻塞命令(如
BLPOP),这些在 Functions 中被禁止,会直接报错,不是变慢 - 如果函数逻辑简单(比如只是
GET + INCR),EVAL 仍有轻微优势;但逻辑一复杂(分支多、嵌套深),Functions 的可维护性和 debug 能力远胜 EVAL,这时性能差异可以接受










