Redis集群默认不支持读写分离，所有请求均被重定向至主节点，从节点仅用于故障转移；如需读写分离，须弃用集群客户端，改用普通主从客户端自行路由。
Redis集群默认不支持读写分离
Redis官方集群（Redis Cluster）设计上不提供主从读写分离能力
所有客户端请求（包括 GET、SET）都会被重定向到负责该槽位的主节点，从节点仅用于故障转移和数据冗余。即使你连接的是从节点，READONLY 命令也不能在集群模式下生效——它只在单机主从结构中起作用。
常见错误现象：
• 客户端直连从节点并发送 GET 请求，返回 MOVED 或 ASK 重定向响应
• 使用 redis-cli -c 连集群后执行 READONLY，提示 (error) ERR unknown command `readonly`, with args beginning with:
想让从节点处理读请求，必须绕过集群协议
核心思路：放弃 redis-cli -c 或 JedisCluster / lettuce 的集群模式客户端，改用普通主从客户端分别连接各节点，并自行路由。
适用场景：
• 读多写少、对一致性要求不苛刻（允许短暂从节点延迟）
• 已有稳定主从拓扑（如 1 主 + 3 从），且未启用 Redis Cluster 模式
• 使用哨兵（Sentinel）或纯主从 + 客户端负载均衡
实操建议：
• 配置哨兵时，用 sentinel.getMasterAddressByName() 获取主节点，再通过 sentinel.slaves() 列出从节点列表
• 读请求随机选一个从节点（或加权重轮询），写请求固定发往主节点
• 在客户端代码里显式调用 READONLY（仅对单个从节点连接有效）
示例（Python redis-py）：
import redis<br><br># 连主节点（写）<br>master = redis.Redis(host='mymaster', port=6379)<br><br># 连某个从节点（读）<br>slave = redis.Redis(host='slave1', port=6380)<br>slave.execute_command('READONLY') # 必须显式声明<br>value = slave.get('key')
集群模式下“伪读写分离”的折中方案
如果已上线 Redis Cluster 且无法重构架构，只能做有限优化：
- 客户端层面识别只读命令（如
GET、LRANGE、SCARD），对 key 做 CRC16 槽计算后，主动向对应主节点发起请求 —— 这不能分担压力，但可避免跨节点重定向开销 - 部署多个只读代理（如
twemproxy或自研 proxy），在 proxy 层解析命令类型与 key，将读请求转发给对应主节点的从副本（需手动维护主从映射关系） - 使用 Redis 7.0+ 的
REPLICA-OF+CLUSTER REPLICATE组合，构建“集群内嵌从节点”，但该节点仍无法被集群自动识别为可读节点，需客户端绕过集群逻辑直连
性能影响：代理层增加 0.2–0.5ms RTT；手动维护主从映射易因故障转移失效，需监听 SENTINEL 事件或定期 CLUSTER NODES 扫描更新
最容易被忽略的坑：复制延迟与连接复用
从节点读取的最大风险不是配置失败，而是业务没意识到数据可能滞后。
常见疏漏：
• 用户刚注册（写主库），立刻查个人资料（读从库），查不到或查到旧头像
• 未对关键读路径加 READWRITE 切换逻辑（例如查不到时自动 fallback 到主节点）
• 复用同一连接对象执行读/写混杂操作，READONLY 状态残留导致后续写失败
建议：
• 对强一致性读（如订单详情、账户余额）始终走主节点
• 从节点连接池独立于主节点，禁止共享
• 在连接建立后立即执行 READONLY，并在每次读操作前检查连接状态（部分驱动会自动清除该状态）
