适用版本Redis Open Source 8.2.28.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 四种部署模式对比部署模式数据分片自动故障转移容量 / 吞吐适用场景单机 standalone无无受限于单机开发测试、非关键场景主从复制无需人工或脚本读可扩展、写仍单点读多写少、可接受人工切换Sentinel 哨兵无有哨兵投票写仍单点、内存单机数据量小、只需高可用原生 Cluster16384 槽分片有集群内置随主节点近线性扩展生产大容量、高并发推荐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 与 FAILPFAIL主观下线节点 A 在cluster-node-timeout内未收到节点 B 的 PONGA 在本地把 B 标记为 PFAIL仅 A 自己可见不可信。FAIL客观下线当集群中“负责槽位的主节点”里有超过半数都报告 B 为 PFAIL任一节点把 B 升级为 FAIL并通过 gossip 向全集群广播。3.4 自动故障转移故障主节点的副本检测到主为 FAIL该主的多个副本按复制偏移数据新旧、优先级等排序确定候选候选副本向集群中其他健康主节点请求投票获得多数主节点投票的副本当选当选副本执行提升相当于SLAVEOF NO ONE接管原主全部槽位新主通过 gossip 广播新拓扑客户端按重定向刷新路由原故障节点恢复后作为副本重新加入并追平数据。副本是自动切换的前提若故障主节点没有任何存活副本则其槽位无主。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 关键输入指标输入指标符号说明 / 采集方式峰值总 QPSQ读写每秒命令数取业务高峰峰值其中写 / 读 QPSW / Rq写不可由副本分摊读可在只读副本扩展热数据量DGB需驻留内存的键与数据结构总字节单实例内存上限m通用 25GB大内存机型可取 40GB数据增长周期g按 6~12 个月增长预留纳入余量4.2 单节点能力基线能力单元经验安全值取值依据单主承载 QPS6 万GET/SET 混合、适度 pipeline理论峰值约 8~10 万按 60% 取安全值单实例内存上限25GB大内存机 40GB实例越小RDB/AOF 重写、重启加载与故障转移越快能力值必须压测校准单节点能力随命令复杂度、读写比例、是否开启多线程 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 24.5 实例总数与物理内存核算实例总数 M × (1 R) # maxmemory 建议 ≤ 物理内存的 60%为内存碎片、AOF 重写 # 的写时复制COW、客户端与复制缓冲留足空间 单机所需物理内存 单机承载数据量 / 0.6 # 例单机 1主1从、每实例 25GB # 需 (2525)/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 万 QPS30GB输入总 QPS Q20000热数据 D30GBm25GB步骤 1 两条线 M_qps ceil(20000/60000) 1 M_mem ceil(30/25) 2 步骤 2 主节点M max(1, 2, 3) 3 步骤 3 副本与实例R1实例 3×(11) 6 步骤 4 集群K ceil(3/16) 1结论1 套集群、3 主 3 从共 6 实例建议 3 台物理机、单机 1主1从64GB 机型。每主约 10GB、承载约 6700 QPS余量充裕。5.2 算例二中型10 万 QPS200GB输入Q100000D200GBM_qps ceil(100000/60000) 2 M_mem ceil(200/25) 8 M max(2, 8, 3) 8 R1实例 8×2 16集群 K1结论1 套集群、8 主 8 从共 16 实例建议 8 台物理机、单机 1主1从128GB。该规模由“内存”主导QPS 线只需 2 主内存线需 8 主每主恰好约 25GB。5.3 算例三大型40 万 QPS500GB输入Q400000D500GBM_qps ceil(400000/60000) 7 M_mem ceil(500/25) 20 M max(7, 20, 3) 20 R1实例 20×2 40集群 K1