4. Redis高可用与集群面试题
🎯 章节定位：Redis 高可用是分布式缓存面试的必考核心板块，覆盖从“主从复制”到“哨兵自动故障转移”再到“Cluster 去中心化分片”的完整演进路径。面试官通过此主题考察你的分布式系统理解深度、故障处理经验及架构选型能力。
📊 三种模式关键对比
| 维度 | 主从模式 | 哨兵模式 | Cluster 模式 |
|---|---|---|---|
| 高可用能力 | ❌ 手动切换 | ✅ 自动故障转移 | ✅ 自动故障转移 |
| 数据扩展 | 读扩展（从节点） | 读扩展（从节点） | ✅ 读写水平扩展 |
| 数据分片 | ❌ 无 | ❌ 无 | ✅ 16384 哈希槽 |
| 一致性保证 | 最终一致性 | 最终一致性 | 最终一致性（异步复制） |
| 运维复杂度 | 低 | 中 | 高 |
| 典型场景 | 读写分离、数据备份 | 生产环境高可用 | 大规模数据存储 |
💡 面试策略：回答“Redis 高可用方案”类问题时，先用自己的话概括三种模式的演进逻辑（主从→哨兵→Cluster），再分别点出1个核心优势 + 1个关键限制，最后落到业务场景选型上，体现架构思维。
📌 面试问题 1：请对比 Redis 主从复制、哨兵和 Cluster 三种高可用方案的特点与适用场景。
🎯 面试官考察点：
- 是否理解三种方案的核心差异（复制 vs 监控 vs 分片）
- 能否根据业务场景做出合理的架构选型
- 对分布式系统CAP 理论的实践认知
🧩 回答框架：
- 分层概述：按演进顺序介绍三种模式，点明各自定位
- 核心差异：高可用方式（手动/自动/去中心化）
- 数据扩展能力：读扩展 vs 读写扩展
- 场景推荐：小规模用哨兵，大规模用 Cluster
✏️ 简短示例回答：
“主从复制实现读写分离，但故障转移需手动干预，适合数据备份场景；哨兵模式在主从上加监控层，实现自动故障转移，满足生产环境高可用，但写能力仍受限于单节点；Cluster 通过哈希槽分片将写能力水平扩展，同时内置自动转移，适合 TB 级数据场景。选型上，日均 QPS 低于 10 万优先哨兵，超过 10 万且需水平扩展则上 Cluster。”
🔍 可能追问：主从复制存在数据延迟，如何保证读写一致性？
⚠️ 避坑提醒：不要只背概念，要结合 CAP 解释“为什么 Cluster 无法保证强一致性”——因为异步复制在节点故障时可能丢数据。面试官很在意你是否清楚每种方案的局限性。
📌 面试问题 2：Redis 哨兵模式如何实现自动故障转移？选举过程是怎样的？
🎯 面试官考察点：
- 是否理解哨兵的监控、通知、自动转移三大职责
- 对 Raft 类选举算法在 Redis 中的具体实现是否清楚
- 能否识别脑裂场景并说明解决方案
🧩 回答框架：
- 哨兵角色：监控主从节点状态，通过
PING检测下线 - 主观下线 → 客观下线：多个哨兵协商确认
- Leader 选举：哨兵间用 Raft 选出一个执行故障转移的 Leader
- 转移流程：选新主 → 修改配置 → 通知客户端
✏️ 简短示例回答：
“哨兵通过 PING 检测主节点超时后标记主观下线，当≥quorum 个哨兵均判定下线则转为客观下线。随后哨兵间发起 Raft 选举，选出 Leader 执行故障转移：从从节点中选一个 replica 优先级最高、复制偏移量最大的提升为新主，更新所有节点配置，并通过 pub/sub 通知客户端切换连接。”
🔍 可能追问：哨兵模式下如何避免脑裂？
⚠️ 避坑提醒：不要遗漏“客观下线需要 quorum 确认”这个关键细节。同时要主动提到脑裂问题——当主节点网络分区但未真正下线时，可能同时存在两个主节点写数据，最终导致数据丢失。解决方案是启用
min-replicas-to-write 和 min-replicas-max-lag 参数。
📌 面试问题 3：Redis Cluster 如何实现数据分片？节点扩缩容的过程是怎样的？
🎯 面试官考察点：
- 是否理解 16384 哈希槽的数据分布机制
- 对 Cluster 无中心化架构和 Gossip 协议的掌握程度
- 能否描述扩缩容时的数据迁移过程及对业务的影响
🧩 回答框架：
- 分片原理：对 key 用 CRC16 计算哈希值，对 16384 取模确定槽位
- 节点职责：每个节点负责一段哈希槽范围，支持主从冗余
- 扩缩容流程：调整槽位分配 → 迁移数据（
MIGRATE）→ 更新路由表 - 客户端感知：重定向机制（MOVED / ASK）
✏️ 简短示例回答：
“Cluster 将数据划分为 16384 个哈希槽，每个节点负责一部分槽位。扩容时，将部分槽位从现有节点迁移到新节点，使用
redis-cli --cluster reshard 触发迁移，底层通过 MIGRATE 命令批量移动 key。客户端遇到 MOVED 重定向会更新本地路由表，ASK 重定向则临时访问目标节点。”
🔍 可能追问：迁移过程中如果 key 很大（大 Value）会有什么问题？如何优化？
⚠️ 避坑提醒：不要忽略迁移对业务的影响——迁移过程中部分 key 会短暂不可用，建议在低峰期进行。同时要提到大 Key 问题：单个 key 过大导致迁移阻塞，应提前拆分或使用
UNLINK 异步删除。面试官很看重你对生产实践细节的认知。
🏭 项目案例：电商平台 Redis Cluster 改造实践
| 项目名称 | 电商主站 Redis 哨兵模式升级 Cluster 集群 |
| 业务背景 | 日活 1500 万电商平台，原有哨兵模式（1主3从）因双11大促流量暴涨，主节点写成为瓶颈，CPU 持续 90%+，急需水平扩展写能力 |
| 规模指标 | 日均请求量 8 亿+，缓存数据量 1.2TB，QPS 峰值 28 万，节点数 12 个（6主6从） |
| 技术栈 | Redis 6.2 Cluster / redis-cli / Prometheus + Grafana / 自研 Proxy 层 |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 | “在做 Cluster 改造时，我们采用双写 + 校验策略保证数据一致性：旧集群与新集群同时写入，离线脚本校验差异并补录。对于大 Key 问题，我们按业务前缀拆分到多个 Hash 槽，并在 Proxy 层做聚合查询。这次改造让写能力提升了 4 倍，单节点故障恢复时间从哨兵的 30 秒降低到 Cluster 的 8 秒。” |
🔥 加分话术：“Cluster 模式下我们关闭了
cluster-require-full-coverage 避免部分槽不可用时整个集群拒绝服务，同时开启了 replica-validate-master 防止从节点切换时读到过期数据。” —— 这句话能体现你对 Cluster 生产配置的深度理解。