Redis 官方针对分片（Cluster）和高可用（HA）的文档说明

原创已于 2025-06-27 14:42:01 修改 · 621 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库

于 2025-06-26 16:14:28 首次发布

Redis 专栏收录该内容

44 篇文章

订阅专栏

下面是 Redis 官方针对分片（Cluster）和高可用（HA）的文档说明：

🔹 分片与高可用（Redis Cluster）

Redis Cluster 官方文档 — “Scale with Redis Cluster”

介绍了如何使用 Redis Cluster 自动划分数据到多个节点，以及在部分节点故障时维持可用能力 (redis.io)。
核心特性包括：
- 数据在 16384 个 Hash Slot 之间分片，每个 Master 负责其中一部分；
- 每个 Master 可配置复制（Replicas），故障自动检测与故障转移；
- 使用 Gossip 和 cluster-bus 协议实现节点间状态传播和故障一致判断 (redis.io, leapcell.medium.com)。

Redis Cluster 规范文档 — “Redis cluster specification”

详细说明了容错机制：当 Master 出现故障且其副本可用，则自动提升副本接管；
描述了 Paxos-like 的投票判断机制，包括 “pfail”→“fail”判定流程 (redis.io)；
指出 Redis Cluster 的一致性和可用性特性，如多数故障节点容忍能力 (redis.io)。

🔹 高可用与复制（Redis Sentinel）

Redis Sentinel 官方文档 — “High availability with Redis Sentinel”

Sentinel 为不使用 Cluster 模式的 Redis 提供高可用能力；
功能包括主从监控、故障检测、自动 failover 及通知机制；
Sentinel 自身作为分布式系统达成选举并切换 Master 地址 (redis.io)。

📌 推荐官方链接整理

功能	官方文档页面
Redis Cluster 分片 & HA	“Scale with Redis Cluster” (redis.io)
Redis Cluster 原理 & 容错机制	“Redis cluster specification”
Redis Sentinel 高可用方案	“High availability with Redis Sentinel”

✅ 总结建议

若你的架构是分片且需要 HA，推荐使用 Redis Cluster 模式；
如果你只是希望对单一实例做高可用保护，可以考虑 Redis Sentinel；
Redis Enterprise 提供更高级“HA＋分片”功能，但那是商业方案，不在开源文档范畴内。

需要进一步内容或帮助搭建 HA/Cluster 模式，欢迎随时告诉我！

翻译

这段关于 Redis Cluster 可用性的官方说明，可以翻译为中文如下：

🔹 可用性（Availability）

Redis Cluster 在网络分区中少数派那一侧不可用。
在网络分区的大多数派那一侧，只要：

大多数 Master 节点仍然可用，并且
每个无法访问的 Master 都至少还有一个副本（Replica）节点可用，

那么集群将在 NODE_TIMEOUT 时间之后，再加上副本选举为新主节点所需的几秒时间（通常是 1 到 2 秒），就可以恢复可用。

这意味着：

Redis Cluster 被设计成能容忍少量节点故障；
但它并不适用于要求在严重网络分裂（net split）情况下仍保持高可用性的应用场景。

📌 举例说明：

假设一个 Redis 集群有 N 个主节点（每个主节点只有一个副本）：

如果只分裂走了 1 个节点，那么大多数派仍然可用；
如果有 2 个节点从集群中被隔离出去，那么集群仍可用的概率是：

$\frac{1}{(N \times 2 - 1)}$

因为在第一个节点失败后，总共还剩下 $\times 2 - 1$ 个节点，而失去副本的那个 Master 也失败的概率是 $\frac{1}{(N \times 2 - 1)}$ 。

例如：

对于一个有 5 个主节点、每个主节点一个副本的集群，
总节点数是 10，
如果 2 个节点被隔离，
那么集群无法保持可用的概率是：

$\frac{1}{5 \times 2 - 1} = \frac{1}{9} \approx 11.11\%$

🔁 副本迁移机制（replica migration）

Redis Cluster 有一个叫做 副本迁移（replica migration） 的特性：

在真实世界的场景中，这项功能可以提升集群的可用性；
当某个主节点的副本失效时，集群可能会重新分配剩余的副本给孤立的主节点；
每次故障恢复后，Redis Cluster 会重新配置副本的布局，以便更好地抵御下一次的故障。

✅ 总结来说：
Redis Cluster 可以自动恢复部分节点故障并保持集群可用性，但无法保证在网络大规模分裂时的高可用。副本的合理分布和迁移机制可以显著提高实际容错能力。

两个主分片运行在同一节点

1. 架构层面优化

反亲和性强制实施

问题根源：两个主分片部署在同一节点，违反 Redis 集群高可用原则（需分散主节点）。
优化方案：
- 立即修复：对现网所有 Redis 分片集群进行主分片分布检查，通过调度策略将同一集群的主分片强制分散到不同物理节点（如使用 podAntiAffinity 或 QFusion 的"实例强制反亲和"策略）。
- 新建集群规范：创建 Redis 集群时默认开启 “实例强制反亲和” 策略，确保主分片跨节点分布。
- 配置示例（QFusion 平台）：
```
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: "redis-role"
              operator: In
              values: ["master"]
        topologyKey: "kubernetes.io/hostname"
```

集群规模与容错能力提升

问题：3 分片集群在单节点故障时极易因投票不足（需 2 个主节点）导致不可用。
优化方案：
- 扩容分片：将关键业务的 3 分片集群扩容至 ≥5 分片（如 5 分片允许同时故障 2 个主节点）。
- 分片分布规则：确保每个物理节点最多承载 1 个主分片（N 分片集群至少部署在 N 个节点）。

2. 运维监控增强

自动化巡检与告警

新增巡检项：
1. 主分片分布检测：定时扫描集群，若同一节点存在同一集群的多个主分片，触发高危告警。
2. 集群健康度检查：监控存活主节点数是否满足 N/2+1（如 3 分片集群需 ≥2 个主节点）。

工具实现：

# 示例：检查 Redis 集群主分片分布
redis-cli --cluster check <cluster-ip>:<port> | grep "master" | awk '{print $2}' | sort | uniq -c
# 输出：若某节点出现 >1 个主分片则告警

故障切换自动化

快速恢复机制：当主节点宕机且投票不足时，自动触发 CLUSTER FAILOVER TAKEOVER 命令强制提升备库。
实现方式：
- 集成到 QFusion 故障处理流程中，通过健康检查脚本自动执行。
- 前提条件：仅适用于缓存集群（无持久化数据），避免数据丢失风险。

3. 硬件与平台加固

节点高可用保障

硬件层：
- 对物理节点进行 RAID 卡/背板健康监控，提前预警硬件故障。
- 关键节点采用 N+1 冗余，避免单点故障导致多主分片丢失。
平台层：
- 优化 QFusion 调度器：优先将主分片部署在稳定性高、故障率低的节点。
- 启用 Node Failure Detection：缩短节点不可用判定时间（如 30 秒内触发切换）。

4. 业务连续性设计

容灾策略优化

缓存集群特殊处理：
- 明确标识纯缓存集群，允许更激进的高可用策略（如自动强制切换）。
- 为缓存集群配置 TTL 自动过期，避免旧数据干扰。
持久化集群保障：
- 开启 AOF/RDB 持久化 + 跨节点备份。
- 定期验证备份可恢复性。

5. 预防机制落地

变更管控与测试

上线前验证：
- 新增集群必须通过反亲和性校验（主分片跨节点部署）。
- 模拟节点宕机测试，确保集群可自动恢复。
文档沉淀：
- 编写《Redis 集群部署规范》，明确反亲和性、分片数量、硬件要求等标准。

总结：关键改进项

类别	措施	优先级
架构调度	主分片强制跨节点反亲和部署	高
集群规模	关键业务扩容至 ≥5 分片	中
监控告警	主分片分布巡检 + 集群健康度实时检测	高
故障恢复	自动化触发强制切换（缓存集群）	高
硬件可靠性	RAID/背板监控 + 节点冗余	中