【Redis从入门到精通】第52篇：sentinel vs cluster——redis高可用方案怎么选

上一篇【第51篇】Cluster复制与故障转移——集群高可用机制 下一篇【第53篇】Redis发布订阅——消息队列的轻量替代方案

你站在Redis的十字路口，面前有两条路：

• 左边是 Sentinel —— 一个独立的高可用哨兵系统，站在Master旁边站岗放哨
• 右边是 Cluster —— 一个内建高可用的分布式集群，数据分片、自动故障转移一把梭

选哪个？这可不是抛硬币能决定的事。今天我们就来一场"神仙打架"，把Standalone、Sentinel、Cluster三种部署模式从头到脚比较一遍，最后给你一棵企业级决策树，让你再也不用纠结。

三种部署模式的架构

Standalone（单机模式）

最简单，一个Redis实例搞定一切。

Standalone 架构

┌─────────────┐
│ Client │
└──────┬──────┘
│
v
┌─────────────┐
│ Redis 单机 │
│ 全部数据 │
│ 6379端口 │
└─────────────┘

优点: 简单！真的简单！
缺点: 挂了就完了，没有备份，没有扩展

Sentinel（哨兵模式）

在Standalone基础上加了主从复制 + 哨兵监控。

Sentinel 架构

┌──────────────────────────────────────┐
│ Sentinel 集群 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Sentinel-1│ │Sentinel-2│ │Sentinel-3│ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────────────────┘
监控 | 监控 | 监控
v
┌─────────────────────────────────────┐
│ 主从复制组 │
│ │
│ Master (6379) ──────┐ │
│ │ │ │
│ │ 同步复制 │ │
│ v v │
│ Slave-1 (6380) Slave-2 (6381) │
└─────────────────────────────────────┘
|
┌──────┴──────┐
│ Clients │
│ (通过Sentinel│
│ 获取主库地址)│
└─────────────┘

Cluster（集群模式）

数据分片 + 内建复制 + 自动故障转移。

Cluster 架构

┌──────────────────────────────────────────────┐
│ Client │
└──────────┬─────────────┬────────────┬─────────┘
│ │ │
v v v
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Master-A │ │ Master-B │ │ Master-C │
│ 槽0-5460 │ │槽5461- │ │槽10923- │
│ │ │ 10922 │ │ 16383 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
v v v
┌──────────┐ ┌──────────┐ ┌──────────┐
│Slave-A1 │ │Slave-B1 │ │Slave-C1 │
└──────────┘ └──────────┘ └──────────┘

特点: 数据分片、内置高可用、水平扩展

全方位对比表格

先上一张大表，一目了然：

Sentinel 的适用场景

Sentinel 适合以下情况：

1. 数据量适中，不需要分片

Sentinel 典型场景

┌─────────────────────────────────┐
│ 你的数据量: 10GB ~ 30GB │
│ 你的QPS: 1万 ~ 5万 │
│ 单机Redis扛得住 │
│ 但你不能接受单点故障 │
│ → Sentinel 完美解决 │
└─────────────────────────────────┘

2. 团队运维能力有限

Sentinel 的部署和运维相对简单：

# 最小化Sentinel部署（3个Sentinel + 1主2从）

# Step 1: 部署主从
redis-server –port 6379 –daemonize yes # Master
redis-server –port 6380 –daemonize yes –replicaof 127.0.0.1 6379 # Slave
redis-server –port 6381 –daemonize yes –replicaof 127.0.0.1 6379 # Slave

# Step 2: 部署Sentinel
redis-sentinel sentinel-1.conf –port 26379 –daemonize yes
redis-sentinel sentinel-2.conf –port 26380 –daemonize yes
redis-sentinel sentinel-3.conf –port 26381 –daemonize yes

# sentinel.conf 配置示例
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

3. 需要读写分离

Sentinel 模式天然支持读写分离：

// Java + Lettuce 实现读写分离
lettuceClient = RedisClient.create(
RedisURI.create("redis-sentinel://127.0.0.1:26379,127.0.0.1:26380/0")
);
// 从库自动发现，读请求分散到从库

Cluster 的适用场景

1. 数据量大，需要水平扩展

Cluster 典型场景

┌─────────────────────────────────┐
│ 你的数据量: 50GB ~ 1TB+ │
│ 你的QPS: 10万 ~ 百万 │
│ 单机Redis扛不住 │
│ 需要数据分片 + 水平扩展 │
│ → Cluster 是唯一选择 │
└─────────────────────────────────┘

2. 高并发写入

# 3主3从Cluster: 写入QPS可达15-20万+
# 6主6从Cluster: 写入QPS可达30-50万+
# 12主12从Cluster: 写入QPS可达60-100万+

# Cluster线性扩展示意:
# 主库数 × 单机写QPS ≈ 集群总写QPS
# 3主 × 5万 = 15万
# 6主 × 5万 = 30万
# 12主 × 5万 = 60万

3. 需要在线扩容

Cluster支持动态添加节点，不需要停机：

# 添加新主库
redis-cli –cluster add-node 127.0.0.1:7006 127.0.0.1:7000

# 重新分片
redis-cli –cluster reshard 127.0.0.1:7000

企业级选型决策树

画一棵决策树，跟着走就能得出答案：

Redis 部署模式选择决策树

数据量 > 50GB 或 QPS > 5万？
├─ 是 ──→ 需要多Key事务或Lua跨Key操作？
│ ├─ 是 ──→ 评估能否用{hashtag}保证同槽
│ │ ├─ 能 ──→ Cluster ✓
│ │ └─ 不能 ──→ 考虑拆分业务到多个Sentinel组
│ └─ 否 ──→ Cluster ✓
│
└─ 否 ──→ 需要高可用（7×24不间断）？
├─ 否 ──→ Standalone（开发/测试环境）✓
└─ 是 ──→ 预算允许6+节点？
├─ 是 ──→ 预计数据量会快速增长？
│ ├─ 是 ──→ 直接上 Cluster（避免二次迁移）✓
│ └─ 否 ──→ Sentinel ✓
└─ 否 ──→ Sentinel（3节点部署）✓

迁移路径：从Standalone到Cluster

如果你的系统正在从Standalone逐步演进，这里有一条清晰的迁移路径：

Stage 1: Standalone → Sentinel

迁移阶段 1

Before: After:
┌────────┐ ┌────────┐
│Redis │ → │Master │─── Slave-1
│单机 │ └────────┘─── Slave-2
└────────┘ ↑
┌────┴────┐
│Sentinel │
│ ×3 │
└─────────┘

# 迁移步骤:
# 1. 配置现有Redis的主从复制
# 2. 部署Sentinel
# 3. 客户端切换到Sentinel模式
# 4. 验证故障转移功能

Stage 2: Sentinel → Cluster

迁移阶段 2

Before: After:
┌────────────┐ ┌────────────────────┐
│Sentinel组1 │ │Cluster │
│Master+Slave│ → │M1─S1 M2─S2 M3─S3 │
└────────────┘ └────────────────────┘
┌────────────┐
│Sentinel组2 │ 合并 数据分片到多个主库
│Master+Slave│ →
└────────────┘

# 迁移步骤:
# 1. 部署Cluster集群（新环境）
# 2. 使用redis-migrate-tool或自研工具迁移数据
# 3. 双写方案过渡期（写Cluster + 写Sentinel）
# 4. 验证Cluster数据完整性
# 5. 客户端切换到Cluster模式
# 6. 下线Sentinel

踩坑提示：从Sentinel迁移到Cluster最大的坑是多Key操作。如果你的代码中有大量 MGET key1 key2 key3 这种操作，在Cluster中只有当所有Key落在同一槽位时才能正常工作。迁移前一定要审计你的代码！

云厂商Redis服务对比

如果不想自己运维，各大云厂商都提供了托管Redis服务：

生产建议：对于中小企业，强烈建议使用云厂商的托管服务。自建Redis Cluster的运维成本（故障排查、备份恢复、版本升级、监控告警）远比你想象的高。除非你有专门的DBA团队，否则托管服务是更划算的选择。

生产环境运维注意事项

监控

不管选哪种模式，以下指标都需要监控：

核心监控指标:
内存:
– used_memory / maxmemory 利用率
– used_memory_peak 峰值
– eviction_count 淘汰计数

性能:
– instantaneous_ops_per_sec 当前QPS
– latency_percentiles_usec 延迟分位数

复制（Sentinel/Cluster）:
– master_link_status 主从连接状态
– master_repl_offset 复制偏移量
– repl_backlog_size 复制缓冲区大小

集群（Cluster）:
– cluster_state 集群状态（ok/fail）
– cluster_stats_messages_sent Gossip消息发送数

持久化:
– rdb_last_bgsave_status RDB最后保存状态
– aof_last_write_status AOF最后写入状态

备份策略

升级策略

滚动升级流程（适用于Sentinel和Cluster）

① 先升级从库（不影响服务）
② 确认从库升级后同步正常
③ 对从库执行 CLUSTER REPLICATE / slaveof 切换（Sentinel模式手动）
④ 触发故障转移，让已升级的从库变为主库
⑤ 升级原来的主库（现在是从库了）
⑥ 重复以上步骤，直到所有节点升级完成

混合部署方案：还需要 Cluster + Sentinel 吗？

答案是：通常不需要。

在Redis Cluster出现之前，有些架构是"Cluster负责分片 + Sentinel负责高可用"。但Redis Cluster从3.0开始就内置了故障转移功能，所以这种组合在现代架构中已经没有意义了。

过时方案 vs 现代方案

过时方案（不推荐）:
┌─────────────────────────────┐
│ Cluster 节点组1 │
│ M1-S1 (Sentinel监控) │
├─────────────────────────────┤
│ Cluster 节点组2 │
│ M2-S2 (Sentinel监控) │
└─────────────────────────────┘
→ 复杂度高，Sentinel和Cluster的故障转移可能冲突

现代方案（推荐）:
┌─────────────────────────────┐
│ Cluster │
│ M1-S1 M2-S2 M3-S3 │
│ 内置故障转移，无需Sentinel │
└─────────────────────────────┘
→ 简洁，Cluster自带一切

唯一可能需要Sentinel的场景是：你有一套独立的、小规模的Redis实例，不参与Cluster，但需要高可用监控。这种情况下Sentinel仍然是最合适的选择。

本章小结

最后送你一句话：没有银弹，只有最适合你当前阶段的选择。如果你还在早期，Standalone就够了；数据量上来了但还能单机扛住，Sentinel给你高可用保障；数据量大到单机扛不住了，那就毫不犹豫上Cluster。

上一篇【第51篇】Cluster复制与故障转移——集群高可用机制 下一篇【第53篇】Redis发布订阅——消息队列的轻量替代方案