Redis主从同步、哨兵、集群原理及应用场景

Redis主从同步、哨兵、集群原理及应用场景
我们分三大块：

1️⃣ 主从同步
2️⃣ 哨兵机制（Sentinel）
3️⃣ 集群机制（Cluster）

每块都包含 原理 + 图解 + 问题 + 应用场景。
确认对你的面试命中。

---

🟦 1️⃣ Redis 主从同步（Replication）

主节点（Master）写，多个从节点（Replica/Slave）读，实现读写分离和数据冗余。

---

🔍 同步阶段图解

⭐ 初次同步（全量同步）

Master --------- RDB快照 + 复制缓冲区（增量） --------> Slave
Slave加载RDB，执行增量命令，追上主

过程：

1. Slave 发 PSYNC 指令给 Master
2. Master 生成 RDB（fork 子进程）
3. 在发送 RDB 时，主继续处理写请求 → 写入复制缓冲区
4. Slave 加载 RDB → 再执行增量命令 → 完成同步

---

⭐ 增量同步

当 Slave 掉线短暂恢复时：

只根据 repl_offset 继续拉取未同步命令
无需全量！

但如果缓冲区已覆盖，则又回退到全量同步。

⭐ 因此复制缓冲区一定要设置足够大：

repl-backlog-size 512mb

---

主从架构优缺点

优势	风险点
读写分离	主挂了整个系统不可写
降低主压力	主从延迟
容灾能力	不自动切主

---

📌 应用场景

• 高并发读请求（缓存、榜单、热门页面）
• 灾备：主节点宕机可恢复服务

---

🟥 2️⃣ Redis 哨兵（Sentinel）——主从自动故障切换

自动监控主节点，一旦 Master 宕机，由 Sentinel 选举新主。

---

Sentinel 架构示意

         ┌────────────┐
         │ Sentinel1  │
         └─────┬──────┘
               │
        ┌──────▼──────┐
        │   Master    │
        └──┬─────┬────┘
           │     │
     ┌─────▼─┐ ┌─▼─────┐
     │Slave1 │ │Slave2 │
     └───────┘ └───────┘

多个 Sentinel（≥3）互相通信，投票裁决 Master 是否下线。

---

🌟 故障切换流程（必记）

1. Subjectively Down（SDOWN）
   Sentinel 自己认为主不可达（主观）
2. Objectively Down（ODOWN）
   多数 Sentinel 都同意主挂了（客观）
3. 选举领导 Sentinel（Raft-like）
4. 该 Sentinel 将一个 Slave 提升为 Master
5. 其他 Slave 改为同步新主
6. 原 Master 恢复后 → 降级为 Slave

---

Sentinel 优缺点

优势	风险点
自动故障转移	主从延迟可能导致数据丢失
服务发现（新 Master IP）	存在脑裂风险
多 Sentinel 保障可靠性	配置复杂度上升

---

📌 应用场景

• Redis 主从写多读少体系
• 单个主节点性能足够但需要高可用

---

🟩 3️⃣ Redis Cluster（分布式集群）

分片 + 高可用，解决 容量瓶颈 + 吞吐瓶颈 + 单点问题

---

🔥 Hash Slot 分片机制（重点）

整个集群使用 16384 个槽位（slot）

hash_slot = CRC16(key) % 16384

槽位均匀映射到多个主节点：

      Hash Slot 分片
         │
 ┌───────┴────────┐
Node A   Node B   Node C
1-5500 5501-11000 11001-16384

---

主从架构 + 自动 Failover

每个主节点至少有一个从：

   Master1 <-> Slave1
   Master2 <-> Slave2
   Master3 <-> Slave3

某个主挂了：

• 它的 Slave 自动提升为 Master
• 客户端自动路由请求到新节点

---

路由方式

客户端负责路由，不是 Cluster Proxy：

• ASK、MOVED 重定向
• 可自动进行 key 重定位

⛔ 多键操作必须 Key 在同一个 slot
解决方式：HASH TAG

key1:{user1001}
key2:{user1001}

相同 {} 内的字符串计算 slot

---

Cluster 优缺点

优势	风险点
水平扩容	复杂度高
自动 failover	无多 key 跨节点事务
分布式高性能	运维要求提升
数据自动分片	客户端必须支持 Cluster 协议

---

📌 应用场景

• 大规模热点数据（亿级用户）
• 高吞吐、分布式系统
• 热点分区、游戏排行榜、直播间计数

---

🧠 三者定位对比总结（面试一句话回答）

能力	主从	Sentinel	Cluster
高可用	❌	✔	✔
自动故障切换	❌	✔	✔
水平扩容	❌	❌	✔
分布式分片能力	❌	❌	✔
运维复杂度	低	中	高

---

面试官常问：选型建议

场景	推荐方案
单节点性能够，要求 HA	主从 + Sentinel
数据量大，需要扩容	Cluster
高并发读场景	主从读写分离
对数据一致性要求高	谨慎使用 Redis，必要时加强持久化策略

---

给你一句大杀器总结

主从解决读扩展，Sentinel解决主挂自动切换，Cluster解决容量和性能的极限扩展。