2. Redis 集群架构基础：主从复制、哨兵模式、Redis Cluster 分片原理、节点通信机制

在深入故障恢复与缓存预加载之前，必须透彻理解 Redis 的三种集群架构。每种架构在数据一致性、可用性和扩展性上做出了不同的权衡，直接决定了故障场景下的行为与恢复策略。

2.1 主从复制（Replication）

主从复制是 Redis 高可用的基石。一个主节点（Master）可以拥有多个从节点（Slave），从节点实时同步主节点的数据，形成 一主多从 的星型拓扑。

核心流程

1. 连接建立：从节点向主节点发送 PSYNC 命令，请求同步。
2. 全量复制：主节点执行 BGSAVE 生成 RDB 快照，同时将新写入命令缓存到复制缓冲区（Replication Buffer）。从节点加载 RDB 文件后，再接收并执行缓冲区中的增量命令。
3. 增量复制：全量复制完成后，主节点持续将写命令推送给从节点，保持最终一致。

主从复制架构图

2.2 哨兵模式（Sentinel）

哨兵模式在主从复制基础上增加了自动故障转移能力。哨兵（Sentinel）是一个独立进程，负责监控主节点和从节点的健康状态，并在主节点故障时自动选举新的主节点。

哨兵核心职责

故障转移流程

1. 主观下线：单个哨兵发现主节点超过 down-after-milliseconds 未响应。
2. 客观下线：多个哨兵（通常为 quorum 数量）都认为主节点下线，触发故障转移。
3. Leader 选举：哨兵集群通过 Raft 类算法选举一个 Leader 负责执行转移。
4. 新主选举：Leader 从从节点中选出优先级最高、数据最完整的节点作为新主。
5. 配置更新：所有哨兵和客户端更新主节点信息。

2.3 Redis Cluster 分片原理

Redis Cluster 是官方提供的分布式解决方案，通过数据分片实现水平扩展。它将所有键空间划分为 16384 个哈希槽（Hash Slot），每个节点负责一部分槽位。

分片算法

// 计算键所属的哈希槽
slot = CRC16(key) % 16384

// 示例：键 "user:1001" 的 CRC16 值为 0xA1B2，取模后落入槽 12345
// 该槽由节点 A 负责，则读写请求路由到节点 A

槽位分配示例

Redis Cluster 分片架构图

2.4 节点通信机制

Redis Cluster 节点之间通过 Gossip 协议 进行通信，维护集群的元数据一致性。每个节点维护一个 集群状态表，包含所有节点的状态、槽位分配、主从关系等信息。

Gossip 消息类型

Gossip 通信流程

1. 每个节点每秒随机选择 5 个 其他节点发送 PING 消息。
2. PING 消息包含本节点已知的 部分 集群状态（通常 2-3 个其他节点的信息）。
3. 接收节点回复 PONG，同样携带自己的状态信息。
4. 节点通过不断交换信息，最终所有节点收敛到一致的集群视图。

三种架构对比