Redis 8.2.2 分布式集群设计与容量规划指南

适用版本：Redis Open Source 8.2.2（8.2 为长期支持版本 LTS）
文档定位：可落地的设计与部署操作手册
编制日期：2026 年 9 月

1. 概述与设计目标

1.1 为什么需要 Redis 分布式

Redis 以内存读写、亚毫秒延迟著称，常被用作缓存、会话存储、分布式锁、排行榜、轻量消息与限流组件。单实例 Redis 在生产环境中存在两类不可接受的风险。其一是可用性风险：进程崩溃、服务器宕机、机房断电都会使访问 Redis 的业务链路整体受阻，缓存不可用时还可能引发请求全部回源、压垮后端数据库的“缓存雪崩”。其二是容量与扩展风险：单实例的内存容量与单核处理能力存在物理上限，业务数据增长或突发流量到来时，纵向升级硬件成本高且有天花板。

分布式通过“数据分片 + 多副本”同时解决这两类问题：把键空间切分到多个主节点，容量与吞吐随节点近线性增长；每个主节点配备副本，主节点故障时副本自动接管，实现高可用。

1.2 设计目标

• 高可用：主节点故障时自动完成故障转移，无需人工切换，目标恢复时间（RTO）为秒级。
• 数据可靠：主从复制配合持久化，主节点故障尽量不丢数据，目标数据丢失量（RPO）趋近于零。
• 水平扩展：通过增加主节点并迁移槽位在线扩容，业务无感知，容量与 QPS 近线性增长。
• 故障隔离：主从副本跨物理机、跨机架、跨可用区分布，避免单机、单柜故障导致主从同时丢失。
• 容量可预测：节点数由 QPS 与数据量通过公式反推，预留统一余量、触水位再扩容。

1.3 Redis 8.2 的关键特性

Redis 8.2 为长期支持版本（LTS），在开源版本中已正式发布（GA），支持周期长，适合作为生产标准化版本。

• 性能与内存：相比 8.0，部分命令延迟降低、整体吞吐提升，并优化了键与 JSON 的内部存储、显著降低内存占用。
• Streams 增强：新增 XACKDEL、XDELEX 等命令，简化消费组管理与流生命周期处理。
• 位图增强：BITOP 新增 DIFF、DIFF1 等逻辑运算符，可在一条命令内完成更复杂的集合运算。
• 可观测性：新增按槽位（per-slot）的用量指标与基础数据类型的键大小分布，便于容量治理。
• 能力内置：8.x 默认集成搜索、JSON、时序、Bloom 等能力，并提供原生向量集合（Vector Set）以支持语义检索与 RAG。

版本与许可提示：本指南命令、参数与默认值均以 Redis Open Source 8.2.2 为准。Redis 8.x 采用 RSALv2 与 SSPLv1 双许可，对云托管转售场景有约束，企业内部自用通常不受影响；若有合规疑虑，可评估基于宽松许可的开源分支。集群槽位总数在 8.2 中仍为 16384。

2. 核心概念与部署模式选型

2.1 四种部署模式对比

2.2 主从复制原理

主从复制中，副本（replica）通过replicaof（旧称slaveof）指向主节点。首次连接时进行全量同步：主节点生成 RDB 快照发送给副本，副本加载后追平；之后通过复制积压缓冲区（replication backlog）持续进行增量同步。网络中断恢复后，若偏移量仍在积压缓冲范围内则只补增量，否则重新全量。

• 复制默认为异步：主节点写成功即返回，副本稍后追平，因此极端情况下主节点宕机可能丢失尚未复制的少量写入。
• 可使用无盘复制（repl-diskless-sync）直接通过套接字发送 RDB，降低主节点磁盘压力。
• WAIT命令可阻塞等待指定数量副本确认，用于在关键写入上增强一致性，但会牺牲部分延迟。

2.3 Sentinel 的定位与边界

Sentinel 是独立部署的哨兵进程，通过监控、通知、自动故障转移与配置提供四项能力。主节点故障时，多个 Sentinel 经主观下线（SDOWN）、客观下线（ODOWN）判定后选举领导者，将一个副本提升为主并通知客户端更新地址。

Sentinel 不做分片：Sentinel 只解决“单点故障自动切换”，数据仍全部集中在一个主节点上，内存与写吞吐无法水平扩展。当数据量或写 QPS 超过单机能力时，应直接使用原生 Cluster，而非 Sentinel。

2.4 为什么生产选择原生 Cluster

• 同时具备分片与高可用：16384 槽均分到多个主节点，每个主节点挂副本，容量、读写均可水平扩展。
• 故障转移内置：无需额外部署 Sentinel，集群节点通过 gossip 互相探测并投票完成切换。
• 在线扩缩容：新增主节点只需迁入部分槽位，下线节点只需迁出槽位，过程业务无感。
• 生态成熟：Lettuce、Jedis、redis-py 等主流客户端均原生支持集群路由与自动刷新。

3. Redis Cluster 分片与高可用原理

3.1 16384 个哈希槽与键定位

Redis Cluster 不使用一致性哈希，而是把全部键空间固定划分为16384 个哈希槽。键所属槽位由 CRC16 校验值对 16384 取模得到：

slot = CRC16(key) mod 16384 # 例：3 个主节点时槽位均分（redis-cli --cluster 自动分配） # master-A: slots 0-5460 # master-B: slots 5461-10922 # master-C: slots 10923-16383

槽位数固定为 16384，不随节点数变化。这样在增删节点、迁移槽位时，键到槽位的映射保持稳定，只需在节点间搬运槽位，无需对全部键重新哈希。官方取 16384 的原因之一是：节点心跳会携带本节点负责槽位的位图，16384 位约 2KB，在建议的集群规模（约千节点）内网络开销可控。

3.2 Gossip 协议与集群总线

集群中每个节点定期通过 gossip 向其他节点发送 PING/PONG，消息中携带部分节点的状态（存活、槽位、主从、复制偏移等），最终所有节点收敛到一致的集群拓扑。

• 节点间通过集群总线端口通信，端口号默认为客户端端口 + 10000（如 6379 对应 16379），需在防火墙 / 安全组放通。
• 客户端端口（6379）接收业务命令，总线端口（16379）只用于节点间通信，二者协议不同。

3.3 故障检测：PFAIL 与 FAIL

• PFAIL（主观下线）：节点 A 在cluster-node-timeout内未收到节点 B 的 PONG，A 在本地把 B 标记为 PFAIL（仅 A 自己可见，不可信）。
• FAIL（客观下线）：当集群中“负责槽位的主节点”里有超过半数都报告 B 为 PFAIL，任一节点把 B 升级为 FAIL，并通过 gossip 向全集群广播。

3.4 自动故障转移

故障主节点的副本检测到主为 FAIL：

1. 该主的多个副本按复制偏移（数据新旧）、优先级等排序，确定候选；
2. 候选副本向集群中其他健康主节点请求投票；
3. 获得多数主节点投票的副本当选；
4. 当选副本执行提升（相当于SLAVEOF NO ONE），接管原主全部槽位；
5. 新主通过 gossip 广播新拓扑，客户端按重定向刷新路由；
6. 原故障节点恢复后，作为副本重新加入并追平数据。

副本是自动切换的前提：若故障主节点没有任何存活副本，则其槽位无主。cluster-require-full-coverage为 yes（默认）时整个集群停止对外服务；设为 no 时仅该部分槽位不可用、其余槽位继续。因此每个主节点至少配备一个副本，是高可用的硬性要求。

3.5 MOVED 与 ASK 重定向

• MOVED：槽位已永久归属另一个节点。客户端收到后应更新本地槽位路由表，并向正确节点重试该命令。
• ASK：槽位正处于在线迁移过程中，仅本次临时重定向到目标节点，客户端不应更新本地路由表。

支持集群的客户端（Lettuce、Jedis Cluster、redis-py Cluster）会自动处理重定向并在拓扑变化时刷新，业务通常无感知。

3.6 Hash Tag 与多键约束

集群要求多键命令（MGET/MSET、事务 MULTI、Lua 脚本）涉及的键必须位于同一槽位，否则返回CROSSSLOT错误。通过 Hash Tag，即键名中第一个花括号{ }内的子串参与槽位计算，可把一组相关键强制归到同一槽位：

# 只有 { } 内的部分参与 CRC16，下列键落在同一槽位，可原子操作user:{100}.base user:{100}.profile user:{100}.counters# 注意：集群模式只使用 db0，不支持 SELECT 切换多个逻辑库

3.7 副本拓扑与机架分布

• 每个主节点可配置一个或多个副本；副本不直接对外提供写，读可经READONLY在副本上分摊。
• 主节点与它的副本必须分散在不同物理机、机架，最好跨可用区，避免单机、单柜故障同时摧毁主从。
• Redis Cluster 不内置机架感知标签，需通过部署规划、调度反亲和保证（K8s 用podAntiAffinity）。

4. 容量规划公式

容量规划要回答四个问题：需要多少个主节点、每个主配几个副本、共多少实例、是否需要拆分多集群。主节点数由“QPS”和“内存数据量”两条线分别反推，取较大值。

4.1 关键输入指标

4.2 单节点能力基线

能力值必须压测校准：单节点能力随命令复杂度、读写比例、是否开启多线程 I/O、持久化策略与硬件而变化。正式规划应在目标硬件上用redis-benchmark压测，用实测值替换公式中的 60000 与 25。

4.3 主节点数公式

# QPS 线：按单主安全 6 万 M_qps = ceil( Q / 60000 ) # 内存线：按单实例 m GB（默认 25） M_mem = ceil( D / m ) # 主节点数：两条线取大，且集群至少 3 个主节点 M = max( M_qps, M_mem, 3 )

4.4 副本数与读扩展公式

# 基础高可用：每个主至少 1 个副本 # 读扩展：副本执行 READONLY 后可分担读（异步复制，可能读到略旧数据） # 保守起见把主节点读能力留给突发，读压力由副本承担： 每主副本数 R = max( 1, ceil( Rq / (M × 60000) ) ) # 不可重建的关键数据（会话、分布式锁）可取 R = 2

4.5 实例总数与物理内存核算

实例总数 = M × (1 + R) # maxmemory 建议 ≤ 物理内存的 60%，为内存碎片、AOF 重写 # 的写时复制（COW）、客户端与复制缓冲留足空间： 单机所需物理内存 = 单机承载数据量 / 0.6 # 例：单机 1主1从、每实例 25GB # 需 (25+25)/0.6 ≈ 83GB，工程取 96/128GB 机型

4.6 集群数量公式

单集群主节点过多会放大 gossip 通信与故障切换的影响面。工程上建议单集群主节点控制在约16~20 个以内，超过则按业务域拆分为多套独立 Cluster。

集群数 K = max( 1, ceil( M / 16 ) ) # 多集群之间不自动同步数据，键与多键操作必须在设计上按业务域隔离 # 跨集群复制需借助外部同步任务，不能像单集群那样透明访问

4.7 容量余量与水位

• 统一预留25%~30%余量，用于突发流量与数据增长。
• QPS / CPU 水位：70% 关注、80% 扩容、85%~90% 紧急限流。
• 内存通过maxmemory与淘汰策略（maxmemory-policy）兜底，缓存场景一般用allkeys-lru。
• 扩容周期长的物理机 / 内存应在 70% 水位即启动采购，避免高水位被动。

5. 完整推算算例

本章给出五个算例，完整演示如何把业务负载代入第 4 章公式，逐步推算主节点、副本、实例与集群数。前四个对应 S/M/L/XL 四档基线，第五个演示读多写少场景下用副本而非主节点做读扩展。

5.1 算例一：小型（2 万 QPS，30GB）

输入：总 QPS Q=20000，热数据 D=30GB，m=25GB

步骤 1 两条线： M_qps = ceil(20000/60000) = 1 M_mem = ceil(30/25) = 2 步骤 2 主节点：M = max(1, 2, 3) = 3 步骤 3 副本与实例：R=1，实例 = 3×(1+1) = 6 步骤 4 集群：K = ceil(3/16) = 1

结论：1 套集群、3 主 3 从共 6 实例，建议 3 台物理机、单机 1主1从（64GB 机型）。每主约 10GB、承载约 6700 QPS，余量充裕。

5.2 算例二：中型（10 万 QPS，200GB）

输入：Q=100000，D=200GB

M_qps = ceil(100000/60000) = 2 M_mem = ceil(200/25) = 8 M = max(2, 8, 3) = 8 R=1，实例 = 8×2 = 16；集群 K=1

结论：1 套集群、8 主 8 从共 16 实例，建议 8 台物理机、单机 1主1从（128GB）。该规模由“内存”主导（QPS 线只需 2 主，内存线需 8 主），每主恰好约 25GB。

5.3 算例三：大型（40 万 QPS，500GB）

输入：Q=400000，D=500GB

M_qps = ceil(400000/60000) = 7 M_mem = ceil(500/25) = 20 M = max(7, 20, 3) = 20 R=1，实例 = 20×2 = 40；集群 K=1