Redis集群高可用架构完全指南：从主从复制到Sentinel哨兵，再到Redis Cluster

Redis集群高可用架构完全指南：从主从复制到Sentinel哨兵，再到Redis Cluster

单机Redis总有极限：内存不够、磁盘写满、单点故障。如何让Redis既能横向扩展，又能自动容灾？本文从主从复制、哨兵监控到集群分片，系统拆解Redis高可用架构的底层逻辑，助你构建7×24小时不间断的缓存服务。

一、高可用之路：从单点到集群

Redis高可用有三个递进的层次：

 

层次	解决的问题	实现方式
主从复制	数据冗余、读写分离	一个Master，多个Slave
哨兵（Sentinel）	故障自动切换	监控、通知、自动选举新Master
集群（Cluster）	海量数据、水平扩展	数据分片，多Master多Slave

 

二、第一阶段：主从复制 —— 数据冗余的基石

2.1 基本原理

主从复制实现异步数据同步：Master负责写，Slave负责读。数据复制分为两阶段。

2.2 全量复制与增量复制

 

场景	触发条件	流程
全量复制	1. 第一次连接 2. Slave的replid与Master不一致 3. offset不在Master的backlog中	Master执行bgsave生成RDB → 发送给Slave → 清空旧数据 → 加载RDB
增量复制	Slave的offset仍存在于Master的backlog中	Master将积压的命令发送给Slave（类似断点续传）

Master维护一个复制积压缓冲区（replication backlog），默认1MB，用于记录最近发送的写命令。

// 关键参数配置
repl-backlog-size 1mb       // 积压缓冲区大小
repl-backlog-ttl 3600        // 无Slave连接时保留时间
client-output-buffer-limit slave 256mb 64mb 60  // Slave输出缓冲区

2.3 全量复制的性能代价

• 生成RDB：fork子进程，内存页表复制，大内存实例可能造成短暂阻塞。

• 传输RDB：网络带宽消耗。

• 加载RDB：Slave加载期间无法提供服务。

优化：尽量开启repl-diskless-sync，Master直接将RDB写入Socket，不经过本地磁盘，提升效率。

2.4 主从模式的局限性

• 无法自动故障转移：Master挂了，需要人工介入提升Slave。

• 写能力单点瓶颈：所有写操作集中在Master。

• 存储能力受单机限制：数据量不能超过单机内存。

三、第二阶段：哨兵（Sentinel）—— 自动故障转移

3.1 哨兵的三大职责

 

职责	说明
监控	每秒向Master/Slave发送PING，检查健康状态
通知	通过API向管理员或其他应用发送告警
自动故障转移	Master下线后，选举新Master，并将其他Slave指向它

 

3.2 主观下线（SDOWN）与客观下线（ODOWN）

• 主观下线（SDOWN）：单个Sentinel实例认为某节点不可达（如PING超时down-after-milliseconds）。

• 客观下线（ODOWN）：多个Sentinel（达到quorum数量）都认为Master下线。

# 配置示例
sentinel monitor mymaster 192.168.1.10 6379 2   # quorum=2
sentinel down-after-milliseconds mymaster 30000 # 30秒无响应判定SDOWN

 

3.3 领导者选举（Raft算法）

客观下线后，Sentinel集群需要选举一个Leader执行故障转移。选举过程：

1. 每个发现ODOWN的Sentinel向其他Sentinel发送SENTINEL is-master-down-by-addr请求，要求投票给自己。

2. 每个Sentinel在一轮选举中只能投一票。

3. 获得半数以上（且≥quorum）票数的Sentinel成为Leader

 

3.4 故障转移流程

Leader Sentinel执行以下步骤：

1. 挑选新Master：优先级（slave-priority）、复制偏移量（offset最大）、RunID最小。

2. 执行slaveof no one：将选中的Slave提升为Master。

3. 重置其他Slave：让其指向新Master，执行slaveof new-master。

4. 通知旧Master：当旧Master恢复后，将其降级为Slave。

 

3.5 脑裂问题与解决方案

脑裂：主从网络分区，旧Master仍在接收写请求，同时Sentinel又提升了一个新Master。恢复后，旧Master的数据会丢失。

 

解决方案：限制主节点写入的最小从节点数量。

 

# 至少要有1个从节点同步成功，才能继续写入
min-replicas-to-write 1
min-replicas-max-lag 10

这样在网络分区时，旧Master因无法同步数据，会拒绝写入，从而减少数据丢失。

四、第三阶段：Redis Cluster —— 真正的分布式

4.1 核心设计

Redis Cluster采用无中心架构，数据自动分片到16384个哈希槽（hash slot），每个Master节点负责一部分槽位。

// 计算key所属槽位
CRC16(key) & 16383

 

 

4.2 集群通信（Gossip协议）

节点之间通过Gossip协议交换信息，包括PING/PONG消息，传播集群拓扑、槽位映射、节点状态等。

• PING：随机选部分节点发送，检测存活。

• PONG：对PING的响应。

• MEET：将新节点加入集群。

4.3 故障检测与Failover

• 半数以上Master认为某Master不可达 → 标记为FAIL。

• 故障Master的Slave发起选举，请求其他Master投票。

• 获得多数票的Slave晋升为新Master。

五、总结：三种模式对比

 

模式	数据量上限	写能力	高可用	复杂度
主从复制	单机内存	单点	需人工干预	低
哨兵	单机内存	单点	自动故障转移	中
Redis Cluster	线性扩展	多点	自动分片+故障转移	高

生产建议：

• 小型项目：主从 + 可选Sentinel。

• 数据量<50GB：主从 + Sentinel。

• 海量数据、高性能要求：Redis Cluster（官方推荐）。

核心配置速查：

# 主从复制
replicaof <masterip> <masterport>
repl-backlog-size 1mb

# 哨兵
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 30000

# 集群
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 15000

如果觉得本文对你有帮助，欢迎点赞、收藏、转发！
关注我，深入Redis内核，持续输出高可用架构干货。