高可用方案

Redis 高可用是生产环境的必备能力，主要通过主从复制、哨兵和集群三种方案实现。

三种方案对比 ⭐⭐⭐⭐⭐

方案	高可用	自动故障转移	水平扩展	适用场景
主从复制	❌	❌	❌	读写分离
哨兵模式	✅	✅	❌	中小规模，自动容灾
集群模式	✅	✅	✅	大规模，海量数据

---

主从复制 ⭐⭐⭐⭐⭐

核心原理

主从复制实现读写分离和数据备份。

┌─────────┐  写请求
│  Master │ ◄────────  Client
└────┬────┘
     │ 数据同步
     ├──────────┐
     ▼          ▼
┌─────────┐  ┌─────────┐  读请求
│ Slave 1 │  │ Slave 2 │ ◄────────  Client
└─────────┘  └─────────┘

配置从节点：

# 从节点执行
REPLICAOF master_ip master_port
# 或配置文件
replicaof 192.168.1.100 6379

复制流程 ⭐⭐⭐⭐⭐

全量同步（首次连接或重连）：

1. Slave 发送 PSYNC 命令
2. Master 执行 BGSAVE 生成 RDB
3. Master 发送 RDB 文件给 Slave
4. Slave 清空旧数据，加载 RDB
5. Master 发送 RDB 生成期间的增量命令

增量同步（正常运行）：

1. Master 执行写命令
2. 命令写入 replication buffer
3. 异步发送给所有 Slave
4. Slave 执行命令，保持数据一致

复制偏移量与积压缓冲区

replication backlog（复制积压缓冲区）：

• 固定大小的环形队列，默认 1MB

• 记录最近的写命令

• 用于断线重连后的部分重同步

复制偏移量：

• Master 和 Slave 各自维护偏移量

• Slave 断线重连时，通过偏移量判断是否需要全量同步

# 配置积压缓冲区大小
repl-backlog-size 1mb

主从复制的问题

1. 不支持自动故障转移：Master 宕机需手动切换

2. 写能力受限：只有一个 Master 可写

3. 存储容量受限：单机内存限制

---

哨兵模式 ⭐⭐⭐⭐⭐

架构

哨兵（Sentinel）是独立进程，监控 Redis 实例并自动故障转移。

┌──────────┐  ┌──────────┐  ┌──────────┐
│Sentinel 1│  │Sentinel 2│  │Sentinel 3│  ← 哨兵集群（奇数个）
└────┬─────┘  └────┬─────┘  └────┬─────┘
     └──────────┬──────────────┘
                ▼ 监控
         ┌─────────┐
         │  Master │
         └────┬────┘
              │ 主从复制
         ┌────┴────┐
         ▼         ▼
    ┌────────┐ ┌────────┐
    │ Slave 1│ │ Slave 2│
    └────────┘ └────────┘

核心功能

1. 监控：检查 Master 和 Slave 是否正常

2. 通知：通过 API 通知管理员故障信息

3. 故障转移：自动将 Slave 提升为 Master

4. 配置中心：客户端通过哨兵获取 Master 地址

故障转移流程 ⭐⭐⭐⭐⭐

1. 主观下线（SDOWN）
   - 某个哨兵认为 Master 下线（超时未响应 PING）

2. 客观下线（ODOWN）
   - 达到法定数量（quorum）的哨兵都认为 Master 下线

3. 选举 Leader 哨兵
   - 哨兵之间通过 Raft 算法选举 Leader
   - Leader 负责执行故障转移

4. 选择新 Master
   - 优先级最高（replica-priority）
   - 复制偏移量最大（数据最新）
   - run_id 最小

5. 执行故障转移
   - 向选中的 Slave 发送 SLAVEOF NO ONE（提升为 Master）
   - 其他 Slave 执行 REPLICAOF 新 Master
   - 通知客户端新 Master 地址

关键配置

# sentinel.conf
sentinel monitor mymaster 192.168.1.100 6379 2  # 2 = quorum
sentinel down-after-milliseconds mymaster 5000  # 5秒判定下线
sentinel failover-timeout mymaster 60000        # 故障转移超时

哨兵模式的局限

1. 写能力和存储容量无法扩展：仍是单 Master

2. 配置复杂：需要部署多个哨兵进程

3. 不支持数据分片：所有数据在一个 Master

---

集群模式 ⭐⭐⭐⭐⭐

架构

Redis Cluster 通过分片实现水平扩展和高可用。

数据分片：16384 个槽（slot）分配到多个 Master

┌─────────────────────────────────────────────────────┐
│          Master 1        Master 2        Master 3   │
│          (0-5460)       (5461-10922)  (10923-16383) │
│             │               │               │       │
│          Slave 1         Slave 2        Slave 3     │
└─────────────────────────────────────────────────────┘

槽分配算法：CRC16(key) % 16384 = slot

槽分配 ⭐⭐⭐⭐⭐

哈希槽：Redis Cluster 将数据分为 16384 个槽（slot）。

计算公式：

slot = CRC16(key) % 16384

Hash Tag（强制相同槽）：

# {user}123 和 {user}456 会被分配到同一个槽
SET {user}123 "data1"
SET {user}456 "data2"

请求路由 ⭐⭐⭐⭐

MOVED 重定向：

1. 客户端向节点 A 发送请求
2. 节点 A 发现槽不在自己这里
3. 返回 MOVED 错误，告知正确节点
4. 客户端缓存槽-节点映射，下次直接请求正确节点

ASK 重定向（槽迁移中）：

槽正在从节点 A 迁移到节点 B：
- 如果 key 已迁移 → 返回 ASK，客户端临时请求节点 B
- 如果 key 未迁移 → 节点 A 处理

扩容与缩容

添加节点：

# 1. 启动新节点
redis-server --cluster-enabled yes

# 2. 加入集群
redis-cli --cluster add-node 新节点IP:端口 已有节点IP:端口

# 3. 重新分配槽
redis-cli --cluster reshard 集群任意节点IP:端口

槽迁移流程：

1. 向目标节点发送 CLUSTER SETSLOT <slot> IMPORTING
2. 向源节点发送 CLUSTER SETSLOT <slot> MIGRATING
3. 逐个迁移槽中的 key（MIGRATE 命令）
4. 通知所有节点槽的新归属

故障转移

自动故障转移（无需哨兵）：

1. 集群中超过半数 Master 认为某个 Master 下线
2. 该 Master 的 Slave 发起选举
3. 获得多数投票的 Slave 晋升为 Master
4. 新 Master 接管槽，继续提供服务

集群模式的限制

1. 不支持多数据库：只能使用 db0

2. 批量操作受限：MGET/MSET 的 key 必须在同一槽

3. 事务受限：事务中的 key 必须在同一槽

4. 复制结构固定：只支持一层主从，不支持级联

---

方案选型 ⭐⭐⭐⭐⭐

场景推荐

场景	推荐方案	理由
小规模，QPS < 10W	主从 + 哨兵	配置简单，满足需求
中等规模，需自动容灾	哨兵模式	自动故障转移，运维成本低
大规模，数据量大	集群模式	水平扩展，突破单机限制
纯缓存，可丢失数据	主从复制	成本最低

对比总结

主从复制：最简单，但无容灾能力
哨兵模式：主从 + 自动故障转移
集群模式：哨兵 + 分片 + 水平扩展

进化路线：主从 → 哨兵 → 集群

---

面试要点 ⭐⭐⭐⭐⭐

Q1: 主从复制的全量同步和增量同步如何区分？

• 全量同步：首次连接或 replication backlog 无法覆盖时，传输整个 RDB

• 增量同步：正常运行时，Master 异步发送写命令给 Slave

Q2: 哨兵如何判断 Master 下线？

• 主观下线（SDOWN）：单个哨兵超时未收到 PING 响应

• 客观下线（ODOWN）：达到 quorum 数量的哨兵都认为下线

Q3: 哨兵如何选择新 Master？

1. 优先级最高（replica-priority）

2. 复制偏移量最大（数据最新）

3. run_id 最小（启动时间最早）

Q4: Redis Cluster 为什么是 16384 个槽？

• 足够大，支持 1000+ 节点

• 槽信息通过心跳传输，16384 个槽的位图只需 2KB

• 太大会增加心跳包大小

Q5: 集群模式下如何执行 MGET？

• 方案 1：客户端拆分为多个单 key 请求

• 方案 2：使用 Hash Tag 强制 key 在同一槽

• 方案 3：使用支持集群的客户端（如 Jedis Cluster）

Q6: 哨兵和集群的故障转移有什么区别？

• 哨兵：依赖独立的哨兵进程，通过 Raft 选举 Leader

• 集群：Master 节点内置故障检测，Slave 自主发起选举

Q7: 为什么不推荐使用主从复制而不用哨兵？

• 主从复制无自动故障转移，Master 宕机需手动切换，可用性差

---

参考资料

1. 官方文档：Redis Replication、Redis Sentinel、Redis Cluster

2. 书籍推荐：《Redis 设计与实现》、《Redis 开发与运维》