Redis Functions 如何在主从切换后保持脚本可用

Redis Functions 在主从切换后仍能调用，关键是把它当作数据库中的函数库发布，而不是把代码只留在客户端的脚本缓存里。用 FUNCTION LOAD 加载的库会进入 Redis 的持久化和复制边界，副本晋升后通常可以直接执行 FCALL；但 Redis Cluster 的每个主节点仍要分别准备函数库，异步复制也不等于业务数据强一致。

Redis Functions 为什么能跨主从切换继续调用

旧式 EVALSHA 依赖脚本缓存，重启、SCRIPT FLUSH 或故障转移都可能让缓存消失。Functions 则把多个函数放进一个有名字的 library，加载动作由 Redis 记录并复制。下面的库只用于说明发布形态：

#!lua name=order_lib

-- 以业务函数作为稳定入口，避免客户端拼接完整 Lua 脚本
redis.register_function('mark_ready', function(keys, args)
    -- 第一个 key 保存状态，参数保存要写入的值
    redis.call('HSET', keys[1], 'status', args[1])
    return 'OK'
end)

在主节点执行一次加载，再用 FCALL mark_ready 1 order:100 ready 调用。实际部署时应把整份 library 当作不可拆分的版本单元，更新时使用经过审核的 FUNCTION LOAD REPLACE，不要只修改某一个函数的片段。

发布时先把复制和持久化边界分开

在普通主从或 Sentinel 架构中，主节点加载的函数库会随复制流到达副本。切换后，副本成为新主，函数库通常仍在；不过 Redis 默认是异步复制，刚写入主节点的数据可能尚未到达被选中的副本。WAIT 可以等待若干副本确认，却不能把整个系统变成强一致系统。

切换后用什么顺序确认函数真的可用

不要一上来只看业务请求是否报错。先在新主节点确认库，再确认函数名，最后用一个不会破坏业务数据的测试 key 做调用。示例中的注释说明了每个命令的检查目的：

# 先看库和函数是否存在；输出只用于切换后的人工或自动门禁
redis-cli -h new-primary -p 6379 FUNCTION LIST

# 再查看当前角色与复制状态，确认客户端连到的是预期节点
redis-cli -h new-primary -p 6379 ROLE
redis-cli -h new-primary -p 6379 INFO replication

# 使用隔离 key 做一次 FCALL；1 表示后面有一个 key 名
redis-cli -h new-primary -p 6379 FCALL mark_ready 1 smoke:failover ready

# 读取隔离 key，确认函数的返回和副作用都符合预期
redis-cli -h new-primary -p 6379 HGET smoke:failover status

客户端层面要重连 Sentinel 或 Cluster 提供的稳定入口，而不是把旧主机地址硬编码成唯一节点。发布门禁至少记录 library 名称、函数名、版本标记、目标节点数量和 FCALL 冒烟结果。

Redis Cluster 和全新实例为什么还要额外处理

Redis Cluster 中，函数库不会像普通主从复制那样自动替所有主节点完成管理分发。扩容或部署后，要对每个 master 运行同一份经过审核的 FUNCTION LOAD；节点加入集群时也要把库版本纳入基础设施配置。否则某个槽位切换到另一主节点时，数据访问正常，FCALL 却可能返回找不到函数。

对于缓存型、可随时重建的 Redis，重启新实例前还要准备函数预加载方案，例如用 Redis 提供的 --functions-rdb 生成包含函数的 RDB，再配合正式的持久化策略。恢复流程应同时检查库、函数和业务数据，不要把“函数存在”当成“数据已恢复”。

常见问题

主从切换后 FCALL 报找不到函数，先查什么？

先查客户端实际连接的节点，再执行 FUNCTION LIST。如果是 Cluster，逐个检查承担目标槽位的 master，确认不是只给旧主节点加载过库。

FUNCTION LIST 正常就代表切换没有丢数据吗？

不代表。它只能证明函数库在当前节点可见；数据是否完整还要结合复制偏移、持久化策略和故障发生时的写入确认方式判断。

为什么不继续使用 EVALSHA？

EVALSHA 适合短小、可重新加载的脚本；如果逻辑需要稳定名字、复制和持久化，Functions 更适合作为可版本化的数据库内 API。