Redis 高可用与集群原理深度解析

Redis 高可用与集群原理

1. 前言

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

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

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

2. Redis 高可用架构演进

• 主从复制（Replication）
  • 提供读写分离，但主节点宕机会导致服务中断，需要人工干预。
• 哨兵（Sentinel）
  • 自动监控主节点健康，支持 自动故障转移。
• 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）与复制原理，这样整个高可用 + 数据可靠性体系就完整了。

到此这篇关于Redis 高可用与集群原理深度解析的文章就介绍到这了,更多相关Redis 高可用集群内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！