深入理解 Redis 集群架构：主从同步、哨兵机制与 Cluster 原理

引言

在高并发、高可用的业务场景下，单机 Redis 已无法满足系统对容量、性能和可用性 的要求。Redis 通过主从复制、哨兵机制和 Cluster 集群模式，逐步构建了一套分布式高可用架构体系。

本文将从底层原理出发，系统讲解 Redis 的主从同步机制、数据一致性问题、哨兵故障转移原理，以及 Cluster 分片集群的设计与实现。

一、Redis 主从复制：完全同步与增量同步

Redis 的主从复制（Replication）是实现高可用与读写分离的基础。复制过程分为两种情况：完全同步（Full Sync） 与 增量同步（Partial Sync）。

1. 完全同步（Full Resynchronization）

触发时机

完全同步通常发生在以下场景：

• 首次建立主从关系
• 从节点数据丢失（如重启、磁盘损坏）
• 主节点发生变化（如故障转移后重新复制）
• 从节点落后太多，复制缓冲区数据已被覆盖

完全同步的执行流程

完整流程可以拆解为 6 个关键步骤：

1. 从服务器发送 SYNC / PSYNC 请求
2. 主服务器生成 RDB 快照
3. 主服务器将 RDB 文件发送给从服务器
4. 从服务器接收并加载 RDB 文件
5. 主服务器在生成 RDB 期间，将新的写命令写入复制缓冲区
6. RDB 传输完成后，主服务器将缓冲区中的写命令发送给从服务器进行回放

核心特点：

• 数据量大、网络与磁盘 IO 开销高
• 会阻塞从节点对外提供服务一段时间

2. 增量同步（Partial Resynchronization）

为避免频繁全量同步，Redis 引入了 增量复制机制。

核心机制

• repl_backlog_buffer（复制积压缓冲区）
• Replication Offset（复制偏移量）

主从节点都会维护一个 offset：

• 主节点记录当前写命令的全局 offset
• 从节点记录已复制到的位置 offset

增量同步流程

1. 从节点重连时发送 PSYNC，携带自己的 replication offset
2. 主节点判断该 offset 是否仍在 repl_backlog_buffer 中
3. 若存在 → 只发送缺失的增量命令
4. 若不存在 → 退化为完全同步

优势：

• 同步成本低
• 对业务影响小
• 是 Redis 高可用的关键优化之一

二、Redis 主从与集群的一致性问题（CAP 视角）

Redis 并不追求强一致性，而是遵循 CAP 理论中的 AP 模型。

Redis 的 CAP 定位

• A（Availability）：高可用

• P（Partition Tolerance）：分区容忍

• C（Strong Consistency）：不保证强一致

可能出现的数据不一致场景

• 主节点写入成功，但尚未同步到从节点就发生宕机

• 客户端从从节点读取到旧数据

• 网络分区导致主从状态判断不一致

结论 ：

Redis 的一致性是 最终一致性（Eventual Consistency）。

三、Redis 哨兵机制：自动故障转移的核心

为了避免主节点故障导致服务不可用，Redis 提供了 Sentinel（哨兵）机制。

1. 哨兵的三大职责

1. 监控（Monitoring）

   • 定期 PING 主从节点，检测是否存活

2. 通知（Notification）

   • 向客户端或运维系统上报状态变化

3. 自动故障转移（Failover）

   • 在主节点宕机后，自动选举新主节点

2. 故障判定流程

① 主观下线（SDOWN）

• 单个 Sentinel 判断某节点不可达

② 客观下线（ODOWN）

• 多个 Sentinel 达成一致

• 超过配置的 quorum 数量

3. Sentinel Leader 选举

1. Sentinel 集群通过 Raft 类似的投票机制
2. 选出一个 Leader Sentinel
3. 由 Leader 负责执行故障转移流程

4. 新主节点选举规则（简化）

优先级参考：

• 从节点优先级（replica-priority）
• replication offset（数据最新）
• 运行 ID（字典序）

完成后：

• 提升新主节点
• 其他从节点重新复制新主
• 通知客户端更新连接信息

四、Redis Cluster：真正的分布式方案

主从 + 哨兵仍然是单主写入模型 ，无法解决容量瓶颈。

Redis Cluster 通过 **分片（Sharding）**实现横向扩展。

1. Cluster 核心设计：槽（Slot）

• Redis Cluster 将 key 空间划分为 16384 个槽

• 每个节点负责一部分槽

• 槽通过 CRC16(key) % 16384 计算得到

2. 数据分布方式

• 平均分配：创建集群时自动分配

• 手动分配：支持迁移槽，实现扩容 / 缩容

3. 客户端如何定位分片？

1. 客户端首次随机访问某节点

2. 若访问的 key 不在该节点：

   • 返回 MOVED / ASK 重定向

3. 客户端缓存 slot → node 映射表

4. 后续请求可直接路由到正确节点

这是 Redis Cluster 无代理（Proxyless）设计的关键

4. Cluster 模式的优缺点

优点

• 水平扩展能力强
• 无中心节点
• 自动故障转移（节点级）

缺点

• 不支持跨 slot 的事务
• 多 key 操作受限
• 运维复杂度较高

总结

Redis 的高可用与分布式能力是逐层演进的结果：

• 主从复制 → 数据冗余
• 哨兵机制 → 自动故障转移
• Cluster 模式 → 分布式扩展

在实际工程中，应根据业务特点选择合适架构，而不是盲目上 Cluster。