Redis 的高可用与扩展本质是在 容量、可用性、一致性、复杂度、成本之间做权衡。下面按常见架构从简单到复杂介绍并给出选型建议。1.架构全景架构高可用水平扩展自动故障转移典型复杂度单机❌❌❌低主从复制⚠️ 需人工切换❌读可扩展❌低Sentinel✅❌读可扩展✅中Redis Cluster✅✅✅中高代理分片Codis 等✅✅⚠️ 依赖组件高云托管 Redis✅✅✅低运维2.单机Standalone架构一个 Redis 进程无复制、无分片。优点部署最简单延迟最低无复制延迟、无脑裂、无 slot 迁移问题适合开发、测试、非关键缓存缺点单点故障进程/机器/网络任一故障即不可用容量受单机内存限制无自动恢复能力适用场景本地开发、CI 测试可丢失、可重建的纯缓存数据量小且业务可接受短暂停机3. 主从复制Master-Replica架构Master ──异步复制── Replica 1 └── Replica 2一主多从写走主读可走从。优点实现简单Redis 原生支持读扩展多个从节点分担读压力从节点可做备份、离线分析SLAVEOF NO ONE提升为主从 Sentinel / Cluster 打基础缺点无自动故障转移主挂了需人工SLAVEOF NO ONE或脚本切换异步复制主宕机可能丢失未同步的写入RPO 0写无法水平扩展仍受单机内存限制从节点滞后时读可能不一致关键配置min-replicas-to-write 1 # 至少 1 个从在线才接受写 min-replicas-max-lag 10 # 从延迟超过 10s 则拒绝写 repl-diskless-sync yes # 大实例同步更快适用场景读多写少可接受短暂不一致有运维能力做手动/半自动切换作为 Sentinel 架构的基础层4. Redis Sentinel哨兵架构App ── Sentinel 发现 Master │ Sentinel 1 / 2 / 3监控 选举 │ Master ── Replica 1, Replica 2Sentinel 负责监控、自动故障转移、通知客户端新主地址。优点自动故障转移RTO 通常 30s–2min取决于配置对应用透明客户端需支持 Sentinel 模式仍是 单分片语义简单支持多 key 事务、Lua、Pub/Sub 无额外限制比 Cluster 运维简单适合中等数据量缺点无法水平扩展写和总容量单 Master 内存上限故障转移期间有 短暂不可用窗口需要 至少 3 个 Sentinel奇数防误判异步复制仍有 数据丢失风险客户端必须正确实现 Sentinel 连接逻辑写死 IP 会在切换后失效典型部署3 Sentinel 1 Master 2 Replica跨 3 个可用区Sentinel 可与 Redis 同机但更推荐独立部署避免 Redis OOM 连带 Sentinel 失效适用场景数据量 单机内存通常几十 GB 以内需要自动 HA但不需要分片业务依赖 多 key 操作、事务、复杂 Lua团队对 Cluster 运维经验不足时的稳妥选择5. Redis Cluster官方集群架构16384 个 hash slot 分布在多个 Master 上 Master A (slot 0-5460) ── Replica A Master B (slot 5461-10922) ── Replica B Master C (slot 10923-16383)── Replica C客户端或 Smart Client 根据 key 的 CRC16 计算 slot直连对应节点。优点水平扩展加节点做 rebalance容量和写吞吐可线性扩展自动故障转移某 Master 挂掉其 Replica 自动提升官方原生方案无第三方代理依赖无单 Master 内存瓶颈缺点运维复杂扩容缩容涉及 slot 迁移可能影响性能多 key 限制只有同一 slot 的 key 才能MGET、事务、MULTI需用 hash tag{user:123}:profile强制同 slot不支持多 DB只有 db0客户端必须 Cluster-aware处理MOVED/ASK重定向小规模3 主 3 从时性价比不如 Sentinel6 个节点只为几十 GB 数据跨 slot 的 Lua 脚本、复杂事务受限扩容注意每次增删节点都会触发 slot 迁移大集群迁移期间延迟可能上升建议提前规划 slot 分布避免频繁 resharding适用场景数据量 超过单机内存百 GB 级以上写 QPS 高需多分片分担业务 key 设计可配合 hash tag无强依赖跨 key 事务有 Cluster 运维经验和监控体系6. 代理分片架构Codis、Twemproxy、Predixy 等架构App ── Proxy 层 ── 后端多个 Redis 实例分片 │ 管控组件Codis Dashboard / FE 等客户端只连代理代理负责路由、分片、部分 HA 逻辑。代表方案方案状态特点Twemproxy维护少轻量代理无自动故障转移配置静态Codis社区活跃但弱于官方有 Dashboard、slot 迁移、较完整运维面Predixy活跃高性能代理支持 Cluster/Sentinel 后端Redis Enterprise商业企业级 HA、CRDB 多活、强 SLA优点对老客户端友好普通 Redis 协议即可无需 Cluster 客户端改造统一入口便于限流、审计、多租户Codis/Enterprise 提供较完善的运维 UI 和迁移工具可灵活组合 Sentinel 后端实现 HA缺点多一层 hop延迟和故障点增加代理本身需 HA多实例 负载均衡Twemproxy 功能较老故障转移能力弱Codis 与官方 Redis Cluster 生态分裂长期维护风险需评估代理可能成为 性能瓶颈超高 QPS 场景需压测适用场景大量 不支持 Cluster 的老应用无法改客户端需要 统一代理层 做治理限流、鉴权、多集群路由已有 Codis/Enterprise 运维体系的企业7. 云托管 RedisAWS ElastiCache、阿里云 Redis、GCP Memorystore架构云厂商提供主从 自动 failover 可选 Cluster 模式用户通过 endpoint 连接。优点运维成本最低备份、补丁、监控、故障转移自动化通常支持跨 AZ、一键扩容Cluster 模式SLA 明确如 99.9%适合合规场景与云监控、VPC、安全组集成好缺点成本高于自建尤其大规格、Cluster版本和功能受云厂商限制部分命令禁用、模块不支持跨云/混合云迁移有锁定风险深度调优、内核级优化空间有限适用场景团队 Redis 运维人力有限需要稳定 SLA 和快速上线已在云上且接受 vendor lock-in8. 多机房 / 多活8.1 主从跨机房冷备/温备同城/异地从节点异步复制优点RPO 低秒级丢失、架构简单缺点异地机房不能自动升主延迟高易脑裂灾备需 人工切换8.2 Redis Enterprise Active-ActiveCRDB多区域双向同步就近读写优点真多活、低延迟缺点商业授权、冲突解决复杂LWW 等、成本高8.3 应用层双写 / 缓存重建各机房独立 Redis数据通过 MQ/DB 同步或故障后重建优点简单、无强一致要求时可用缺点一致性弱适合 纯缓存 而非状态存储9. 选型建议9.1 决策树数据是否必须持久、不可丢 ├─ 是 → Redis 只做缓存层权威数据落 DB选 HA 方案 持久化 └─ 否纯缓存→ 可接受重建 数据量是否超过单机内存~64GB 实用上限 ├─ 否 → 需要自动故障转移吗 │ ├─ 是 → Sentinel推荐默认 HA 方案 │ └─ 否 → 主从读扩展或单机非生产 └─ 是 → 需要分片 ├─ 客户端可改 → Redis Cluster ├─ 客户端不可改 → Codis / Predixy 代理 └─ 少运维 → 云托管 Cluster 是否强依赖多 key 事务 / 跨 key Lua ├─ 是 → 优先 Sentinel单分片Cluster 需 hash tag 改造 └─ 否 → Cluster 更灵活 团队运维能力 ├─ 弱 → 云托管 ├─ 中 → Sentinel └─ 强 → 自建 Cluster 或 Codis9.2 按场景推荐场景推荐架构理由开发测试单机简单够用Session、分布式锁中等规模Sentinel单分片语义完整自动 HA电商商品缓存百 GBRedis Cluster 或云 Cluster容量和 QPS 需分片遗留 Java 应用、Jedis 老版本Sentinel 或 Predixy避免大规模客户端改造金融级低 RPOSentinel 强持久化 业务双写 DBRedis 异步复制本质限制startup 快速上线云托管 Sentinel/Cluster省运维读极多写少主从 Sentinel读走 Replica读写分离10.总结Sentinel大多数中小规模生产的 默认 HA 选择——自动故障转移、语义简单、运维可控。Redis Cluster数据量或写吞吐 超过单机 时的官方分片方案需接受 slot 限制和更高运维成本。代理方案客户端无法升级时的 过渡或治理层需评估代理 HA 和长期维护。云托管省人力、要 SLA 时的务实选择。主从/单机分别适合 有运维的手动 HA 和 非生产不应作为关键业务唯一方案。没有「最好」的架构只有 与数据规模、一致性要求、团队能力、预算 最匹配的方案。若你补充数据量、QPS、是否跨机房、客户端语言可以进一步给出更具体的拓扑和节点数量建议。
