---

Redis 已成为互联网系统里最常用的缓存与轻量数据库之一。

面对不同的业务负载与可用性要求，Redis 的部署架构会有很大差别：单机、主从复制（Master-Slave）、哨兵（Sentinel）高可用、Cluster（分片）以及一些工程化替代方案（Proxy、客户端分片等）。

---

一、Redis 三大核心模式

模式	核心作用	高可用	水平扩展	通俗理解（实操角度）
主从复制（Master-Slave）	数据复制、读扩展	❌（需 Sentinel 或其他方案实现高可用）	❌	写数据到主节点，多个从节点帮忙读取，减轻主节点压力。如果主节点挂了，业务会受影响，需要人工干预。
哨兵模式（Sentinel）	节点监控 + 自动故障切换	✔（依赖主从架构）	❌	监控已有主从架构，主节点宕机时自动选一个从节点顶上，业务基本不中断。它本身不存数据，也不做复制。
集群（Cluster）	分片 + 自动 failover	✔	✔	数据按 key 分片到不同节点，每个节点可有副本，读写压力分散，高并发大数据量下稳定运行。

---

核心记忆点

1. 主从 = 数据复制 + 读扩展

   想象写作业：主节点写作业，从节点帮忙抄副本来读。主节点挂了，作业还在，但得找人顶上。

2. Sentinel = 高可用监控 + 自动选主

   有老师监控，主节点出事时，老师选一个副节点顶上。注意：哨兵自己不存数据，只管监控和切换。

3. Cluster = 分片 + 高可用 + 水平扩展

   把作业拆成多个部分，不同小组处理，每组有副本。流量大也不会卡。分片和副本都保证高并发和数据安全。

---

二、基础概念

1. 单机（Standalone）：一个 Redis 实例，读写请求都在同一个节点。

2. 主从复制（Master/Replica）：Master 节点写，Replica 节点读，可分担读压力。

3. 哨兵（Sentinel）：监控主从节点状态，Master 宕机时自动切换。

4. Redis Cluster：通过 hash slot 分片到多个 Master 节点，每个 Master 可有 Slave，支持水平扩展和高可用。

5. 持久化：RDB（快照）、AOF（操作日志）

6. 客户端分片 / Proxy：客户端或代理负责 key 路由，适合不使用 Cluster 的分片方案。

---

三、Redis 架构详解

3.1 单机 Redis（Standalone）

原理

• 单个 Redis 实例处理所有请求

• 支持 RDB / AOF 持久化，也可以纯内存缓存

高可用机制

• 无高可用：单点故障（SPOF），节点宕机数据不可用

工作流程

1. 客户端请求 key

2. Redis 直接读写内存

3. 可配置 RDB / AOF 持久化保存数据

工程理解

就像一个人自己做作业、自己查资料，一切都在一个地方完成。操作最快，但一旦这个人休息了，作业就无法完成。

优缺点

优点	缺点
部署简单	单点故障（SPOF）
延迟低	内存受限
调优容易	无读扩展

适用场景

• 开发环境

• 小流量缓存

• 本地 L1 缓存

工程实践建议

• 设置 maxmemory + LRU/LFU 淘汰策略

• 根据需求选择 RDB / AOF

• 监控慢命令、内存碎片率、CPU 使用

---

3.2 主从复制（Master-Slave）

原理

• Master 节点负责写操作

• Slave 节点异步复制 Master 数据

• Slave 节点可分担读请求，减轻 Master 压力

• 初次启动进行全量同步，之后增量同步

高可用机制

• 不自动切换：Master 宕机需人工干预

• 可结合 Sentinel 自动选举 Master

工作流程

1. 客户端写入 Master

2. Slave 异步复制数据

3. 客户端读请求可发送到 Slave

4. Master 宕机：

   • 无 Sentinel → 手动提升 Slave

   • 有 Sentinel → 自动选举新 Master

工程理解

写入主节点，副节点帮忙读取，减轻主节点压力，但副节点数据可能落后，存在短暂延迟。

优缺点

优点	缺点
提供读扩展	异步复制可能延迟
数据备份	Master 写压力大
简单易用	自动高可用需 Sentinel

适用场景

• 读多写少

• 数据备份

工程实践建议

• 监控复制延迟（replication_lag）

• 客户端实现读写分离

• Slave 不承接写负载

---

3.3 Sentinel 高可用模式

原理

• 基于主从架构（Master-Slave）

• Sentinel 监控 Master / Slave 状态

• Master 宕机时，自动选举最合适的 Slave 升级为 Master

---

高可用机制

• 自动故障切换（Failover）

  当 Master 宕机时，Sentinel 会自动选出一个 Slave 升级为 Master，保证业务继续可用。

• Slave 选举规则

  1. 只有属于宕机 Master 的 Slave 才能被提升

  2. Slave 必须在线，且能与大多数 Sentinel 节点通信

  3. 优先选择与 Master 同步偏移量最大、数据最完整的 Slave

  4. Sentinel 通过投票选出新 Master（大多数 Sentinel 投票通过）

  5. 其他 Slave 跟随新 Master，重新同步数据

  6. 客户端更新 Master 地址，继续读写

• 注意事项

  • Sentinel 节点数必须为奇数，避免投票平局

  • Failover 期间短暂不可写，可能存在少量脏数据

  • 网络分区可能导致 split-brain，需要多 Sentinel 节点和监控

---

工作流程

1. Sentinel 监控 Master 心跳

2. Master 宕机 → Sentinel 发起投票，选择最合适的 Slave 升级为 Master

3. 其他 Slave 重新跟随新 Master 同步数据

4. 客户端通过 Sentinel 获取新的 Master 地址，继续正常访问

---

工程理解

Sentinel 就像老师监督班级作业，如果班长生病，老师通过投票选副班长顶上，并让其他同学跟随，确保作业继续完成。

---

优缺点

优点	缺点
自动故障切换	Sentinel 自身需高可用（奇数节点）
自动发现 Master	Failover 期间短暂不可写，可能有脏数据
易于中小型业务使用	网络分区可能 split-brain

---

适用场景

• 中小型生产环境

• 读多写少

• 需要自动故障切换

---

工程实践建议

• Sentinel 节点分布不同机房，提高容灾能力

• 客户端支持自动发现 Master

• 监控 failover 时间、投票选主过程和 Slave 同步状态

• 为 Master 配置 1~2 个 Slave，保证 failover 成功

---

3.4 Redis Cluster（分片 + 高可用）

原理

• 数据按 16384 个 hash slot 分布到多个 Master 节点

• 每个 Master 可配置一个或多个 Slave 节点

• 客户端通过 key hash 自动路由到对应 Master

• Master 宕机时，Slave 自动升主，保证高可用

Redis Cluster 不是按 key 哈希到节点，而是：先哈希到槽（slot），再把槽分配给节点。
key → CRC16(key) % 16384 → slot → node

---

高可用机制

• 自动故障切换（Auto Failover）

  当 Master 宕机且存在 Slave 时，Cluster 会自动选择合适的 Slave 提升为 Master。

• Slave 选举规则

  1. 只有属于宕机 Master 的 Slave 才能被提升

  2. 必须是在线且能与大多数 Master 通信的节点

  3. 优先选择与 Master 同步偏移量最大、数据最完整的 Slave

  4. 集群大多数 Master 投票通过后，Slave 才能正式升级为 Master

  5. 其他 Slave 重新跟随新 Master，客户端更新路由

⚠️ 重点：Cluster 的自动 failover 并不是随机选择 Slave，而是“数据最完整 + 集群投票”，避免数据丢失和 split-brain

如果 Redis Cluster 中 Master 投票出现平票（无法形成多数），结果只有一个：❗ 不会发生主从切换（Failover 失败）
一旦允许，就可能出现多个 Master，导致脑裂！

• 限制：跨 slot 的多 key 操作受限，客户端必须支持 Cluster 协议

---

工作流程

1. 客户端访问 key → 计算 hash slot → 路由到对应 Master

2. Master 写入数据

3. Slave 异步复制 Master 数据

4. Master 宕机 → Cluster 自动选举最合适的 Slave 升级为 Master

5. 其他 Slave 跟随新 Master，同步数据

6. 客户端更新路由表，继续正常读写

---

工程理解

想象把作业拆成多个小组，每组负责一部分，并且每组有备份。即使某组成员出问题，其他小组仍能继续完成整体作业。

---

优缺点

优点	缺点
水平扩展	跨 slot 多 key 操作受限
自动 failover	扩容/迁移复杂
分布式读写	客户端必须支持 Cluster

---

适用场景

• 高并发、大数据量

• 写压力大、高可用需求

---

工程实践建议

• 合理设计 key，使相关 key 同 slot（hash tag {user:123}:profile）

• 监控 slot 分布、Master/Slave 节点负载、复制延迟

• 扩容使用 redis-cli --cluster reshard，确保数据均衡

• 定期演练 failover，熟悉自动提升 Slave 的过程

• 保证每个 Master 至少配置 1~2 个 Slave，避免无法 failover

---

3.5 客户端分片 / Proxy 层（Twemproxy / Codis）

原理

• 客户端或 Proxy 按规则把 key 分片到不同 Redis 节点

• 不改 Redis 源码

• 客户端或 Proxy 需保证高可用

高可用机制

• Proxy 或客户端需支持节点故障转移

• re-sharding 需额外协调

工程理解

客户端/Proxy 像家长分配作业给不同孩子，并记住谁做哪一部分。灵活但可能出错。

优缺点

优点	缺点
无需改 Redis 源码	Proxy 或客户端可能成为瓶颈
部署灵活	re-sharding 需额外协调
支持连接池、故障屏蔽	事务、多 key 命令可能不支持

适用场景

• 过渡性扩容

• 不想使用 Cluster

---

3.6 跨数据中心 & 多活（Active-Active）

工程理解

• Redis 本身不保证跨机房强一致性

• 必须结合 DB / MQ / CRDT 保证最终一致性

常用方案

1. 主从 + DB/CDC → Redis 仅作缓存，DB 为权威

2. CRDT / 商业多活 → 冲突自动合并

3. 地域隔离 + 写回主 DC → 本地缓存加速，最终写入主中心

⚠️ 建议：大多数业务不要直接做 Redis 多活写

---

3.7 持久化（RDB / AOF）

类型	原理	优点	缺点
RDB	定期快照	文件小、恢复快	数据丢失窗口
AOF	记录每条写命令	数据安全性高	文件大、恢复慢

工程实践

• 缓存型 Redis → RDB 或不开持久化

• 核心数据 → AOF 每秒 fsync

• 常用混合模式 → RDB + AOF

---

3.8 高可用 / 灾备组合设计

组合方式	特点	适用场景
主从 + Sentinel	中小型高可用，低成本	中小型业务
Cluster + 多副本	高吞吐、高可用	大规模、高并发业务
读写分离 + MQ/CDC	最终一致性保证	金融等核心业务
热备 + 冷备	离线数据恢复	大规模数据恢复

工程实践建议

• 先满足业务可用性与容量，再优化扩展与高可用

• 定期演练 failover 与扩容

• 对核心数据，Redis 仅做缓存，DB + CDC 保证最终一致性

---

四、结语

• 单机 = 一个人做所有事 → 简单，易理解，但单点故障

• 主从 = 写主节点，读副本 → 减轻读压力，副本有延迟

• Sentinel = 老师监督 + 自动顶替 → 自动故障切换

• Cluster = 分组 + 每组有备份 → 高并发、高可用

• 客户端分片 / Proxy = 家长分作业 → 灵活，但需保证管理层稳定

• 多活 / 跨机房 = 分布式协调 + 最终一致性 → 复杂且高风险

Redis 架构选择不是越复杂越好，关键是 根据业务需求落地：

1. 简单场景

   • 建议：单机 或 主从 + Sentinel

   • 特点：部署简单、延迟低、容易理解

   • 适用：开发环境、小流量缓存、读多写少的中小型业务

2. 大规模、高吞吐量场景

   • 建议：Cluster + 多副本

   • 特点：数据分片、读写分散、高可用

   • 适用：高并发、大数据量业务，如电商、社交、流量热点服务

3. 核心业务数据

   • 建议：Redis 仅作缓存，最终数据由 DB + CDC 保证一致性

   • 特点：Redis 快速响应，DB 保证数据权威性

   • 适用：金融、交易、计费等对数据准确性要求高的业务

💡 落地原则记忆法：
“先能用，再能扛，再保准”

• 先能用 → 满足业务可用性和容量
• 再能扛 → 考虑扩展和高并发
• 再保准 → 核心数据依靠数据库保证最终一致性

---