深入解析：Redis 主从哨兵与 Cluster 集群读写分离差异，为何规则截然不同
前言
很多同学在学习 Redis 读写分离时，会发现不同资料里规则好像“前后矛盾”：有的场景从节点直接就能读，有的场景连接从节点却报重定向、无法读取。
其实这并不是 Redis 设计冲突，核心原因是对应了两种完全不同的部署架构：传统主从/哨兵模式、Redis Cluster 集群模式。两种架构定位不同、设计目标不同，从节点读写的默认规则自然天差地别。本文就带大家彻底拆解两种模式的读写分离规则、使用方式、底层逻辑，同时梳理常见误区。
一、核心结论速览
先把核心差异整理成表格，方便大家快速记忆：
| 对应图示 | 部署模式 | 读写分离默认状态 | 核心规则 |
|---|---|---|---|
| 图二 | 传统主从/哨兵模式 | 天生支持 | 从节点默认接收读请求，直接实现主写从读 |
| 图一 | Redis Cluster 集群模式 | 默认禁用，手动开启可用 | 从节点默认拒绝读请求、返回重定向，执行READONLY命令后才可读取 |
二、传统主从 & 哨兵模式：天然支持读写分离
1. 架构概述
主从、哨兵架构是典型的一主多从单分片架构，全量数据统一存储在主节点，所有从节点通过异步复制同步主节点数据。该架构诞生的核心诉求之一，就是读写分离 + 故障容灾，适配中小体量业务场景。
2. 为什么默认就能做读写分离？
- 从节点出厂默认开启读能力，
GET、SCAN、KEYS等所有读命令都可以正常执行，客户端直连从节点即可获取数据，不会产生路由重定向； - 架构设计初衷就是分流读压力：写请求统一落地主节点，海量读请求分摊到多个从节点，有效降低主节点负载。
3. 实际使用方式
配置逻辑非常简单，无需额外命令干预：
- 写请求：客户端连接主节点地址；
- 读请求：客户端连接任意从节点地址。
主流客户端如 Jedis、Redisson 均内置了读写分离策略，只需简单配置，就能实现请求自动路由，无需业务代码手动切换节点。
补充说明
主从模式下从节点默认只读，默认配置下向从节点发送写命令会直接报错。一般不建议修改replica-read-only no配置开放从节点写权限，会彻底破坏主从数据一致性，引发数据错乱问题。
三、Redis Cluster 集群模式：默认禁用读，需手动开启
1. 架构概述
Redis Cluster 是多主多从分片集群，为解决单节点容量、并发上限而生。集群将数据划分为 16384 个哈希槽，不同哈希槽分配给不同主节点，数据按key哈希规则分散存储在各个主节点中；每个主节点都会搭配从节点，从节点核心作用是数据备份 + 主节点故障转移。
2. 为什么默认不能直连从节点读取？
这是 Cluster 架构最容易踩坑的点，根源在于集群的哈希槽路由机制：
- Cluster 的请求处理规则：只有持有对应哈希槽的主节点，才有权限处理该槽位的读写请求；
- 从节点仅同步数据，不持有哈希槽，默认不会承接读请求。客户端直连从节点执行读命令时，从节点会直接返回
MOVED重定向指令，强制客户端跳转至对应主节点读取数据。
Redis 这么设计，主要是为了规避问题：如果允许客户端随意读取从节点，客户端可能因不清楚哈希槽分布，频繁出现“连从节点→重定向主节点”的无效链路，额外增加网络延迟与性能损耗。
3. 如何开启 Cluster 读写分离？
想要使用从节点分担读压力，必须手动在客户端侧执行READONLY命令。
这条命令的语义等同于：客户端已知从节点可能存在数据延迟，自愿接受弱一致性。
执行READONLY之后，当前连接的从节点会正常处理后续所有读请求，不再返回重定向，正式实现 Cluster 架构下的读写分离。
重要注意事项
Cluster 主从同样是异步复制，从节点数据会滞后于主节点。开启从节点读取后，业务会面临数据弱一致性问题。
建议：对数据实时性、一致性要求高的核心业务，优先读取主节点；非实时、高并发的查询业务，再使用从节点做读分流。
四、两大架构读写分离全方位对比
| 对比维度 | 传统主从/哨兵模式 | Redis Cluster 集群模式 |
|---|---|---|
| 从节点默认读权限 | 直接支持读请求 | 默认禁止读，需执行READONLY开启 |
| 数据一致性 | 主从异步复制，存在数据延迟 | 主从异步复制，延迟特性和主从模式一致 |
| 客户端配置难度 | 低，直连从节点即可 | 较高，客户端需支持READONLY指令（Redisson 可配置readMode: SLAVE） |
| 架构核心目标 | 读写分离 + 故障容灾 | 数据分片、容量扩容、分布式高可用，读写分离为附加能力 |
五、解惑：两种架构设计差异的底层逻辑
弄懂设计初衷，就再也不会觉得规则“矛盾”：
- 主从/哨兵模式
面向中小业务，单节点数据量、并发量有限。架构定位偏向读压力分流，从节点的核心价值就是分担读请求，因此默认开放读能力，开箱即用。 - Redis Cluster 集群
面向大数据量、高并发的大型业务，首要目标是突破单节点瓶颈、实现分布式分片。从节点第一职责是做主节点的备用节点，保障集群故障转移。为了规避无效路由带来的性能损耗，默认关闭从节点读能力，把选择权交给使用者。
六、高频误区逐一纠正
误区1：Redis Cluster 的从节点完全不能读
纠正：并非不能读，只是默认不处理读请求。客户端执行READONLY命令后，从节点可正常承接读请求，Cluster 完全支持读写分离。
误区2：主从模式下从节点可以随意写数据
纠正：主从架构从节点默认只读，写请求会被拒绝。强行修改配置开放写权限，会造成主从数据不一致，生产环境严禁使用。
误区3：读写分离只能使用传统主从模式
纠正：两种架构都支持读写分离。Cluster 仅多了一步开启操作，主流客户端（Redisson 等）已封装对应逻辑，简单配置就能落地。
七、总结
- 看到“从节点直接可读”，对应主从/哨兵架构，天生支持读写分离，使用最简单；
- 看到“连接从节点报 MOVED 重定向”，对应Redis Cluster 分片集群，需手动开启
READONLY才能读从节点； - 读写分离必然伴随主从异步延迟，根据业务对数据实时性的要求，选择读主还是读从；
- 架构选型优先看业务规模：中小业务选主从/哨兵，大数据量、大并发分布式场景优先 Redis Cluster。