Redis 的集群

深入理解 Redis 的集群模式与高可用机制

Redis 是一款广泛应用于高性能缓存与存储系统的 NoSQL 数据库。随着业务的发展，如何提升 Redis 的高可用性和水平扩展能力成为架构设计的关键。本篇博客将系统讲解 Redis 的不同集群模式及其高可用策略，深入剖析其故障恢复机制与主从选举规则。

一、Redis 的四种主要部署模式

1. 单机模式（Standalone）

• 所有数据集中存储在一个 Redis 实例中。

• 简单、快速、适合测试或小型系统。

• 缺点：没有容灾能力，单点故障严重。

2. 主从复制模式（Master-Slave）

• 一个主节点（Master）提供读写，多个从节点（Slave）复制主节点的数据，仅提供读。

• 支持读写分离，从节点可缓解主节点压力。

• 缺点：主节点挂掉后需人工切换，没有自动恢复能力。

3. Sentinel 哨兵模式

• 在主从复制基础上，增加 Sentinel 守护进程，负责监控主从状态并实现主从自动切换。

• 自动故障转移，无需人工干预。

• 高可用但不支持数据分片，适合中小型系统。

4. Redis Cluster 模式

• Redis 官方提供的分布式架构，支持数据自动分片与高可用。

• 每个主节点负责部分数据（slot），并配有一个或多个从节点。

• 集群自动处理主从故障转移，具备真正的弹性扩展能力。

二、Sentinel 模式中的部署与容灾原理

1. Sentinel 是什么？

• 是 Redis 提供的高可用组件，独立运行的进程，不是 Redis 实例本身。

• 负责监控主从节点、判断故障、发起主从切换。

2. Sentinel 可以部署在哪？

• 可以部署在任意能访问 Redis 的服务器上。

• 推荐部署在：

  • 与从节点同机（节省资源）

  • 独立服务器上（高可用性强）

• 不推荐部署在主节点上：主节点宕机，Sentinel 也失效。

3. 最小部署建议

• 至少 3 个 Sentinel 节点，确保有法定票数判断主节点状态。

• 推荐架构：

  • 1 主 + 2 从 + 3 Sentinel（可与从节点共用机器）

三、Redis Cluster 模式的高可用机制

Redis Cluster 在设计上具备原生的分布式高可用能力，主要包括以下几个方面：

1. 主从架构

• 每个主节点对应一个或多个从节点，用于备份数据、提升可用性。

2. 节点间 Gossip 协议

• 所有节点定时互发心跳包（PING/PONG），检测对方存活状态。

• 若某主节点被多数节点判断失联，则标记为 FAIL。

3. 自动 Failover 机制

当主节点宕机时，其从节点会自动参与“竞选”成为新的主节点，流程如下：

晋升规则（从节点选主）：

1. 优先看 slave-priority 配置（默认值越小越优先；为 0 表示不参与选主）。

2. 再比较复制偏移量 offset，越大说明同步越完整，优先级越高。

3. 最后比较节点 ID，值较小的节点胜出（UUID）。

⚠️ 选主需要多数主节点存活，Redis Cluster 遵循 “超过半数” 原则防止脑裂。

四、如果主节点和它的所有从节点都宕机了怎么办？

情况说明：

• 某个主节点及其所有从节点都挂了。

后果：

• 对应的数据分片（slot）将不可访问。

• Redis Cluster 不会将这些 slot 自动分配给其他主节点（为了数据一致性安全）。

• 集群部分服务仍可用，但出现 cluster_slots_fail 状态。

解决方案：

1. 启动一个新的 Redis 节点。

2. 使用 redis-cli --cluster add-node 加入集群。

3. 使用 setslot 或 reshard 等命令重新分配 slot。

4. 恢复备份数据（RDB/AOF）到新节点。

如何避免：

• 为每个主节点配置 至少两个从节点。

• 部署在不同物理机或网络区域，增强容灾能力。

五、小结与最佳实践

🔚 写在最后

Redis 的集群模式提供了丰富的选择，每种模式适合的场景和复杂度不同。在生产环境中，推荐使用 Redis Cluster 结合多个从节点部署，保障数据分片与故障恢复能力，并通过合理设置 slave-priority 和监控系统提升系统弹性。

如果你正在设计 Redis 架构，不妨从自身系统的可用性要求、数据规模、读写压力等方面出发，选择合适的集群模式，并做好部署与监控体系的建设。