真实面经题目 · 原创解析
Redis 的高可用不是单一能力，而是复制、故障检测、自动切换、分片容灾、持久化、客户端重连和监控治理共同组成的体系。主从复制提升读扩展和副本冗余，哨兵负责发现主节点故障并自动完成主从切换，Cluster 通过分片和多主多从避免单机容量与单点问题，AOF/RDB 持久化降低进程或机器故障后的数据损失。真正回答这道题时，要同时说明 Redis 能恢复服务、能减少数据丢失，但不能承诺在所有极端场景下零丢失，尤其要讲清复制延迟、脑裂和一致性取舍。
Redis 高可用主要靠几层机制实现。第一层是主从复制，主节点写入后把数据异步同步到从节点，从节点可以承担读流量，也可以在主节点故障时被提升为新主。第二层是哨兵机制，Sentinel 会持续探测主从节点状态，通过主观下线和客观下线判断故障，并在多数哨兵达成共识后选举领导者执行 failover。第三层是自动故障转移，哨兵会从从节点中选择复制偏移量较新、优先级合适、状态健康的节点晋升为主，并通知其他从节点和客户端更新连接。第四层是 Redis Cluster，它把 key 分布到 16384 个 hash slot 上，由多个主节点分别承载分片，每个主节点配置从节点，某个主节点故障时由其从节点接管，从而同时解决容量扩展和分片级高可用。第五层是持久化，RDB 适合快速恢复快照，AOF 适合降低数据丢失窗口，生产中常组合使用。最后还要补充高可用的边界：Redis 复制默认是异步的，主节点宕机前尚未复制的数据可能丢失；网络分区下可能出现脑裂，需要通过合理的 min-replicas-to-write、min-replicas-max-lag、哨兵 quorum、客户端超时重连、监控告警等手段降低风险。因此 Redis 高可用的本质是提高服务连续性和恢复速度，同时在性能、可用性和数据一致性之间做工程权衡。
Redis 高可用的核心目标不是让单个进程永远不挂，而是在节点故障、机器故障、网络抖动或进程重启时，系统仍能较快恢复对外服务，并尽量减少数据丢失。评价 Redis 高可用通常看几个指标：是否存在单点、故障检测是否及时、切主是否自动、客户端是否能发现新主、数据是否可恢复、故障期间是否可控降级。面试中要避免只回答“因为 Redis 有哨兵”，更完整的答案应覆盖复制冗余、自动 failover、分片容灾、持久化恢复和运维监控。
主从复制是 Redis 高可用的基础。主节点负责写入，从节点通过复制流接收主节点数据，形成副本冗余。当主节点故障时，从节点具备被提升为新主的条件。Redis 复制包括全量复制和部分复制：从节点首次同步或复制积压缓冲区无法覆盖缺口时需要全量复制；短暂断线后如果复制偏移量仍在 backlog 范围内，可以进行部分复制，降低恢复成本。复制还可以带来读扩展，但读从库要注意延迟和读到旧数据的问题。
Sentinel 是 Redis 主从模式下的高可用控制面，负责监控、通知、选主和配置更新。哨兵会周期性向 Redis 节点发送探测命令，如果某个哨兵认为主节点不可达，会标记主观下线；当足够数量的哨兵都认为主节点不可达时，才会形成客观下线。这样可以避免单个哨兵误判导致错误切换。客观下线后，哨兵之间会选出 leader，由 leader 执行故障转移流程。
自动 failover 的流程一般是：确认主节点客观下线，选择一个合适的从节点晋升为新主，让其他从节点复制新主，更新主从拓扑，并向客户端发布新主地址。选从节点时通常会综合 slave-priority、复制偏移量、复制状态、网络连通性等因素，优先选择数据更完整、状态更健康的副本。这个过程降低了人工介入时间，但切换期间仍会有短暂不可写、连接断开或请求失败，所以客户端必须具备重试和重新发现主节点的能力。
Redis Cluster 通过 16384 个 hash slot 把数据分布到多个主节点，每个主节点负责一部分 slot，从而突破单机内存、CPU 和网络上限。每个主节点通常配置一个或多个从节点，当某个主节点故障时，它的从节点可以被提升为新主并继续服务对应 slot。Cluster 的高可用是分片级的：只要故障分片有可晋升副本，集群就能继续提供服务；如果某个 slot 所属主节点及其副本都不可用，则该 slot 的数据无法服务，集群可用性会受影响。
复制和 failover 解决的是服务接管问题，持久化解决的是进程重启或机器恢复后的数据恢复问题。RDB 是周期性快照，恢复速度快、文件紧凑，但两次快照之间的数据可能丢失；AOF 记录写命令，配合 everysec 策略通常能把数据丢失窗口控制在较小范围，但文件更大、恢复可能更慢。生产环境常同时开启 RDB 和 AOF，用 RDB 提供快照兜底，用 AOF 降低数据丢失窗口。
Redis 主从复制默认是异步复制，主节点写成功返回客户端时，并不保证数据已经同步到所有从节点。如果主节点在写入后、复制到从节点前宕机，新主可能缺少这部分数据，这就是高可用和强一致之间的典型取舍。可以通过 WAIT 命令等待一定数量副本确认，或配置 min-replicas-to-write 与 min-replicas-max-lag 限制主节点在副本不足或延迟过高时继续接收写入，但这些手段会牺牲部分可用性和写入延迟。
脑裂通常发生在网络分区场景：旧主没有真正宕机，只是与哨兵或多数节点失联，哨兵把某个从节点提升为新主；与此同时，旧主仍可能被部分客户端访问并继续接收写入，导致出现两个主节点。网络恢复后，旧主会被降级并复制新主，旧主分区期间接收的写入可能丢失。降低脑裂风险的关键是让旧主在无法连接足够副本时拒绝写入，并让客户端遵循哨兵或集群拓扑发现结果，避免长期写入孤立主节点。
Redis 高可用不是服务端单方面完成的，客户端也要配合。哨兵模式下客户端应支持 Sentinel 地址列表，主节点变化后重新查询新主并重连；Cluster 模式下客户端要理解 MOVED、ASK 重定向并维护 slot 到节点的映射。运维侧需要监控主从状态、复制延迟、role 变化、AOF 重写、RDB 保存、内存水位、连接数、慢查询、故障切换次数和客户端错误率。没有客户端重连和监控告警，高可用机制即使触发，也可能表现为业务长时间不可用。
Sentinel 主要解决一主多从架构中的自动故障转移问题，本身不做数据分片；Cluster 同时解决数据分片和分片级高可用问题。数据量不大但需要主从切换时可以用 Sentinel，数据量或吞吐量需要水平扩展时更适合 Cluster。
不是。Redis 默认使用异步复制，主节点写入成功返回时，从节点可能还没有收到或应用该写入。因此故障切换后，新主可能缺少旧主最近的一部分数据。
单个哨兵探测主节点超时后会标记主观下线，但只有达到配置的 quorum 数量后，才会形成客观下线。随后哨兵选举 leader，由 leader 执行故障转移。
可以增加从节点数量、控制复制延迟、使用 WAIT 等待副本确认、配置 min-replicas-to-write 和 min-replicas-max-lag、合理设置 AOF everysec，并保证主从部署在不同故障域。但数据越安全，写入延迟和可用性成本通常越高。
脑裂是指网络分区后，旧主和新主在一段时间内都可能对外提供写服务。网络恢复后旧主通常会被降级并同步新主，旧主分区期间接收的数据可能被覆盖或丢失。
客户端要支持连接失败后的重试、超时控制、连接池刷新、哨兵新主发现或 Cluster slot 映射更新。否则服务端已经完成切主，业务仍可能因为连接旧主或缓存旧拓扑而持续失败。
RDB 和 AOF 不负责自动切主，但负责数据恢复。RDB 提供快照恢复能力，AOF 通过追加写命令降低数据丢失窗口，两者常组合使用来增强灾难恢复能力。
