Redis的架构

Redis哨兵机制

先问一个问题：如果你的 Redis 挂了，会发生什么？

• 缓存全部失效
• 接口大量报错
• 数据库被打爆
  如何进行解决？

Redis 主从 + 哨兵机制

先理解主从架构

假设我们有：1 台主节点（Master），1 台从节点（Slave）
客户端–>Master–>Slave
作用：

• 写操作 → Master
• 读操作 → Slave（可选）
• Slave 同步 Master 数据
  这叫 主从复制。
  但是当Master挂了，Slave并不会自动变为Master。
  所以哨兵就出现了。

什么是 Redis 哨兵（Redis Sentinel）？

本质：一个“监控 + 自动故障转移”的系统

实现了哪些效果

1. 监控 Redis
2. 自动切换主节点
3. 通知客户端

我们来给形象的比喻

我们将

• Master = 小区老板
• Slave = 副老板
• Sentinel = 保安
  哨兵的核心逻辑就是
  当一切照旧，保安会看护着老板，一旦当老板倒下。
  1.保安便会确认是不是真的倒了
  2.然后投票
  3.推选一个副老板上位
  4.通知所有客户：新老板在这！

哨兵是怎么判断主节点挂了？

1. 第一步：主观下线（SDOWN）
   如果一个哨兵发现：在指定时间内，主节点没有响应
   它会认为： 主观下线
2. 第二步：客观下线（ODOWN）
   如果多个哨兵都认为主节点挂了：并且超过法定票数。
   于是客观下线成立。
   才会开始真正的主从切换。

主从切换过程

当确认 Master 挂了：

1. 哨兵选举出一个 Leader
2. Leader 选出一个最合适的 Slave
3. 把它升级为新的 Master
4. 让其他 Slave 重新指向新 Master
5. 通知客户端更新地址

整个过程是自动完成的。
这叫： 自动故障转移（Failover）

一个常见误区

哨兵会保存数据吗？

不会

总结

Redis 哨兵机制的核心就是：

自动监控 + 自动选举 + 自动切换。

Redis集群简介

一、先问一个问题

如果你的 Redis 数据量越来越大：一台机器还能撑住吗？、
即使能撑住：

• 内存成本高
• 单点风险大
• 性能瓶颈明显
  于是我们的Redis 集群模式就出现了（Redis Cluster）

对比：哨兵解决什么？集群解决什么？

模式	解决问题
主从 + 哨兵	高可用
集群	高可用 + 数据分片

哨兵解决“挂了怎么办”
集群解决“太大怎么办”

什么是 Redis 集群？

把数据拆分到多台 Redis 上存储。

以前是：一台仓库装所有货
现在是：多个仓库分开存货
这叫：数据分片（Sharding）

如何分片的？

核心机制 是哈希槽
简单来说Redis有2^14槽
所有key会都过计算，被平均分配到某一个槽
然后：每个 Redis 节点负责一部分槽。

集群如何保证高可用？

每个主节点都会有从节点。
Master1 —— Slave1
Master2 —— Slave2
Master3 —— Slave3
类似于哨兵，但更高级。

集群怎么做到扩容

假设原来 3 个节点，现在要加第 4 个。

• 新节点加入
• 从老节点迁移一部分槽
• 数据同步完成
  这个过程叫槽迁移
  优点：
• 不需要停机
• 可以平滑扩容

集群的优点

• 数据分布式存储
• 支持水平扩展
• 自动故障转移
• 没有单点问题

集群的缺点

• 架构复杂
• 运维成本高
• 不支持多 key 跨槽事务

哨兵 vs 集群

对比	哨兵	集群
数据是否分片	❌ 否	✅ 是
是否高可用	✅ 是	✅ 是
是否支持大规模扩展	一般	强
架构复杂度	较低	较高

核心总结

Redis 集群的本质是：

用哈希槽实现数据分片，用主从复制实现高可用。

用于解决

• 数据太大
• 单机性能瓶颈
• 单点故障风险