6、Redis 高可用部署的两种方式 Redis Cluster 集群模式、Redis Sentinel 哨兵模式

Redis 的高可用部署是构建稳定、高性能系统的基石。在实际开发中，Redis Cluster（集群模式） 和 Sentinel（哨兵模式） 是两种主流的高可用方案，它们解决的问题相似，但架构、能力、适用场景有显著区别。

下面我将为你提供一份 详细、实战级的对比说明文档，涵盖原理、架构、优缺点、性能、数据分布、故障转移机制，并结合 Java 开发者的实际需求给出 选型建议和推荐做法。

---

📚 Redis 高可用方案对比：Redis Cluster vs Sentinel 模式

适用读者：Java 后端开发者、系统架构师、运维工程师
目标：理解两种模式的本质区别，掌握在实际项目中如何选择与部署

---

一、核心目标对比

目标	Redis Sentinel	Redis Cluster
✅ 高可用（HA）	✅ 支持主从切换	✅ 支持节点故障转移
✅ 数据冗余	✅ 主从复制	✅ 分片 + 副本
✅ 自动故障转移	✅ 支持	✅ 支持
✅ 水平扩展（分片）	❌ 不支持（需客户端分片）	✅ 原生支持
✅ 客户端直连	✅ 可直连主节点	✅ 客户端需支持 Cluster 协议

---

二、基本架构与工作原理

1. Redis Sentinel（哨兵模式）

✅ 架构图（简化）

                +----------------+
                |   Sentinel     |
                | (监控/决策)    |
                +-------+--------+
                        |
         +--------------+--------------+
         |              |              |
+--------v----+ +-----v------+ +-----v------+
|  Master     | |  Slave     | |  Slave     |
|  (写/读)    | |  (只读)    | |  (只读)    |
+-------------+ +------------+ +------------+

🔧 工作机制：

• Sentinel 进程：独立运行的监控进程（通常部署 3~5 个）
• 监控：持续检查 Master 和 Slave 是否存活
• 自动故障转移（Failover）：
  • 当 Master 宕机，Sentinel 选举新主（从 Slave 中选）
  • 通知其他 Slave 切换主节点
  • 通知客户端新的 Master 地址（通过 PUB/SUB 或 API 查询）
• 配置中心：客户端需连接 Sentinel 获取当前 Master 地址

⚠️ 注意：数据不分片，所有数据仍在单个 Master 上。

---

2. Redis Cluster（集群模式）

✅ 架构图（6 节点示例）

        Client
          │
          ▼
   +------------------+
   | Redis Cluster    |
   | (16384 slots)    |
   +------------------+
     /       |       \
    ▼        ▼        ▼
Master1  Master2  Master3
   │        │        │
   ▼        ▼        ▼
Slave1   Slave2   Slave3

🔧 工作机制：

• 数据分片（Sharding）：整个 Key 空间划分为 16384 个哈希槽（hash slots）
• Key → Slot 映射：CRC16(key) % 16384
• Slot → 节点分配：每个 Master 节点负责一部分 Slot（如 0-5000, 5001-10000 等）
• 故障转移：每个 Master 至少有一个 Slave，故障时自动提升 Slave 为新 Master
• Gossip 协议：节点间通过 Gossip 交换状态信息
• 客户端职责：
  • 首次获取集群拓扑（CLUSTER SLOTS）
  • 缓存 Slot → 节点映射
  • 请求转发或重定向（MOVED / ASK）

✅ 支持 自动分片 + 高可用 + 水平扩展

---

三、核心区别对比表

对比维度	Redis Sentinel	Redis Cluster
高可用性	✅ 支持主从切换	✅ 支持多节点故障转移
数据分片	❌ 不支持（单 Master）	✅ 支持 16384 个 slots
水平扩展	❌ 无法扩展单 Master 容量	✅ 可动态增减节点
吞吐量	受限于单 Master 性能	多 Master 并行，更高 QPS
内存上限	单机内存限制（如 64GB）	多节点总和（如 3×64GB）
客户端要求	需支持 Sentinel（如 Jedis, Lettuce）	需支持 Cluster 协议（Lettuce 推荐）
运维复杂度	简单	较复杂（需管理多个节点、槽位）
网络开销	小（仅 Sentinel 通信）	较大（Gossip 协议）
数据一致性	异步复制，可能丢数据	同 Sentinel，异步复制
多 Key 操作限制	支持多 Key 操作（同一 Master）	❌ 跨 Slot 的 multi-key 操作受限（如 MGET 必须同 Slot）
适用场景	小中规模、数据量 < 50GB	大规模、高并发、海量数据

---

四、实际开发中的选择建议

✅ 场景 1：中小型项目（数据量 < 50GB，QPS < 5万）

推荐：Sentinel 模式

理由：

• 架构简单，运维成本低
• 支持完整的 multi-key 操作（如 MGET, MSET, ZUNIONSTORE）
• 客户端兼容性好（几乎所有 Redis 客户端都支持）
• 故障转移稳定，适合大多数业务系统

典型应用：

• 用户会话缓存
• 商品信息缓存
• 配置中心
• 分布式锁（Redisson）

---

✅ 场景 2：大型项目（数据量 > 50GB，QPS > 10万，需水平扩展）

推荐：Redis Cluster

理由：

• 支持水平扩展，可承载 TB 级数据
• 多 Master 并行处理，提升整体吞吐量
• 原生支持分布式架构，适合微服务环境
• 避免单点瓶颈

典型应用：

• 社交平台（粉丝关系、动态流）
• 游戏排行榜（ZSet 分布式存储）
• 实时推荐系统
• 大规模消息队列（Stream）

---

五、Java 客户端支持情况

客户端	Sentinel 支持	Cluster 支持	推荐指数
Lettuce	✅	✅	⭐⭐⭐⭐⭐（推荐）
Jedis	✅	✅	⭐⭐⭐⭐☆（较老，但稳定）
Redisson	✅	✅	⭐⭐⭐⭐⭐（高级功能多）

示例：Lettuce 连接 Cluster

RedisClusterConfiguration clusterConfig = new RedisClusterConfiguration(Arrays.asList(
    "192.168.1.100:7000",
    "192.168.1.100:7001",
    "192.168.1.101:7000"
));

LettriceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
    .commandTimeout(Duration.ofSeconds(5))
    .build();

RedisConnectionFactory factory = new LettuceConnectionFactory(clusterConfig, clientConfig);
factory.afterPropertiesSet();

---

六、推荐部署架构（生产环境）

✅ 推荐：Redis Cluster（3主3从）

Node1: 192.168.1.100:7000 (Master) → Node4: 7003 (Slave)
Node2: 192.168.1.101:7001 (Master) → Node5: 7004 (Slave)
Node3: 192.168.1.102:7002 (Master) → Node6: 7005 (Slave)

• 每个节点独立配置 redis.conf
• 使用 redis-cli --cluster create 初始化集群
• 建议使用 奇数个 Master（3/5/7）避免脑裂

---

✅ 备选：Sentinel（1主2从 + 3哨兵）

Master:  192.168.1.100:6379
Slave1:  192.168.1.101:6379
Slave2:  192.168.1.102:6379

Sentinel1: 192.168.1.100:26379
Sentinel2: 192.168.1.101:26379
Sentinel3: 192.168.1.102:26379

• 哨兵配置：

  sentinel monitor mymaster 192.168.1.100 6379 2
  sentinel auth-pass mymaster yourpassword
  sentinel down-after-milliseconds mymaster 5000
  sentinel failover-timeout mymaster 10000
  

---

七、实际开发中的最佳实践

实践	推荐做法
📦 数据分片设计	Cluster 中避免 KEYS *，合理设计 key 名称（如 user:{userId}:profile）使同用户数据在同一 slot
🔁 客户端重试	处理 MOVED / ASK 重定向，Lettuce 自动处理
🧯 故障转移测试	定期模拟主节点宕机，验证自动切换
📊 监控	使用 INFO 命令 + Prometheus + Grafana 监控命中率、延迟、内存
🔐 安全	启用密码（requirepass），禁用危险命令（rename-command FLUSHDB ""）
💾 持久化	Cluster 和 Sentinel 都建议开启 AOF + RDB
🔄 备份	定期备份 RDB 文件，防止数据丢失

---

八、总结：如何选择？

选择依据	推荐方案
数据量小（< 50GB），QPS 低	✅ Sentinel（简单稳定）
需要水平扩展，数据量大	✅ Redis Cluster
要求支持 multi-key 操作	✅ Sentinel（Cluster 有限制）
微服务架构，多团队共用	✅ Cluster（资源隔离）
团队运维能力弱	✅ Sentinel
追求极致性能与扩展性	✅ Cluster

---

九、最终推荐（2025 年 Java 开发者建议）

✅ 如果你是新项目，且预计数据量会增长 → 直接上 Redis Cluster
✅ 如果你是中小型项目，追求稳定简单 → 使用 Sentinel + 主从复制
✅ 无论哪种，都使用 Lettuce 或 Redisson 作为客户端
✅ 生产环境至少 3 节点，避免单点故障