Redis 高可用架构演进：主从、哨兵与 Cluster 的选型边界

高可用不是「部署个集群」那么简单

Redis 的高可用方案有三级：主从复制、哨兵（Sentinel）、集群（Cluster）。很多团队直接上 Cluster，结果被多键操作限制、运维复杂度打个措手不及；也有团队主从跑了好几年靠人肉切换。正确的思路是按「数据规模 + 故障容忍度 + 运维能力」三级演进，不跳级。一、主从复制：最朴素的起点

一主多从，读写分离。解决的是读扩展与数据冗余，但不解决自动故障转移——主挂了要人工提升从库。适合：读多写少、有 DBA 值守、业务能容忍分钟级恢复的场景。关键参数：replicaof 配置、min-replicas-to-write（主库至少 N 个健康从库才接受写，防止脑裂丢数据）。

二、哨兵：自动故障转移的标准解

Sentinel 三节点（奇数）监控主从，主挂后自动选主并通知客户端重新连接。适合：数据量单机可容纳（内存 ≤ 单机可用内存）、写 QPS 单机可扛、需要自动故障转移的绝大多数业务。三个运维要点：

1. 脑裂防护：min-replicas-to-write=1 + min-replicas-max-lag=10，把旧主隔离期间接受的写入降到最低（不能完全杜绝，但把丢失窗口压到秒级）；
2. 客户端必须用哨兵模式连接（不是直连主库 IP），否则切换后客户端不知道新主；
3. 副本优先级与数据校验：故障切换后核对新主数据完整性，replica-priority 排除不适合升主的节点。

三、Cluster：数据规模倒逼时的选择

16384 个 slot 按 hash tag 分片，数据与写入压力分散到多主多从。触发条件：内存超出单机上限或写 QPS 单机扛不住。三个代价要提前接受：

1. 多键操作受限：跨 slot 的 MGET、事务、Lua 不支持——用 hash tag（{user1000}.follow）把关联键固定到同一 slot，业务设计期就要规划 key 结构；
2. 运维复杂度翻倍：slot 迁移、故障恢复、客户端兼容（必须用 Cluster 模式 SDK）都是新工作量；
3. 扩容要搬数据：加节点触发 slot 重分配，大 key 会拖慢迁移——拆分大 key（hash 分段、大 value 压缩）是 Cluster 化的前置工作。

四、云托管与容灾兜底

云上 Redis（云数据库 Redis 版）默认托管了哨兵/集群的高可用逻辑，还带备份恢复、多可用区容灾——中小团队直接用云托管，把精力留给 key 设计与容量规划。无论哪种方案，两条兜底必须做：定期 RDB/AOF 备份并演练恢复（高可用防机器故障，备份防数据被误删）、关键业务的缓存击穿降级预案（Redis 全挂时业务不能跟着全挂）。

演进路径一句话：数据量单机放得下就用主从+哨兵，放不下再上 Cluster；哨兵解决了「谁当主」，Cluster 解决的是「一台装不下」——不要为了架构先进性提前支付 Cluster 的复杂度。