Redis 的 Sentinel 模式 和 Cluster 模式 是两种不同的高可用（HA）解决方案，它们在架构设计、功能特性和适用场景上有显著区别。以下是两者的详细对比：
1. 核心功能与目标
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 核心目标 | 提供 高可用性（HA），确保主节点故障时自动切换。 | 提供 高可用性 + 数据分片，支持大规模数据存储和水平扩展。 |
| 数据分片 | 不支持数据分片，所有数据存储在主节点上。 | 支持数据分片（通过哈希槽分配数据），实现分布式存储。 |
| 自动故障转移 | 自动完成主从切换，确保服务连续性。 | 自动完成主从切换，并同步数据分片信息。 |
| 扩展性 | 扩展性有限（仅通过增加从节点实现读扩展）。 | 可线性扩展到多个节点，动态添加/删除节点。 |
2. 架构设计
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 节点角色 | – 单主节点 + 多从节点 – Sentinel 节点独立运行。 | – 多主节点 + 多从节点 – 所有节点直接通信（无中心节点）。 |
| 通信机制 | – Sentinel 节点通过心跳检测主从节点状态。 – 使用集中式决策（投票选举新主节点）。 | – 节点间通过 Gossip 协议 交换状态信息。 – 去中心化决策（分布式选举新主节点）。 |
| 客户端连接 | – 客户端直接连接主节点或从节点。 – Sentinel 提供主节点地址发现能力。 | – 客户端直接连接任意节点，通过 哈希槽路由 定位数据。 |
3. 高可用性与故障转移
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 故障检测 | – Sentinel 节点定期检测主从节点状态。 – 主观下线（单个 Sentinel 判定）→ 客观下线（多数 Sentinel 确认）。 | – 每个节点通过 Gossip 协议检测其他节点状态。 – 主观下线（单节点判定）→ 客观下线（多数主节点确认）。 |
| 故障转移时间 | 通常 10-30 秒（依赖配置和网络延迟）。 | 通常 15-60 秒（依赖节点数量和网络延迟）。 |
| 从节点选举规则 | – 优先级最高（slave-priority）– 数据最完整（复制偏移量最大） – 节点 ID 最小。 | – 数据最完整（复制偏移量最大） – 节点 ID 最小。 |
4. 数据分片与扩展性
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 数据分片 | 不支持数据分片，所有数据存储在单个主节点上。 | 支持 哈希槽（Hash Slot） 分片，数据分布到多个主节点。 |
| 水平扩展 | 仅通过增加从节点实现读扩展，写操作仍受限于主节点性能。 | 通过增加主节点实现写扩展，支持线性扩展（1000+ 节点）。 |
| 数据迁移 | 无自动数据迁移功能。 | 自动迁移哈希槽和数据（如节点增删时重新分配）。 |
5. 客户端兼容性
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 客户端要求 | – 支持 Sentinel 协议的客户端（如 Redis 官方驱动）。 | – 需要 集群感知驱动（支持哈希槽路由）。 |
| 多键操作支持 | 支持跨节点多键操作（如 MSET、MGET）。 | 不支持跨节点多键操作（需客户端分片或使用代理）。 |
6. 配置与维护
| 维度 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 配置复杂度 | 配置相对简单，仅需配置 Sentinel 和主从节点。 | 配置复杂，需设置哈希槽分配、节点通信等参数。 |
| 维护成本 | 维护成本较低，适合中小规模部署。 | 维护成本较高，适合大规模分布式部署。 |
| 单点故障风险 | – Sentinel 节点本身可能存在单点故障（需部署多个 Sentinel 实例）。 | – 去中心化设计，无单点故障风险。 |
7. 适用场景
| 场景 | Sentinel 模式 | Cluster 模式 |
|---|---|---|
| 数据规模 | 适合中小规模数据（如小于 100GB）。 | 适合大规模数据（如 TB 级以上）。 |
| 并发需求 | 适合中低并发（单主节点性能瓶颈）。 | 适合高并发（水平扩展写能力）。 |
| 运维复杂度 | 适合运维团队较小的场景。 | 适合有分布式系统经验的运维团队。 |
| 典型业务 | – 缓存服务 – 会话存储 – 简单排行榜 | – 分布式锁 – 海量数据存储 – 高并发读写场景 |
8. 优缺点总结
| 模式 | 优点 | 缺点 |
|---|---|---|
| Sentinel | – 配置简单，易于部署。 – 高可用性保障完善。 – 适合中小规模应用。 | – 不支持数据分片。 – 扩展性有限（写操作受限于单主节点）。 – 客户端需适配 Sentinel 协议。 |
| Cluster | – 支持水平扩展，适合大规模数据。 – 自动分片和故障转移。 – 无中心化设计，容错性强。 | – 配置复杂，运维成本高。 – 不支持跨节点多键操作。 – 客户端需支持集群模式。 |
9. 如何选择？
- 选择 Sentinel：
- 数据量较小（如 <100GB）。
- 需要简单高可用性，且并发需求不高。
- 运维团队规模有限，无法处理复杂配置。
- 选择 Cluster：
- 数据量大（TB 级以上）且需要水平扩展。
- 高并发写操作需求（需多主节点分担压力）。
- 有分布式系统运维经验，可接受复杂配置。
10. 示例对比
Sentinel 场景：
# 配置文件示例（sentinel.conf）
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1- 适用于单主节点的高可用部署，如缓存服务。
Cluster 场景：
# 启动命令示例（3 主 3 从）
redis-server --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 \
127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1- 适用于分布式存储场景，如电商秒杀系统的库存缓存。
总结
- Sentinel 是 高可用性优先 的方案，适合中小规模应用。
- Cluster 是 分布式扩展优先 的方案，适合大规模数据和高并发场景。
- 两者的核心区别在于：Cluster 通过数据分片和去中心化设计实现了真正的分布式架构，而 Sentinel 更关注单实例的高可用性保障。
THE END
