Redis Cluster 和 Sentinel 有什么区别？如何选择？

核心区别对比

1. 架构设计差异

2. 容错能力对比

故障恢复速度：

• Cluster：秒级自动故障转移（依赖Gossip协议）
• Sentinel：分钟级切换（需多数Sentinel节点确认）

数据一致性：

• Cluster：异步复制，可能丢失少量数据
• Sentinel：同步复制（需配置wait命令）

典型故障场景：

• 主节点宕机时
  Cluster：自动选举新主，客户端自动重定向到新主节点
  Sentinel：需要等待多数Sentinel节点确认故障，人工确认切换结果

3. 性能表现差异

选型决策因素

1. 数据规模边界

• ≤100GB：Sentinel + 主从复制
• ＞100GB：Cluster 自动分片
• ＞1TB：Cluster + Proxy 分层架构

2. 业务特性匹配

适合 Cluster 的场景：

• 需要水平扩展（如社交平台用户数据）
• 读写比 8:2 以上的读密集型业务
• 允许少量数据丢失（如缓存场景）

适合 Sentinel 的场景：

• 强一致性要求（如金融交易记录）
• 事务操作频繁（如库存扣减）
• 已有客户端不支持集群协议

3. 运维复杂度

Cluster 管理难点：

• 扩缩容需迁移哈希槽
• 跨机房部署需要定制工具
• 监控指标分散（需聚合）

Sentinel 管理优势：

• 配置变更简单
• 监控体系成熟
• 故障排查直观

4. 成本对比

5. 生态兼容性

常见兼容问题：

• Cluster 不支持跨节点事务
• 部分客户端需要升级（如 Jedis 3.x+）
• 监控工具需要适配（如 Prometheus）

Redis 集群架构选型流程图

生产环境配置示例

Redis Cluster 部署方案

6节点部署（3主3从）：
北京机房：
├─ 主A（槽0-5460）
├─ 从A1
上海机房：
├─ 主B（槽5461-10922）
├─ 从B1
广州机房：
├─ 主C（槽10923-16383）
├─ 从C1

Redis Sentinel 高可用方案

5节点部署：
主节点：redis-master
从节点：redis-replica1, redis-replica2
Sentinel节点：sentinel1, sentinel2, sentinel3（部署在独立服务器）

经典踩坑案例

Case 1: 集群脑裂问题

现象：某电商大促期间，Cluster 跨机房网络中断导致数据不一致
解决方案：

1. 设置cluster-node-timeout 15000
2. 配置cluster-replica-validity-factor 10
3. 启用cluster-require-full-coverage no

Case 2: Sentinel误切换

现象：网络抖动导致 Sentinel 误判主节点下线
优化方案：

sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

总结建议

下述场景选择 Redis Cluster：

• 数据量超过单机内存容量
• 需要线性扩展读写能力
• 能够接受客户端改造

下述场景选择 Redis Sentinel：

• 数据规模可控（＜200GB）
• 需要完整 Redis 特性支持
• 已有基础设施不支持集群协议

混合架构趋势：大型互联网公司通常同时使用两种方案，用 Cluster 承载海量数据，Sentinel 保证核心业务的高可用。

---

相关推荐：

• Redis 的 RDB 持久化机制是如何工作的？
• Redis 的 AOF 持久化机制是如何工作的？
• 像刷 LeetCode 一样练习 Redis 面试题