Redis 作为高性能的内存数据库，在缓存、会话存储、消息队列等场景中被广泛使用。然而，单机 Redis 存在明显的单点故障风险，一旦宕机，整个依赖它的业务链路都会受到影响。因此，在生产环境中，Redis 的高可用架构设计是每个后端工程师必须掌握的核心技能，也是面试中的高频考点。本文将从单机部署出发，逐步演进到主从复制、哨兵模式、Cluster 集群，并讨论每种方案的适用场景与面试常见追问。
一、单机模式：起点与瓶颈
单机 Redis 部署简单，适合开发测试或对可用性要求极低的场景。但它有三个致命问题：
- 单点故障：进程崩溃或服务器宕机，服务完全不可用。
- 容量受限：受限于单机内存，无法水平扩展。
- 性能瓶颈：所有请求压在一台机器上，QPS 有上限。
在生产环境中，单机模式几乎不可接受。面试中如果被问到“你们 Redis 怎么部署的”，回答“单机”基本会被追问到哑口无言。
二、主从复制：读写分离与数据冗余
主从复制是 Redis 高可用的第一步。通过 SLAVEOF（或 REPLICAOF）命令，让一个从节点复制主节点的数据。核心价值：
- 数据冗余：主节点宕机后，从节点仍有完整数据。
- 读写分离：主节点写，从节点读，提升读吞吐量。
- 故障恢复基础：为后续哨兵和集群提供数据副本。
但主从复制本身不具备自动故障转移能力。主节点挂了，需要人工介入将从节点提升为主节点，期间服务不可写。因此，主从复制只是高可用的基石，而非完整方案。
面试追问：主从复制的原理是什么？
- 全量同步：从节点首次连接时，主节点生成 RDB 快照发送，期间写命令缓存到 repl_backlog。
- 增量同步：断线重连后，根据 offset 从 repl_backlog 中补发缺失命令。
- 关键参数：
repl-backlog-size、repl-timeout。
三、哨兵模式（Sentinel）：自动故障转移
哨兵模式在主从复制的基础上，引入了一组 Sentinel 进程，负责监控、通知和自动故障转移。
核心能力：
- 监控：持续检查主从节点是否存活。
- 通知：节点异常时向管理员或应用发送告警。
- 自动故障转移：主节点客观下线后，Sentinel 集群选举一个从节点晋升为主节点，并通知其他从节点复制新主。
- 配置中心：客户端通过 Sentinel 获取当前主节点地址。
部署要点：
- Sentinel 本身建议部署至少 3 个节点，且分布在不同的物理机或可用区，避免脑裂。
- 哨兵集群通过 Raft 类协议达成共识，
quorum决定客观下线的票数。 - 客户端需使用支持 Sentinel 的 SDK（如 Jedis、Lettuce），而非直连主节点 IP。
局限性：
- 故障转移期间（通常几秒到几十秒）写操作不可用。
- 未解决容量扩展问题，所有数据仍存于单主节点。
- 主从异步复制可能导致少量数据丢失（取决于
min-replicas-to-write配置）。
面试高频题：哨兵如何判断主节点下线？
- 主观下线（SDOWN）：单个 Sentinel 在
down-after-milliseconds内未收到有效回复。 - 客观下线（ODOWN）：超过
quorum个 Sentinel 都认为主节点主观下线。 - 随后由 Leader Sentinel 执行故障转移。
四、Redis Cluster：分片与高可用兼得
当数据量或吞吐量超过单机上限时，哨兵模式也无能为力。Redis Cluster 是官方提供的分布式方案，核心特性：
- 数据分片：将整个键空间划分为 16384 个槽（slot），每个主节点负责一部分槽。
- 去中心化：节点间通过 Gossip 协议通信，无中心代理。
- 高可用：每个主节点可配置一个或多个从节点，主节点故障时从节点自动晋升。
- 客户端重定向：客户端访问错误节点时，返回 MOVED/ASK 重定向。
架构建议：
- 至少 3 主 3 从，部署在 6 台独立机器上。
- 使用
redis-cli --cluster创建和管理集群。 - 避免使用
KEYS、MGET跨槽操作，必要时用 Hash Tag 将相关键映射到同一槽。
Cluster 的代价：
- 运维复杂度显著上升，扩缩容需迁移槽。
- 不支持多数据库（只有 db0）。
- 批量操作和事务受限。
- 网络分区时可能出现脑裂，需配置
cluster-require-full-coverage和min-replicas-to-write。
面试追问：Cluster 的槽迁移过程是怎样的？
- 目标节点执行
CLUSTER SETSLOT IMPORTING。 - 源节点执行
CLUSTER SETSLOT MIGRATING。 - 逐个迁移键，迁移期间客户端访问返回 ASK 重定向。
- 迁移完成后广播槽归属变更。
五、演进路线总结与选型建议
| 阶段 | 方案 | 可用性 | 扩展性 | 适用场景 |
|---|---|---|---|---|
| 1 | 单机 | 低 | 无 | 开发测试 |
| 2 | 主从复制 | 中（需人工） | 读扩展 | 读多写少，可容忍短暂不可写 |
| 3 | 哨兵模式 | 高（自动） | 读扩展 | 数据量可控，要求自动故障转移 |
| 4 | Cluster | 高（自动） | 水平扩展 | 大数据量、高吞吐生产环境 |
实际生产建议：
- 中小规模业务：哨兵模式 + 客户端连接池，配合合理的
maxmemory-policy。 - 大规模业务：Redis Cluster，配合代理层（如 Codis 或官方集群代理）简化客户端。
- 无论哪种方案，都必须配置持久化（RDB + AOF）、监控告警（如 Prometheus + Grafana）和定期容灾演练。
六、面试常见问题速查
- 主从复制是全量还是增量？ 首次全量，断线重连增量。
- 哨兵集群最少几个节点？ 3 个，且建议奇数。
- Cluster 有多少个槽？ 16384。
- 如何解决脑裂？ 配置
min-replicas-to-write和min-replicas-max-lag。 - 故障转移期间数据会丢吗？ 异步复制下可能丢失少量未同步的写命令。
- 客户端如何感知主节点变更？ 哨兵模式通过 Sentinel 获取，Cluster 通过 MOVED 重定向。
Redis 高可用架构的演进本质是在可用性、一致性、扩展性和运维成本之间做权衡。理解每种方案的原理与边界，才能在面试和实际生产中都做出合理决策。
未经允许不得转载：任鹏个人博客 » Redis 在生产环境中的高可用架构演进方案
