Redis 集群采用 N 主 + M 从 (N ≥ 3) 的架构设计，其中主节点和从节点扮演着严格定义且互补的角色，这种设计是为了满足高可用性（HA） 和 数据分片（Sharding） 的核心需求。以下是主节点和从节点的核心区别、设计讲究及其原因：
一、主节点（Master Nodes）
-
核心职责：
- 数据存储与读写： 每个主节点负责存储集群中分配给它的 一部分槽（Slot） 对应的数据（共16384个槽，分给N个主节点）。
- 处理请求： 直接处理客户端对这些槽的读写命令（SET, GET, DEL等）。
- 参与集群管理： 通过 Gossip 协议 与其他节点交换状态信息，参与 故障检测 和 故障转移 的投票决策。
-
数量讲究 (N ≥ 3)：
- 最小可用性要求： Redis 集群使用类似 Raft 共识算法 的机制进行故障转移。需要大多数（Majority）主节点达成共识 才能执行故障转移、槽迁移等关键操作。
- 容错能力：
N=3：集群可容忍 1个主节点故障（剩余2个 > 3/2=1.5，满足多数派）。N=5：可容忍 2个主节点故障（剩余3个 > 5/2=2.5）。
N < 3的问题：N=1：单点故障，无冗余。N=2：若1个主节点故障，剩余1个节点无法达到多数派（2/2=1，但需要 >1.5），集群无法完成故障转移，会不可用。
二、从节点（Slave Nodes / Replica Nodes）
-
核心职责：
- 数据冗余： 作为指定主节点的副本 ，通过异步复制接收主节点的数据更新。
- 故障转移： 当主节点故障时，符合条件的从节点会升级为新的主节点（由其他主节点投票选出），接管原主节点的槽和数据服务，保障可用性。
- 读扩展（可选）： 客户端可配置从从节点读取数据（但需注意复制延迟可能导致脏读）。
-
数量讲究 (M ≥ 1，通常 M = N)：
- 最小冗余要求： 每个主节点至少应有1个从节点 ，否则主节点故障时该分片数据将不可用。
- 高可用推荐： 生产环境通常为每个主节点配置1个从节点 （即
M = N），形成对称结构。 - 更高冗余： 对关键分片可为1个主节点配置多个从节点（
M > N），提升容错能力（如允许同时故障1主+1从）。
三、为什么这样设计？核心原因
| 设计原则 | 实现方式 | 解决的问题 |
|---|---|---|
| 数据分片 (Sharding) | N 个主节点平分 16384 个 Slot | 水平扩展写能力与存储容量 |
| 高可用 (HA) | 每个主节点有 ≥1 个从节点（M ≥ N） | 避免单点故障，实现自动故障转移 |
| 分布式共识 | N ≥ 3，基于多数派投票机制 | 安全地执行故障转移与配置变更 |
| 数据冗余 | 从节点异步复制主节点数据 | 防止数据丢失（节点故障时） |
四、关键流程示例：故障转移（Failover）
- 主节点 X 被多数主节点判定为 FAIL（通过心跳超时 + Gossip 传播确认）。
- 主节点 X 的从节点（如 S1）发起竞选。
- 集群中大多数主节点（≥ N/2 + 1） 对 S1 的升级进行投票。
- 若投票通过：
- S1 被提升为新主节点。
- S1 接管原主节点 X 的所有 Slot。
- 集群更新拓扑信息，客户端重定向到 S1。
⚠️ 若主节点数 N=2：
当1个主节点故障时，剩余1个主节点无法满足"大多数"（需要 ≥1.5 → 实际需要2票）。故障转移无法触发，集群将不可写！
五、总结与最佳实践
- 主节点 (N)：
- 必须 ≥ 3，确保共识机制可用。
- 负责数据分片与读写。
- 从节点 (M)：
- 必须 ≥ N（每个主至少1个从）。
- 提供数据冗余与故障恢复能力。
- 推荐架构：
N = M（例如 3主3从、6主6从），平衡性能、扩展性与高可用。
graph LR
A[客户端] --> B[主节点 M1]
A --> C[主节点 M2]
A --> D[主节点 M3]
B -->|复制| S1[从节点 S1]
C -->|复制| S2[从节点 S2]
D -->|复制| S3[从节点 S3]
subgraph Redis Cluster
B & C & D -- Gossip协议 --> 集群状态共识
S1 & S2 & S3 -- 故障检测 --> B & C & D
end
✅ 最终结论：
Redis 集群通过 N主（分片） + M从（冗余） 的架构，结合 分布式共识（N≥3） 和 自动故障转移（M≥N），实现了高性能、高可用与线性扩展。这是分布式系统设计中的经典权衡（CAP），确保了在分区容忍性（P）下的可用性（A）与一致性（C）的平衡。