如何通过Redis集群的读写分离配置提升系统性能？

Redis Cluster原生不支持自动读写分离，必须由客户端直连从节点并显式执行readonly命令才能启用本地读，且仅对当前TCP连接及对应主节点槽位生效。

Redis Cluster 里配置读写分离根本不是配从节点，而是配客户端连接

Redis Cluster 原生不支持从节点自动承接读请求。你改 slave-read-only yes、调 repl-backlog-size、甚至重启从节点，都完全无效——集群模式下这些配置对读路由零影响。真正起作用的，只有客户端连接时执行的 readonly 命令。

这意味着：

1. 每个 TCP 连接必须显式执行 readonly 才能走本地读，断开重连后要再执行一次
2. 从节点不会主动暴露自己可读，客户端必须预先知道哪些 IP:port 是从节点，并直连它们
3. 读请求是否分流，取决于你发给谁 + 是否开了 readonly，跟集群拓扑发现无关

客户端必须手动连接从节点并执行 readonly

Spring Boot + Lettuce 或 Jedis 都不自动识别集群里的从节点角色，也不会帮你选从节点发 readonly。你得自己维护从节点地址列表，并在建立连接后立刻发送命令：

redis-cli -h 192.168.1.20 -p 7001 -c192.168.1.20:7001> readonly

之后所有读命令（GET、HGET 等）才会由该从节点本地处理；写命令（SET、INCR）仍会触发 MOVED 重定向到对应主节点。

常见问题表现：

1. 用 redis-cli -c 连主节点执行 readonly → 无效，主节点无视该命令
2. 连从节点但没执行 readonly → 所有读请求照样被重定向到主节点
3. 用 JedisCluster 初始化时传入全部节点（含从节点）→ 它只认主节点槽位，从节点地址被忽略

只读连接有严格的作用域和 key 范围限制

readonly 不是让整个从节点变“可读”，而是让当前连接对“自己同步的那个主节点负责的哈希槽”可读。如果读的 key 不属于该从节点对应的主节点，依旧会返回 MOVED。

例如：从节点 A 同步主节点 M1（负责槽 0–5460），你连 A 并执行 readonly，然后执行 GET user:1001 —— 如果 user:1001 的槽位是 1234，就读成功；如果是 6000，就会被重定向到负责槽 6000 的主节点。

所以实际落地时必须：

1. 提前通过 CLUSTER SLOTS 或客户端 SDK 获取每个从节点映射的槽区间
2. 读请求前做本地槽计算（CRC16(key) % 16384），判断是否落在目标从节点范围内
3. 无法匹配时，降级走主节点或换另一个从节点重试

生产环境建议绕开集群读写分离，改用单机主从+客户端路由

除非你有极强的定制能力，否则 Redis Cluster 的读写分离落地成本远高于收益。Lettuce、Jedis、StackExchange.Redis 等主流客户端都不原生支持带槽感知的只读连接池，你需要自己封装连接管理、故障剔除、延迟监控、一致性兜底逻辑。

更现实的选择是：

1. 保持 Redis Cluster 专注分片和高可用，读压力靠加主节点数量或前置多级缓存缓解
2. 若读吞吐确实瓶颈，单独部署一套单机主从架构（非集群模式），用 Lettuce 的 read-from: REPLICA_PREFERRED 自动分流
3. 强一致性读场景，统一走 read-from: MASTER，避免业务层判断槽位和节点关系

真正容易被忽略的是：集群模式下，从节点的内存和 CPU 并不天然闲置——它要持续做增量复制、参与故障检测、响应 CLUSTER NODES 查询。盲目开启 readonly 可能让它从“备份节点”变成“半负载节点”，却没换来等量读性能提升。