Redis高可用演进分三层：主从复制解决数据备份与读写分离，但需人工故障转移；哨兵模式在此基础上实现自动故障转移，通过主观/客观下线与选举机制提升可用性；Cluster集群进一步支持水平分片与多主架构，以16384个哈希槽实现弹性扩容与部分可用保障。
面试中讲清楚 Redis 高可用和分布式，关键不是堆名词，而是用一条逻辑线串起三个演进层级：主从复制解决“有备份”，哨兵解决“自动切换”，Cluster 解决“能扩容”。每层回答紧扣“问题—方案—机制—局限”四要素，就能体现系统性。
主从复制：高可用的起点，解决单点数据丢失
这是所有高可用方案的地基。核心是“一主多从+异步复制”，主节点处理写请求，从节点只读、同步数据。
- 怎么同步：首次连接走全量同步（RDB快照 + 后续增量命令）；断线重连优先用 PSYNC2.0 的部分重同步（靠复制偏移量 + 环形缓冲区）
- 为什么只是基础：主挂了，从节点不会自动上位；客户端仍需手动改配置指向新主；存在数据丢失窗口（异步复制）
-
典型配置项：
replicaof <ip> <port>（新版替代slaveof），repl-backlog-size控制缓冲区大小
哨兵（Sentinel）：实现自动故障转移，解决人工介入延迟
哨兵是独立进程，不存数据，专注监控与决策。它把主从架构“活”了起来。
- 三阶段流程：主观下线（单哨兵超时未响应）→ 客观下线（≥ quorum 个哨兵达成共识）→ 选举领导者 → 执行故障转移（选从、提升、重配置）
- 防脑裂设计：选举要求多数派参与；故障转移前会检查从节点的复制偏移量，优先选数据最新的从节点
-
客户端怎么用：不直连 Redis，而是通过哨兵获取当前主节点地址（
SENTINEL get-master-addr-by-name mymaster），支持自动重试与重定向
Redis Cluster：真正的分布式，解决海量数据与横向扩展
Cluster 是无中心架构，靠 Gossip 协议维系集群状态，核心是哈希槽（16384 个）分片机制。
- 数据怎么分布：每个 key 按 CRC16 算法映射到 0–16383 的槽位；每个主节点负责若干连续槽位；客户端先算槽，再找对应节点
- 高可用怎么保障：每个主节点配至少一个从节点；主挂后，其从节点在多数主节点同意下自动晋升；故障期间，其他槽位仍可服务（部分可用）
- 为什么是 16384 个槽：太少影响扩缩容粒度，太多增大心跳包体积；16384 经压缩后集群状态仅约 2KB，平衡了通信开销与扩展性
对比选型与落地要点
没有银弹，选型看业务阶段：
- 小流量、强一致性要求不高 → 主从 + 应用层简单兜底
- 中等规模、需自动恢复 → 哨兵（建议至少 3 个哨兵节点，避免单点）
- 大流量、大数据量、长期演进 → Cluster（注意客户端必须支持重定向，禁用多 key 操作如
mget跨槽） - 共性风险提醒：三者都依赖异步复制，极端情况下（主挂且未同步完）都有丢数据可能；生产环境务必开启
min-replicas-to-write等参数增强写安全
