Redis集群从节点只读优化技巧

Redis集群中从节点默认不响应读请求，因为集群协议完全绕过了传统主从模式下的slave-read-only配置，必须通过客户端连接时显式执行readonly命令开启连接级只读模式，才能让从节点直接处理本主槽的读操作；但需注意该设置仅对当前TCP连接生效，且存在异步复制导致的数据延迟与不一致风险，因此还需结合同步状态监控（如master_last_io_seconds_ago、slave_repl_offset）和动态节点发现（CLUSTER NODES + CLUSTER SLAVES）来安全、高效地将读流量路由至健康可用的从节点。

从节点只读配置为什么不能直接用 slave-read-only yes？

在 Redis 集群模式下，slave-read-only yes 是无效的。这个配置只对纯主从（非集群）部署起作用。集群中每个节点都有自己的槽范围，客户端发来的命令若落在非本节点负责的槽上，会返回 MOVED 或 ASK 重定向响应 —— 即使你连的是从节点，它也不会执行读操作，而是强制跳转到对应主节点。

常见错误现象：redis-cli -c -h 127.0.0.1 -p 6382 连从节点后执行 GET key:test，返回 (error) MOVED 12944 127.0.0.1:6379，而不是读取本地数据。

• 集群模式下，从节点默认拒绝所有读写请求（flags=N），不参与路由逻辑
• slave-read-only 是主从协议层配置，集群协议（Cluster Bus + Slot Hash）完全绕过它
• 想让从节点响应读请求，必须先让客户端连接进入“只读模式”

如何让集群从节点真正响应读请求？

核心动作是执行 readonly 命令，它是连接级别的开关，且仅对当前 TCP 连接生效。执行后该连接会被标记为 flags=r，后续读命令只要命中本节点复制的主节点所属槽，就直接处理，不再重定向。

实操要点：

• 每次新建连接都必须手动执行一次 readonly，断开重连后失效
• 执行 readwrite 可退出只读状态，恢复重定向行为
• 用 CLIENT LIST 查看连接 flags 字段确认是否已生效（flags=r 表示只读连接）
• 不支持在 redis.conf 中全局开启；集群不识别 slave-read-only 配置项

示例流程：

127.0.0.1:6382> readonly
OK
127.0.0.1:6382> get key:test:3130
"value:3130"

为什么集群里从节点读仍可能延迟或不一致？

即使开启了 readonly，读从节点也不等于“强一致”。因为主从同步是异步的，存在天然延迟窗口。尤其在以下场景容易出问题：

• 主节点刚写入，从节点尚未收到 PSYNC 流中的命令（特别是高写入、网络抖动时）
• 从节点正在做全量同步（RDB 加载中），期间无法服务读请求
• 复制积压缓冲区（repl-backlog）太小，断连后触发全量同步，导致长时间不可读
• 客户端未做故障剔除，仍向 fail 状态的从节点发请求（可用 CLUSTER SLAVES 获取健康从节点列表）

监控建议：定期查 INFO REPLICATION 中的 master_sync_in_progress、slave_repl_offset 和 master_last_io_seconds_ago，判断同步健康度。

客户端如何安全路由到可用从节点？

不能硬编码 IP+端口直连某台从节点 —— 它可能宕机、失联或正在同步。正确做法是利用集群元数据动态发现：

• 先用任意节点执行 CLUSTER NODES，找出主节点 ID（flag 包含 master）
• 再对每个主节点 ID 执行 CLUSTER SLAVES ，解析返回结果，过滤掉 fail 或 disconnected 状态的从节点
• 将健康从节点 IP:port 加入本地缓存池，按负载策略（如轮询、随机）分发读请求
• 定期（例如每 30 秒）刷新一次节点列表，避免长期使用 stale 列表

注意：CLUSTER SLAVES 返回的是字符串数组，每项格式类似 "40622f9e... 127.0.0.1:6382 myself,slave cfb28ef1... 003 connected"，需按空格分割并校验第3字段是否含 slave、第5字段是否为 connected。

以上就是《Redis集群从节点只读优化技巧》的详细内容，更多关于的资料请关注golang学习网公众号！