redis cluster原生不支持自动读写分离，必须由客户端直连从节点并显式执行readonly命令才能启用本地读，且仅对当前tcp连接及对应主节点槽位生效。
Redis Cluster 里配置读写分离根本不是配从节点，而是配客户端连接
Redis Cluster 原生不支持从节点自动承接读请求。你改 slave-read-only yes、调 repl-backlog-size、甚至重启从节点，都完全无效——集群模式下这些配置对读路由零影响。真正起作用的，只有客户端连接时执行的 readonly 命令。
这意味着：
- 每个 TCP 连接必须显式执行
readonly才能走本地读，断开重连后要再执行一次 - 从节点不会主动暴露自己可读，客户端必须预先知道哪些 IP:port 是从节点，并直连它们
- 读请求是否分流，取决于你发给谁 + 是否开了
readonly，跟集群拓扑发现无关
客户端必须手动连接从节点并执行 readonly
Spring Boot + Lettuce 或 Jedis 都不自动识别集群里的从节点角色，也不会帮你选从节点发 readonly。你得自己维护从节点地址列表，并在建立连接后立刻发送命令：
redis-cli -h 192.168.1.20 -p 7001 -c 192.168.1.20:7001> readonly
之后所有读命令（GET、HGET 等）才会由该从节点本地处理；写命令（SET、INCR）仍会触发 MOVED 重定向到对应主节点。
常见错误现象：
- 用
redis-cli -c连主节点执行readonly→ 无效，主节点无视该命令 - 连从节点但没执行
readonly→ 所有读请求照样被重定向到主节点 - 用 JedisCluster 初始化时传入全部节点（含从节点）→ 它只认主节点槽位，从节点地址被忽略
只读连接有严格的作用域和 key 范围限制
readonly 不是让整个从节点变“可读”，而是让当前连接对“自己同步的那个主节点负责的哈希槽”可读。如果读的 key 不属于该从节点对应的主节点，依旧会返回 MOVED。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
例如：从节点 A 同步主节点 M1（负责槽 0–5460），你连 A 并执行 readonly，然后执行 GET user:1001 —— 如果 user:1001 的槽位是 1234，就读成功；如果是 6000，就会被重定向到负责槽 6000 的主节点。
所以实际落地时必须：
- 提前通过
CLUSTER SLOTS或客户端 SDK 获取每个从节点映射的槽区间 - 读请求前做本地槽计算（
CRC16(key) % 16384），判断是否落在目标从节点范围内 - 无法匹配时，降级走主节点或换另一个从节点重试
生产环境建议绕开集群读写分离，改用单机主从+客户端路由
除非你有极强的定制能力，否则 Redis Cluster 的读写分离落地成本远高于收益。Lettuce、Jedis、StackExchange.Redis 等主流客户端都不原生支持带槽感知的只读连接池，你需要自己封装连接管理、故障剔除、延迟监控、一致性兜底逻辑。
更现实的选择是：
- 保持 Redis Cluster 专注分片和高可用，读压力靠加主节点数量或前置多级缓存缓解
- 若读吞吐确实瓶颈，单独部署一套单机主从架构（非集群模式），用 Lettuce 的
read-from: REPLICA_PREFERRED自动分流 - 强一致性读场景，统一走
read-from: MASTER，避免业务层判断槽位和节点关系
真正容易被忽略的是：集群模式下，从节点的内存和 CPU 并不天然闲置——它要持续做增量复制、参与故障检测、响应 CLUSTER NODES 查询。盲目开启 readonly 可能让它从“备份节点”变成“半负载节点”，却没换来等量读性能提升。
