Redis Cluster 架构核心的设计理念

Redis Cluster 架构核心的设计理念——为什么它是“分片 + 主从”，而不是“互为主从”。

 

---

 

 

🔍 简单回答：

 

 

Redis Cluster 是“分片（分槽）+ 主从复制”架构，不是“互为主从”，因为它的目的是扩展性能 + 提高可用性，两者责任不一样！

 

---

 

 

✅ 一、Redis Cluster 是 

分槽存储（slot-based sharding）

 

 

• Redis 的集群被划分成 16,384 个槽（slots）

• 每个“主节点”负责一部分 slot 的 key 存储（比如 05460、546110922、10923~16383）

 

 

 

举例：

 

主节点	负责 slots 范围
7000	0 - 5460
7001	5461 - 10922
7002	10923 - 16383

所以一个 key，比如 set name tom，会被 Redis 通过 CRC16 算法计算槽号，比如算出来是 slot 1240，那就存到 7000 上。

 

---

 

 

✅ 二、从节点只负责高可用，不存“不同槽的数据”

 

 

从节点只做主节点的“备份”，即：

 

• 不参与存储不同槽的数据

• 只接管主节点宕机后的工作

 

 

例如：

节点	类型	职责
7000	主	负责 slots 0 - 5460
7003	从	跟随 7000，提供故障接管
7001	主	负责 slots 5461 - 10922
7004	从	跟随 7001

 

 

---

 

 

❌ 为什么 Redis 不设计成 “互为主从” 呢？

 

 

比如 A 是 B 的从，B 又是 A 的从（很多人会问：这样不是更安全？）

 

 

❌ 原因如下：

 

问题点	说明
🔁 脑裂风险	主从互相“断网”，两边都以为自己是主，可能写入冲突，数据不一致
🔀 不清职责	主负责读写，从负责备份、故障接管，职责清晰。互为主从会造成职责混乱
🚫 Redis 不支持双主同步	Redis 是单线程、单主的设计，没有内建同步冲突解决机制（不像 MySQL 的双主复制）
🔁 冗余逻辑复杂	如果两个节点都同步对方，循环复制、性能开销大，还可能陷入无限同步死循环

 

 

---

 

 

✅ Redis Cluster 的设计目标是：

 

 

1. 横向扩展（靠分片）

2. 容灾高可用（靠主从复制 + 哨兵机制）

3. 节点间协商（Gossip协议 + 自动Failover）

 

 

所以，它选择了：

 

• 多主节点负责不同槽的数据

• 每个主节点配备一个或多个从节点来保证高可用

• 节点之间不会互为主从，从属关系是“单向”的

 

 

---

 

 

🧠 总结一句话：

 

 

Redis Cluster 把 “扩展性” 交给分槽，把 “可用性” 交给主从复制，

如果主节点宕了，从节点接管；但不会出现两个主节点互相复制，因为 Redis 本身是单主架构，天然不适合双主冲突场景。