Redis集群如何实现读写分离与负载均衡

Redis集群原生不支持读写分离，所有请求默认被重定向至主节点，从节点仅承担故障转移角色；若需实现真正的读写分离与负载均衡，必须放弃集群客户端，转而采用普通主从客户端配合手动路由——将写操作发往主节点，读操作分发至从节点（需显式执行READONLY），适用于读多写少、容忍短暂复制延迟的场景；对于已上线集群又无法重构的系统，可通过客户端槽位计算优化重定向、引入只读代理或利用Redis 7.0+内嵌从节点等折中方案缓解压力，但务必警惕复制延迟导致的数据不一致、连接状态残留及强一致性读误走从库等关键陷阱。

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，并在每次读操作前检查连接状态（部分驱动会自动清除该状态）

理论要掌握，实操不能落！以上关于《Redis集群如何实现读写分离与负载均衡》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！