redis主从复制和哨兵机制

2025年Java面试宝典下载地址（提取码：9b3g）建议保存到网盘，备战金三银四

Redis主从复制和哨兵机制核心原理剖析

作为后端开发必问的Redis考点，主从复制和哨兵机制经常让候选人"痛并快乐着"。今天我们就来拆解这两个核心机制，让你在面试中游刃有余。

主从复制实现原理

Redis主从复制是构建高可用架构的基石，理解数据同步机制是关键。主节点（master）通过三种方式同步数据给从节点（slave）：

1. 全量复制：初次连接时主节点生成RDB快照传输
2. 增量复制：基于环形缓冲区的复制积压缓冲区
3. 命令传播：主节点执行写命令后主动推送

需要注意复制偏移量（replication offset）这个重要指标，当主从节点偏移量差超过缓冲区大小时，会触发全量复制。这也是为什么需要合理配置repl-backlog-size参数。

主从架构的致命缺陷

虽然主从复制解决了数据备份问题，但系统仍然存在单点故障风险：

1. 主节点宕机需要人工干预切换
2. 写操作无法自动转移到其他节点
3. 故障发现依赖外部监控

这时候就需要哨兵机制（Sentinel）来补齐高可用短板。根据某大厂故障报告，未配置哨兵的Redis集群宕机恢复时间平均达到47分钟，而配置哨兵后这个时间缩短到30秒内。

哨兵集群运作机制

三个哨兵节点组成的集群是保证高可用的最小配置，这里需要重点掌握几个核心机制：

故障检测流程：

1. 主观下线（SDOWN）：单个哨兵判定节点不可用
2. 客观下线（ODOWN）：超过半数的哨兵确认节点失效

Leader选举： 采用Raft算法实现，需要获得多数票的哨兵成为故障转移操作执行者。这个过程需要特别注意网络分区情况下的脑裂问题。

故障转移步骤：

1. 筛选健康从节点（检查断开连接时间、复制偏移量）
2. 优先级排序（配置slave-priority）
3. 执行slaveof no one提升为新主节点
4. 通知其他从节点切换主节点

生产环境配置建议

根据阿里云Redis团队的最佳实践：

• 主从节点建议跨机房部署
• 哨兵节点数量配置为奇数（推荐3或5个）
• 合理设置down-after-milliseconds参数（通常30秒）
• 主从复制使用单独的网络链路
• 定期检查哨兵日志中的+sdown/-sdown事件

需要购买Redis相关服务的同学，可以通过面试鸭返利网联系我，购买会员可返利25元。更多分布式系统设计要点，可以参考我们整理的最新面试资料。