Redis 的主从架构、哨兵模式（Sentinel）和集群（Redis Cluster）是三种不同的分布式解决方案，分别针对不同的业务场景设计，核心差异体现在功能定位、数据分布、高可用机制等方面。以下是全方面对比：
一、核心定位与适用场景
| 架构类型 | 核心定位 | 适用场景 |
|---|---|---|
| 主从架构 | 基础的数据备份与读负载均衡，通过复制实现主从数据同步。 | 读多写少、数据量不大、对高可用要求不高的场景（如单机主库 + 1-2 个从库）。 |
| 哨兵模式 | 在主从架构基础上，通过哨兵节点实现主库故障自动检测与切换，保障高可用。 | 读多写少、需自动容灾（避免主库故障导致集群不可用），但数据量仍可控的场景。 |
| Redis 集群 | 实现数据分片（突破单机内存限制）+ 原生高可用，支持大规模扩展。 | 数据量大（需分片存储）、对扩展性和容错性要求高的大规模分布式场景。 |
二、数据分布方式
| 架构类型 | 数据存储方式 | 节点角色 |
|---|---|---|
| 主从架构 | 所有节点（主库 + 从库）存储完整数据集，从库通过 “主从复制” 同步主库数据，无分片。 | 1 个主库（负责读写）+ N 个从库（仅负责读，不处理写请求）。 |
| 哨兵模式 | 同主从架构，所有节点存储完整数据集，无分片。哨兵节点仅负责监控，不存储数据。 | 1 主 N 从（数据节点）+ 3 + 个哨兵节点（监控 / 决策）。 |
| Redis 集群 | 采用哈希槽（Hash Slot）分片：16384 个哈希槽分配给多个主库，每个主库存储部分槽数据。 | 多主多从：每个主库负责部分哈希槽，可配置从库（同步主库数据，用于故障切换）。 |
三、高可用机制（故障检测与恢复）
| 维度 | 主从架构 | 哨兵模式 | Redis 集群 |
|---|---|---|---|
| 故障检测 | 无原生机制，需人工监控或依赖外部工具（如 Zabbix）。 | 哨兵节点通过定期 ping检测主从节点存活状态，多个哨兵达成共识后标记故障。 | 节点间通过心跳检测（ping/pong） 实现故障检测，超时无响应则标记为故障。 |
| 主库故障恢复 | 需手动切换（将从库升级为主库，重新配置其他节点），过程可能长时间不可用。 | 哨兵自动选举新主库（从库中选最优节点），并通知所有从库和客户端更新主库地址。 | 自动触发故障迁移：故障主库的从库通过 “选举” 升级为新主库，集群自动更新槽映射。 |
| 容错能力 | 主库故障后写服务不可用，从库故障仅影响部分读请求。 | 主库故障后，哨兵可在秒级完成切换，写服务短暂中断后恢复。 | 单个主库故障后，其从库快速接管，不影响其他分片的读写，整体可用性更高。 |
四、读写能力与扩展性
| 维度 | 主从架构 | 哨兵模式 | Redis 集群 |
|---|---|---|---|
| 写能力 | 仅主库处理写请求，写性能受限于单机配置（无法通过加节点提升）。 | 同主从架构，写能力仍受限于单个主库。 | 多主库并行处理写请求（每个主库负责部分槽），写性能随主库数量线性扩展。 |
| 读能力 | 可通过增加从库分担读请求，读性能可扩展。 | 同主从架构，读能力可通过增加从库扩展。 | 读请求可分流到主库或从库，读性能随节点数量扩展。 |
| 存储扩展性 | 无（所有节点存全量数据，单机内存不足时无法通过加节点解决）。 | 无（同主从架构，依赖单机存储）。 | 支持水平扩展：新增主库并分配哈希槽，存储容量随节点数量线性增长。 |
五、一致性保障
| 架构类型 | 数据一致性机制 | 潜在问题 |
|---|---|---|
| 主从架构 | 默认异步复制：主库写成功后立即返回，数据异步同步到从库，可能存在 “主从延迟”。 | 主库宕机时，未同步到从库的数据可能丢失；从库读可能获取旧数据。 |
| 哨兵模式 | 同主从架构（依赖主从复制的一致性）。 | 同主从架构，且故障切换过程中可能产生短暂的数据不一致（如部分从库未同步完）。 |
| Redis 集群 | 基于主从复制的一致性，同时通过 “槽映射” 保证分片内的数据原子性。 | 跨槽操作（如多 key 命令）不支持，需手动将 key 分配到同一槽；仍存在主从延迟问题。 |
六、部署复杂度
| 架构类型 | 部署难度 | 核心组件 |
|---|---|---|
| 主从架构 | 简单：配置主库地址即可实现从库复制。 | 主库、从库（无额外组件）。 |
| 哨兵模式 | 中等：需部署 3 + 个哨兵节点，配置哨兵监控规则。 | 主库、从库、哨兵节点（至少 3 个，保证高可用）。 |
| Redis 集群 | 较高：需配置哈希槽分配、节点间通信，建议至少 3 主 3 从（共 6 节点）。 | 主库、从库（每个主库至少 1 个从库），无额外监控组件（节点自管理）。 |
总结：核心差异对比表
| 对比维度 | 主从架构 | 哨兵模式 | Redis 集群 |
|---|---|---|---|
| 数据分布 | 全量数据（无分片） | 全量数据（无分片） | 哈希槽分片（部分数据） |
| 核心能力 | 备份、读负载均衡 | 自动故障切换（高可用） | 分片扩展、原生高可用 |
| 写性能扩展 | 不可扩展（依赖单机） | 不可扩展（依赖单机） | 可扩展（多主并行） |
| 存储扩展 | 不可扩展 | 不可扩展 | 可扩展（水平分片） |
| 故障恢复 | 手动切换 | 自动切换（哨兵） | 自动迁移（节点自管理） |
| 最小部署节点数 | 2（1 主 1 从） | 5（1 主 1 从 + 3 哨兵） | 6（3 主 3 从） |
| 典型适用场景 | 中小规模、读多写少 | 需自动容灾的中小规模场景 | 大规模数据、高扩展需求 |
选择建议：
- 小规模场景（数据量小、读多写少）：主从架构足够；
- 需自动容灾但数据量可控：哨兵模式；
- 大规模数据、高扩展需求：Redis 集群。