Redis FCALL_RO 和 FCALL 在只读副本调用上有什么区别

如果一个 Redis 函数只读取数据，却在只读副本上执行失败，先别急着改客户端连接池。最常见的原因是函数注册时没有声明 no-writes：Redis 默认认为函数可能修改数据，因此 FCALL_RO 会拒绝它。简单记忆：写函数调用主节点用 FCALL；明确只读的函数，才适合用 FCALL_RO 发送到只读副本。

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

FCALL_RO 和 FCALL 的差别在函数能力，不在返回格式

两条命令的参数结构接近，都是函数名、numkeys、显式 key 和普通参数。区别在执行许可：FCALL 调用普通函数，函数可以读也可以写；FCALL_RO 调用只读函数，Redis 会检查函数登记信息，拒绝带写入能力标志的函数。两者返回值仍由函数决定，不会因为换成 FCALL_RO 就自动变成另一种 RESP 类型。

因此，命令名不是权限绕过。一个没有正确标记的纯读函数，使用 FCALL_RO 反而会得到类似 ERR Can not execute a function with write flag using fcall_ro 的错误。

纯读取函数要在注册时声明 no-writes

Redis Functions 默认按可能读写处理。下面的库只读取一个哈希，并返回字段和值；flags 中的 no-writes 是让 Redis 放行只读调用的关键信息。

#!lua name=profile_queries

-- 只读取 KEYS[1]，ARGV[1] 只作为可选字段名，不拼接动态 key。
local function read_profile(keys, args)
    if args[1] == 'email' then
        return redis.call('HGET', keys[1], 'email')
    end
    return redis.call('HGETALL', keys[1])
end

-- no-writes 表明这个函数不应执行 SET、DEL、INCR 等修改命令。
redis.register_function{
    function_name = 'read_profile',
    callback = read_profile,
    flags = {'no-writes'}
}

装载后，读副本可以使用：

# 1 表示后面的 profile:{1001} 是唯一一个 key；email 是普通参数。
redis-cli FCALL_RO read_profile 1 profile:{1001} email

如果把函数改成调用 HSET，即使客户端仍使用同一个函数名，FCALL_RO 也不应继续使用。修改逻辑应该登记为可写函数，并由客户端把请求送到主节点。已经加载过旧库时，要用明确的版本化流程替换函数，避免一部分节点仍保留旧定义。

副本读取还要接受复制延迟和路由限制

FCALL_RO 解决的是“函数是否允许写入”这一层，不保证副本已经追上主节点。刚写入主节点后立刻从副本读取，可能得到旧值；订单状态、余额和权限判断通常应继续读主节点，商品详情、报表或可容忍短暂延迟的查询才适合分流。

在 Redis Cluster 中，函数访问的 key 仍要显式放入 KEYS，不要在 Lua 内用 ARGV 拼出要访问的 key。多个 key 需要符合集群路由要求，常用相同 hash tag，例如 profile:{1001} 和 quota:{1001}。ARGV 只传字段名、阈值或分页参数，便于客户端和路由层知道函数涉及哪些 key。

客户端可以按下面的判断表实现路由：

常见问题

纯读取函数能不能直接用 FCALL 发到副本？

不能只看函数体“目前没有写命令”。它还必须按 Redis 的函数标志正确登记；未声明 no-writes 时，Redis 会按可能写入处理并拒绝副本执行。

FCALL_RO 会自动把写函数改成只读吗？

不会。它是限制更严格的调用入口，遇到带写入标志的函数会报错，不会屏蔽函数中的写命令。

副本读到旧值是 FCALL_RO 的 bug 吗？

通常不是。FCALL_RO 只表达只读执行能力，主从复制仍可能存在延迟；需要读己之写或强一致判断时，应读主节点。