Redis高可用面试全攻略：从原理到实战的深度解析
在分布式系统架构中，Redis高可用是后端开发面试的绝对核心。本文深入剖析主从复制、哨兵模式、Cluster集群以及持久化策略，结合真实面试场景，为您提供一份详尽的备考指南。
一、为什么面试官如此关注 Redis高可用？
在现代互联网架构中，Redis不仅是缓存利器，更承担着分布式锁、消息队列、计数器等关键角色。一旦Redis实例宕机，可能导致整个系统雪崩。因此，Redis高可用方案的设计与实现能力，直接反映了候选人对分布式系统稳定性的理解深度。
面试官通常不会只问“什么是Redis”，而是会追问：“如果Redis主节点突然宕机，如何保证服务不中断？”、“数据一致性如何保证？”、“集群扩容时数据如何迁移？”这些问题直击Redis高可用的核心痛点。
⚡ 核心考点：故障转移
理解主从切换的自动化机制，掌握Sentinel和Cluster在故障检测上的区别。
⚡ 核心考点：数据一致性
同步复制与异步复制的权衡，以及半同步复制在高可用场景下的应用。
⚡ 核心考点：容量规划
如何根据业务增长规划集群节点数，以及如何优雅地进行在线扩容。
二、基石：主从复制与数据同步机制
Redis高可用的第一步是实现数据冗余。主从复制（Master-Slave Replication）是构建高可用架构的基础。在这一模式下，一个Master节点可以向多个Slave节点同步数据，实现读写分离和数据备份。
1. 全量同步与增量同步
当Slave节点首次连接Master时，会发起全量同步。Master节点会生成RDB文件发送给Slave，Slave加载该文件完成初始同步。此后，Master会将执行的写命令异步发送给Slave，实现增量同步。
2. 断线重连机制
如果网络抖动导致主从断开，Slave会在后台线程中尝试重新连接。重连成功后，如果PSync命令支持部分重同步（Partial Resynchronization），则只需同步断线期间产生的新数据，避免再次全量同步带来的性能开销。
| 特性 | 全量同步 (Full Resync) | 部分重同步 (Partial Resync) |
|---|---|---|
| 触发条件 | 首次连接、主从ID不一致、缓冲区满 | 短暂断线、主从ID一致、缓冲区数据完整 |
| 数据量 | 全量数据 | 断线期间的写命令 |
| 性能影响 | 高，可能阻塞Master | 低，异步进行 |
三、自动化运维：哨兵模式（Sentinel）详解
主从复制虽然解决了数据冗余，但无法自动进行故障转移。当Master宕机时，需要人工干预选举新的Master，这在高可用场景中是不可接受的。Redis哨兵模式应运而生，它实现了监控、通知和自动故障转移。
1. 哨兵架构组成
哨兵系统由一个或多个Sentinel节点组成。每个Sentinel节点都会定期向Master、Slave及其他Sentinel节点发送PING命令，以判断其是否在线。
2. 故障转移流程
单个哨兵认为节点宕机
当某个哨兵在指定时间内未收到Master的回复，将其标记为主观下线。
多数哨兵确认节点宕机
其他哨兵在指定时间内也认为该Master主观下线，且数量达到quorum阈值，则标记为客观下线。
选举哨兵领导者
一个哨兵被选为领导者，负责执行故障转移操作。
选举新Master
领导者从Slave中选择一个优先级最高、复制偏移量最大、运行ID最小的节点提升为Master，并通知其他Slave指向新Master。
哨兵模式核心配置参数
监控主节点，quorum为判定客观下线所需的最小哨兵数
sentinel monitor mymaster 127.0.0.1 6379 2故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 180000并行同步的slave数量
sentinel parallel-syncs mymaster 1向下兼容的客户端配置
sentinel down-after-milliseconds mymaster 30000
哨兵模式的局限性
尽管哨兵模式解决了自动故障转移，但它仍存在以下问题：
- 【】单点问题：虽然哨兵集群本身是高可用的，但如果所有哨兵都配置在同一个物理机上，依然面临单点风险。
- 【】写能力瓶颈：写操作只能发生在Master节点，Slave节点只读，无法水平扩展写性能。
- 【】存储能力瓶颈：单个Master的内存有限，无法存储海量数据。
面试场景题：脑裂问题
问题：在网络分区情况下，哨兵可能将Master和Slave误判为不同集群，导致“脑裂”，产生两个Master。
解答：Redis 4.0+引入了`min-slaves-to-write`和`min-slaves-max-lag`参数。如果Master检测到与之同步的Slave数量少于`min-slunes-to-write`，或者所有Slave的最后通信时间超过`min-slunes-max-lag`，Master将拒绝写入请求，从而保证数据一致性。
四、终极方案：Redis Cluster集群架构
为了解决哨兵模式无法水平扩展写性能和存储容量的问题，Redis Cluster是官方推荐的分布式解决方案。它去中心化，节点间通过Gossip协议通信，实现了数据的自动分片。
1. 数据分片：Hash Slot
Redis Cluster将所有数据划分为16384个哈希槽（Hash Slot）。每个Key通过`CRC16(key) % 16384`计算落入某个槽。集群中的每个节点负责一部分槽。当客户端访问Key时，先计算槽位，如果该槽不在当前节点，节点会返回`MOVED`重定向错误，客户端再请求正确的节点。
2. Gossip协议
集群节点间通过Gossip协议交换元数据，如节点状态、槽位分布等。相比Zookeeper的强一致性，Gossip协议最终一致性，但具有更高的可用性和扩展性。
📊 节点角色
每个节点既是主节点也可能是从节点。主节点处理读写请求，从节点复制主节点数据并提供故障转移备份。
🔄 在线扩容
无需停机即可添加新节点。通过`CLUSTER MEET`加入节点，使用`CLUSTER ADDSLOTS`迁移槽位，实现数据均衡。
🛡️ 高可用保障
类似哨兵，Cluster内部也包含故障检测与转移机制。如果主节点宕机且其从节点未能及时提升，集群将进入FAIL状态，直至满足恢复条件。
3. 跨槽操作限制
由于数据分散在不同节点，Redis Cluster不支持多键跨节点事务。如果事务中的Key属于不同槽位，操作将被拒绝。这要求开发人员在设计数据结构时，尽量将相关的Key通过`{tag}`方式哈希到同一槽位。
五、数据持久化：RDB与AOF的深度对比
在Redis高可用面试中，持久化策略的选择直接影响数据恢复速度和系统性能。面试官常问：“RDB和AOF有什么区别？生产环境如何选择？”
1. RDB (Redis Database)
RDB是数据的快照。它通过Fork子进程将内存数据写入临时文件，完成后替换旧文件。优点是文件紧凑、恢复速度快；缺点是可能丢失最后一次快照后的数据。
2. AOF (Append Only File)
AOF记录每次写命令。Redis启动时重放命令重建数据。优点是数据安全性高（可配置每秒同步）；缺点是文件体积大、恢复速度慢。
3. 混合持久化 (Redis 4.0+)
结合了RDB和AOF的优点。AOF重写时，先写入RDB格式的全量数据，再追加AOF格式的增量数据。既保证了恢复速度，又保证了数据安全性。
| 对比维度 | RDB | AOF | 混合持久化 |
|---|---|---|---|
| 数据安全性 | 低（可能丢失数据） | 高（可秒级同步） | 高 |
| 恢复速度 | 快 | 慢 | 较快 |
| 磁盘占用 | 小 | 大 | 中等 |
| CPU占用 | 间歇性高（Fork时） | 持续性（写命令时） | 中等 |
六、缓存实战：穿透、击穿与雪崩
除了架构本身，Redis高可用还涉及缓存层的稳定性。以下是三个经典问题的解决方案：
1. 缓存穿透
现象：查询不存在的数据，请求直达数据库。
解决：缓存空对象、布隆过滤器（Bloom Filter）。
2. 缓存击穿
现象：热点Key过期，大量请求瞬间打到数据库。
解决：互斥锁（Mutex Key）、逻辑过期（不设TTL，后台异步更新）。
3. 缓存雪崩
现象：大量Key同时过期或Redis集群宕机。
解决：Key过期时间加随机值、Redis集群高可用、多级缓存、限流降级。
七、高频面试题深度解答
以下整理了近一年互联网大厂关于Redis高可用的高频面试题，涵盖原理与实战。
Q1: Redis Cluster中，如果Master宕机，但它的从节点尚未同步最新数据，会发生什么？
A: 选举新Master时，会优先选择复制偏移量大的从节点。如果数据不一致，可能导致数据丢失。因此，业务上应尽量减少对强一致性数据的依赖，或在应用层做补偿。
Q2: 如何设计一个支持高并发的分布式锁？
A: 使用Redisson客户端，基于RedLock算法。注意锁的续期机制（Watch Dog），防止业务未执行完锁过期。同时要考虑时钟漂移问题。
Q3: Redis大Key问题如何发现与处理？
A: 发现：使用`redis-cli --bigkeys`或客户端监控工具。处理：拆分Key（如Hash结构）、异步删除、设置过期时间。
Q4: Redis持久化与高可用如何配合？
A: 开启AOF每秒同步，确保数据不丢失。Cluster模式下，每个节点独立持久化。故障转移时，新Master加载自己的AOF文件，保证数据最新。