Redis 高可用与集群原理

1. 前言

Redis 单机虽然高性能，但一旦节点宕机，数据丢失或服务不可用问题会非常严重。为了解决这一问题，Redis 提供了 主从复制、哨兵（Sentinel）、Cluster 集群 等高可用机制。

这一篇文章我们重点拆解：

• Sentinel 哨兵机制：如何发现故障、如何自动主从切换。
• Cluster 集群架构：如何实现分片存储与高可用。
• Gossip 协议：节点间如何通信。
• 故障转移源码剖析：Redis 内部实现流程。

---

2. Redis 高可用架构演进

1. 主从复制（Replication）

   • 提供读写分离，但主节点宕机会导致服务中断，需要人工干预。

2. 哨兵（Sentinel）

   • 自动监控主节点健康，支持 自动故障转移。

3. Cluster 集群

   • 支持 数据分片（水平扩展），并内置高可用。

👉 可以理解为：
复制 = 数据冗余
Sentinel = 自动运维
Cluster = 扩展能力 + 内置高可用

---

3. Sentinel 哨兵机制

3.1 Sentinel 的作用

• 监控（Monitoring）：周期性检测 Master 和 Slave 是否可达。
• 通知（Notification）：当节点异常时，向客户端/其他哨兵发送通知。
• 故障转移（Failover）：自动将一个 Slave 提升为新的 Master，并让其他 Slave 复制它。

3.2 故障检测机制

• 主观下线（SDOWN）：某个 Sentinel 认为 Master 不可达。
• 客观下线（ODOWN）：多数 Sentinel 达成共识，确认 Master 宕机。

3.3 Leader 选举

在多个 Sentinel 中，需要选出一个 Leader 来执行故障转移，算法基于 Raft 的选举思想：

• 每个 Sentinel 给候选者投票。
• 超过半数票数的 Sentinel 当选 Leader。

3.4 源码剖析（sentinel.c）

哨兵检测主观下线：

// sentinel.c
if (mst->flags & SRI_MASTER) {if ((mst->flags & SRI_S_DOWN) == 0 && mst->link->disconnected) {mst->flags |= SRI_S_DOWN; // 标记主观下线sentinelEvent(LL_WARNING, "+sdown", mst, "%@");}
}

这段代码表明，当哨兵发现主节点无法连接时，会标记为 S_DOWN。

---

4. Redis Cluster 集群架构

4.1 核心特性

• 分布式存储：采用 16384 个哈希槽（hash slots），每个节点负责一部分槽位。
• 高可用：每个分片至少有 1 个 Master 和若干 Slave。
• 自动故障转移：某个 Master 挂掉时，其 Slave 自动升级为新的 Master。

4.2 集群拓扑

         ┌───────────┐│   Client  │└─────┬─────┘│┌─────────────▼─────────────┐│        Cluster            ││ ┌────────┐   ┌────────┐   ││ │ Master │   │ Master │   │ ...│ │ Slot 0 │   │ Slot 5461  ││ └───▲────┘   └────▲───┘   ││     │            │         ││   ┌─┴─┐        ┌─┴─┐       ││   │Slave│      │Slave│     ││   └─────┘      └─────┘     │└────────────────────────────┘

4.3 请求路由

• Client 向某个节点发起请求。
• 如果 Key 不在本节点的槽位范围，返回 MOVED 重定向。
• 客户端更新槽位映射表，下次直连正确节点。

---

5. Gossip 协议

Redis Cluster 中节点通信依赖 Gossip 协议，类似于 流言传播：

• 每个节点周期性地向随机节点发送 PING。
• 接收节点返回 PONG，附带自己已知的集群信息。
• 这样集群拓扑信息逐渐在所有节点中收敛。

消息类型：

• MEET：新节点加入。
• PING/PONG：心跳检测与状态同步。
• FAIL：节点失效信息。

👉 Gossip 的特点是 去中心化、最终一致性。

---

6. 故障转移源码剖析

当 Master 宕机时，Cluster 的转移逻辑如下：

1. 检测故障

// cluster.c
if (node->flags & (CLUSTER_NODE_FAIL | CLUSTER_NODE_PFAIL)) {// 标记为下线
}

2. Slave 竞选新 Master

• 每个 Slave 会尝试升级为 Master。
• 使用投票机制，获得过半节点支持的 Slave 升级。

3. 重新分配槽位

// cluster.c
clusterFailoverReplaceYourMaster();

执行槽位迁移，客户端可继续访问。

4. 客户端感知

• 客户端收到 MOVED / ASK，刷新槽位映射。

---

7. 总结

本文深入分析了 Redis 高可用与集群原理：

1. Sentinel：实现了自动故障转移，基于 SDOWN/ODOWN 和选举机制。
2. Cluster：通过哈希槽实现数据分片和自动转移。
3. Gossip 协议：支撑集群中节点间的通信和状态同步。
4. 源码剖析：揭示了 Redis 在 sentinel.c、cluster.c 中的故障转移实现。

📌 下一步可以写 Redis 持久化（RDB/AOF）与复制原理，这样整个高可用 + 数据可靠性体系就完整了。