生产高可用方案选型

三种方案的定位

Redis 在生产环境中，有三大主流的高可用方案，分别面向不同的业务需求：

方案一：主从+哨兵

架构

[客户端]
    ↓
[哨兵集群（3 个哨兵）]
    ↓
[主节点] ←→ [从节点 1] ←→ [从节点 2]

适用场景

• 数据量可控：总数据量不超过单机内存（通常 <64GB）
• 需要完整功能：事务、Lua 脚本、多 Key 操作
• 运维能力一般：架构简单，易于管理和排查问题
• 应用场景：用户会话缓存、简单的排行榜、计数器

推荐配置

3 个哨兵（quorum=2）
1 个主节点 + 2 个从节点
min-replicas-to-write 1
min-replicas-max-lag 10

优缺点

优点：
– 架构简单，部署快捷
– 支持所有 Redis 功能
– 成熟稳定，资料丰富

缺点：
– 写性能受限于单节点
– 总容量受限于单机内存
– 横向扩展困难

方案二：Redis Cluster

架构

[客户端（Smart Client）]
    ↓
[主 A ←→ 从 A1, A2]  [主 B ←→ 从 B1, B2]  [主 C ←→ 从 C1, C2]
       ←── Gossip 通信 ──→

适用场景

• 数据量大：超过单机内存容量
• 需要水平扩展：数据增长快，需要在线扩容
• 高可用要求高：自动故障转移，无单点
• 应用场景：大规模缓存、时序数据、消息队列

推荐配置

至少 3 主 3 从
cluster-node-timeout 15000
min-replicas-to-write 1
replica-priority 按硬件配置

优缺点

优点：
– 支持自动水平扩展
– 无单点故障
– 海量数据存储

缺点：
– 跨槽操作受限
– 客户端需要支持 Cluster 协议
– 运维复杂度高

方案三：Redis Sentinel + Proxy

架构

[客户端]
    ↓
[Proxy 层：Twemproxy / Codis / HAProxy / Nginx]
    ↓                      ↓
[哨兵集群]            [Redis 主从组 1]
                      [Redis 主从组 2]
                      [Redis 主从组 3]

适用场景

• 需要读写分离：Proxy 层统一路由
• 兼容普通客户端：不支持 Cluster 的旧系统
• 统一管理：多组 Redis 的集中管理
• 应用场景：大型电商、社交平台的缓存层

推荐配置

3 个哨兵负责每组 Redis
Proxy 层做负载均衡和故障转移
每组 1 主 2 从

选型决策树

数据量是否超过单机内存？
├── 否 → 需要完整事务/Lua？
│   ├── 是 → 主从+哨兵 ✅
│   └── 否 → 主从+哨兵 或 Cluster 均可
└── 是 → 需要在线扩容能力？
    ├── 是 → Redis Cluster ✅
    └── 否 → 主从+哨兵 或 Proxy 方案

其他考量因素

成本

性能

• 主从+哨兵：读性能可通过加从节点扩展，写性能受单节点限制
• Redis Cluster：读写性能均可随节点数线性扩展
• Proxy 方案：Proxy 层可能成为性能瓶颈

业务连续性

• RTO（恢复时间目标）：哨兵/Cluster 通常 10-30 秒
• RPO（恢复点目标）：取决于 min-replicas-to-write 配置（异步复制默认可能有秒级丢失）

特殊情况

云托管 Redis

如果使用云服务（AWS ElastiCache、阿里云 Redis、腾讯云 Redis）：

• 云服务商已经内置了高可用和分片能力
• 通常不需要自己部署哨兵
• 根据数据量选择”主从版”或”集群版”

混合方案

有些场景可以将哨兵和 Cluster 混合使用：

• 核心业务数据使用 Cluster 分片存储
• 元数据或配置使用主从+哨兵
• 缓存层使用 Proxy 做读写分离

总结

没有”最好的方案”，只有”最适合的方案”。选择 Redis 高可用方案的核心理念是：

1. 数据量决定架构：超过单机内存选 Cluster，否则选主从
2. 功能需求限制选择：需要完整事务就排除 Cluster
3. 运维能力决定复杂度：能力有限时宁可选简单的方案
4. 云计算时代优先使用托管服务

理解每种方案的适用边界和取舍，是在面试中展示深度思考的关键。