Redis Cluster从节点默认拒绝读请求，需客户端显式执行READONLY命令启用读能力，且必须配合拓扑感知与replica-aware连接池才能实现有效读分离。
Redis Cluster 里从节点默认不响应读请求
Redis Cluster 的从节点（replica）默认是只读禁用状态，哪怕你连的是从节点地址，GET 这类命令也会被拒绝，报错 READONLY You can't write against a read only replica.——注意这个错误信息本身有误导性，它其实是在说“你试图对只读节点做写操作”，但真正触发它的常见原因反而是：你没显式声明“我要读”。
- Cluster 模式下，客户端路由由服务端重定向（MOVED/ASK）驱动，所有命令默认发往负责该 slot 的主节点，从节点不会自动参与读流量分担
- 从节点要处理读请求，必须先执行
READONLY命令切换连接状态；断开重连后状态重置，得重新发 - 部分客户端（如 Jedis、redis-py）封装了
READONLY调用，但默认不启用，需手动开启读写分离策略或指定 replica 链接模式
客户端启用 READONLY 的典型方式
不是改 Redis 配置，也不是在 redis.conf 里设 slave-read-only yes（那是单机主从的老逻辑，Cluster 下无效），而是客户端连接后主动发指令。
- 原生 redis-cli 连从节点后，先执行
READONLY，再执行GET key才能成功 - Java + Jedis：创建
JedisPool时传入new JedisPoolConfig()后，需调用jedis.readonly()（注意不是构造时设置） - Python + redis-py：连接后调用
client.execute_command("READONLY")，或使用readonly=True参数初始化 client（仅限 4.0+ 版本） - Node.js + ioredis：配置
enableReadyCheck: false和readonly: true，否则 ready check 会因INFO命令失败而中断连接
READONLY 不等于自动负载均衡
发了 READONLY 只是解锁当前连接的读能力，不代表客户端会自动把读请求打到从节点——它仍然可能被 Cluster 的 MOVED 重定向回主节点，尤其当 key 的 slot 映射未缓存或过期时。
- 客户端必须支持 Cluster 拓扑感知（如维持 slots 缓存），并识别出某 slot 当前有可用 replica，才可能将读请求发过去
- 很多客户端默认只连主节点列表，即使你手动连了从节点 IP，若没在初始化时传入 replica 地址，它根本不知道那些从节点存在
- Redis 6.0+ 引入
READONLY REPLICA（非标准命令），但实际未被广泛支持；别依赖它 - 真正可控的读分离，得靠客户端显式选择节点：比如用
getReadOnlyClient(slot)或按 tag 路由（如{user:123}）配合 replica-aware 连接池
容易被忽略的兼容性坑
READONLY 是连接级状态，不是实例级，也不跨 pipeline。一个连接发了 READONLY，不代表同一批 pipeline 里的所有命令都安全执行——如果中间夹着 SET，从节点直接报错中断。
- 事务（
MULTI/EXEC）中不能混用读写命令，否则整个 EXEC 失败；Cluster 下更麻烦：事务涉及多个 slot 时，根本无法路由到单一节点 - 某些旧版客户端（如早期 StackExchange.Redis）在 Cluster 模式下忽略
READONLY，或把 replica 连接当成普通节点加入拓扑，导致读请求被错误重定向 - 监控和日志里看不到 “谁在读从节点”，因为
CLIENT LIST不暴露 readonly 状态，只能靠INFO replication查连接数 + 主从 lag 综合判断
真正落地时，最麻烦的往往不是怎么发 READONLY，而是客户端是否把 replica 视为一等公民来管理连接生命周期、故障转移和重试逻辑。
