目标

理解一下 redis 单点、哨兵、集群模式

chat

redis 的三种部署模式

理解 Redis 的三种部署模式（单点、哨兵、集群）是掌握 Redis 架构设计的关键。

我们可以从以下六个角度来系统理解它们：

🌱 1. 概念与架构 ⚙️ 2. 读写机制 💀 3. 故障转移机制 🌐 4. 客户端访问方式 ⚡ 5. 优缺点对比 🧭 6. 典型使用场景

🧩 一、单点模式（Standalone）

🏗️ 架构概念

最简单的 Redis 部署方式：

只有一个 Redis 实例（一个进程），负责所有数据读写。

Client  ⇆  Redis Server
  • 所有 key 都存储在这个单实例中；
  • 不存在主从复制；
  • 不存在自动容灾机制。

⚙️ 读写机制

  • 所有命令都直接在一个 Redis 实例上执行；
  • 数据保存在内存中，定期通过 RDB / AOF 落盘。

💀 故障转移

  • 无高可用机制：Redis 一旦挂掉，业务就不可用；
  • 需要人工重启或脚本监控。

🌐 客户端连接

  • 直接指定一个 IP + 端口；
  • 配置简单；
  • 不需要任何额外中间层。
spring.redis.host: 127.0.0.1
spring.redis.port: 6379

⚖️ 优缺点

优点 缺点
架构简单，易部署 单点故障，无法自动恢复
性能高，无主从延迟 无高可用
配置最少 无扩展性

🧭 典型场景

  • 本地开发环境；
  • 单机小项目；
  • 临时缓存或测试用途。

🛰️ 二、哨兵模式（Sentinel）

🏗️ 架构概念

Sentinel 模式 = 主从复制 + 自动故障转移。

它由：

  • 1 个主节点（Master）
  • 若干从节点（Slave）
  • 若干 Sentinel 监控节点组成。
        +----------------+
        |   Sentinel A   |
        +----------------+
              |
              | monitor
              v
+---------+         +---------+
|  Master | <-----> |  Slave1 |
+---------+         +---------+
       ^                 |
       |                 v
       |           +---------+
       |           |  Slave2 |
       |           +---------+
       |
       +------> Sentinels detect & promote Slave

⚙️ 读写机制

  • 写操作 → 发送到 主节点（Master）
  • 读操作 → 可发到 主节点或从节点（可读从）
  • 从节点通过 复制（replication） 同步主节点数据

💀 故障转移机制

  1. Sentinel 通过心跳监控 Master；
  2. 若超过 down-after-milliseconds 未响应；
  3. Sentinel 进入 “主观下线（SDOWN）”；
  4. 多个 Sentinel 协商（投票）一致后确认 “客观下线（ODOWN）”；
  5. 从节点中选举一个新 Master；
  6. 客户端更新新的 Master 地址并继续工作。

整个过程是自动化的主从切换。

🌐 客户端连接方式

客户端不会直接连接固定主节点，而是：

  • 连接到哨兵（Sentinel）；
  • Sentinel 通知客户端当前的主节点是谁。

Spring Boot 示例：

spring.redis.sentinel.master: mymaster
spring.redis.sentinel.nodes: host1:26379,host2:26379,host3:26379

⚖️ 优缺点

优点 缺点
自动主从切换，高可用 主从切换时短暂不可用
读写分离可提升性能 写性能受限（仍为单主）
支持横向扩展读节点 无法分片扩容
Sentinel 可动态发现 Master 配置复杂度略高

🧭 典型场景

  • 需要高可用但数据规模不大的中小型系统；
  • 常见于微服务缓存层；
  • 一主多从结构。

⚙️ 三、集群模式（Cluster）

🏗️ 架构概念

Redis Cluster 是 Redis 官方提供的 分布式高可用方案。

通过哈希槽（Hash Slot）机制实现数据分片与节点自治。

架构如下：

     +---------+    +---------+    +---------+
     | Master1 |    | Master2 |    | Master3 |
     +---------+    +---------+    +---------+
        |  \           |  \           |  \
        |   \          |   \          |   \
     +------+      +------+      +------+
     |Slave1|      |Slave2|      |Slave3|
     +------+      +------+      +------+

      (16384 slots 分配到各 Master)

⚙️ 读写机制

  • 每个 Master 负责部分 key（通过 16384 个槽位分配）；
  • 写操作 → 发到该 key 所在的 Master；
  • 读操作 → 默认 Master，也可读 Slave；
  • 从节点仅负责数据冗余，不参与写入。

💀 故障转移机制

  • 每个节点都保存集群拓扑；
  • 节点间通过 gossip 协议通信；
  • Master 掉线后，其 Slave 自动晋升为新 Master；
  • 客户端可自动重定向（MOVED/ASK）。

🌐 客户端连接方式

客户端必须是 支持 Redis Cluster 协议的客户端：

spring.redis.cluster.nodes: host1:7001,host2:7002,host3:7003
spring.redis.cluster.max-redirects: 3

RedisTemplate / Lettuce / JedisCluster 都会自动路由请求。

⚡ 哈希槽（Hash Slot）机制详解

  • Redis Cluster 把整个 key 空间划分为 16384 个 slot；
  • 每个 Master 管理一部分 slot；

  • key 对应 slot 的算法：

    slot = CRC16(key) % 16384
  • 客户端通过槽位路由到正确节点；

  • 若 key 落在其他节点，Redis 会返回：

    MOVED slot 127.0.0.1:7002

    客户端随后会更新本地路由缓存。

⚖️ 优缺点

优点 缺点
真正的水平扩展（分片） 不支持跨节点事务
自动高可用 管理复杂
故障自动转移 pipeline / Lua 跨 slot 受限
数据分散存储 部分命令（如 keys, mget）受限

🧭 典型场景

  • 大规模缓存；
  • 分布式会话、排行榜；
  • 数据量 > 单机内存；
  • 高可用 + 水平扩展要求。

🧮 四、三种模式的对比总览

特性 Standalone Sentinel Cluster
数据副本 1 1主+多从 多主多从
容错能力 ❌ 无 ✅ 有 ✅ 有
扩展性 ❌ 无 ❌ 读扩展 ✅ 水平扩展
自动故障转移 ❌ ✅ ✅
支持分片 ❌ ❌ ✅
支持事务 ✅ ✅ ⚠️ 仅单 slot
支持 pipeline ✅ ✅ ⚠️ 仅单节点
客户端复杂度 低 中 高
推荐场景 开发/测试 高可用中小项目 大规模高并发系统

🧭 五、一个形象类比

类比场景 描述
单点模式 一台单独的服务器，老板干所有活，累死算你的。
哨兵模式 老板+几个备份员工，老板倒下时备份自动顶上。
集群模式 多个分店（各干一部分活），每个分店都有副店长备用。

✅ 六、总结一句话：

  • 单点模式：简单高效，但没高可用。
  • 哨兵模式：高可用 + 主从复制，适合中小规模。
  • 集群模式：分片 + 高可用，适合大规模高并发场景。

小结

理解为什么这样，反而比直接知道答案更加重要。