【Redis】 高可用三大核心:主从复制 + 哨兵 + 集群(面试终极版)
2026/6/4 10:55:21 网站建设 项目流程

大家好,我是程序员二叉。


简介

主从复制、哨兵、集群是 Redis 高可用架构的三驾马车,也是后端面试必考、必问、必深挖的核心知识点。本文从原理、流程、机制、面试题全方位拆解,内容包含主从全量/增量同步、复制积压缓冲区、哨兵故障转移、Cluster 哈希槽、扩缩容、16384 槽位根源、脑裂解决。欢迎点赞收藏关注。


一、Redis 主从复制原理

1. 核心作用

  • 主节点(Master):负责写请求
  • 从节点(Slave):负责读请求
  • 实现读写分离、数据备份、高可用基础

2. 主从复制流程

  1. 从节点发送slaveof指令建立连接
  2. 主从进行全量同步增量同步
  3. 主节点持续将写命令异步同步到从节点
  4. 从节点接收命令并执行,保持数据一致

二、全量同步 & 增量同步

1. 全量同步(RDB 快照)

触发场景:第一次同步、runId 不匹配、偏移量丢失
流程

  1. 主节点执行bgsave生成 RDB 文件
  2. 发送 RDB 给从节点
  3. 从节点清空数据,加载 RDB
  4. 主节点将期间缓存的增量写命令发送给从节点
    特点:数据完整,但性能开销大

2. 增量同步(命令重放)

触发场景:短时间断线、网络抖动恢复
流程

  1. 从节点发送主节点 runId + 偏移量 offset
  2. 主节点在复制积压缓冲区查找 offset
  3. 仅发送缺失的命令
  4. 从节点快速补齐数据
    特点:轻量、高效、无阻塞

三、复制积压缓冲区作用

1. 本质

主节点内存中的固定长度环形队列

2. 核心作用

  • 缓存主节点最近的写命令
  • 支持从节点断线后增量同步
  • 避免频繁全量同步,提升主从性能

3. 断线后增量同步原理

  1. 从节点断线重连,带上 offset
  2. 主节点判断 offset 是否在缓冲区中
  3. 存在 → 增量同步
  4. 不存在 → 全量同步

四、哨兵 Sentinel 核心原理

1. 哨兵作用

  • 实时监控主从节点状态
  • 自动故障发现 + 故障转移
  • 主节点宕机自动选举新主
  • 提供主节点地址查询服务

2. 核心工作流程

  1. 哨兵每秒向主从发送心跳
  2. 节点无响应 →主观下线
  3. 多个哨兵确认 →客观下线
  4. 哨兵间选举Leader
  5. Leader 执行故障转移

3. 故障转移完整流程

  1. 原主节点客观下线
  2. 哨兵集群选举 Leader
  3. 从从节点中筛选新主节点
  4. 执行slaveof no one升主
  5. 其他从节点指向新主
  6. 旧主恢复后变为从节点

五、哨兵选主规则 & 投票机制

1. 新主节点选举优先级

  1. slave-priority 优先级最高
  2. 复制偏移量最大(数据最新)
  3. runId 最小

2. 哨兵投票机制

  • 采用半数以上通过原则
  • 至少3 个哨兵才能保证高可用
  • 投票胜出者为 Leader,执行切换
  • 避免脑裂,保证决策唯一

六、Redis Cluster 集群原理

1. 核心设计

  • 去中心化架构
  • 数据按哈希槽分片存储
  • 支持水平扩容、高可用

2. 哈希槽(Hash Slot)

  • 总数:16384 个
  • 所有主节点均匀分配槽位
  • 键路由公式:
    slot=CRC16(key)mod 16384 slot = CRC16(key) \mod 16384slot=CRC16(key)mod16384
  • 一个槽只属于一个主节点

七、集群槽位分配 & 分片规则

  • 集群将 16384 个槽均匀分配给所有主节点
  • 每个主节点负责一段连续槽位
  • 客户端可连接任意节点
  • 节点根据槽位返回重定向或直接响应

八、集群扩容 & 缩容原理

1. 扩容

  1. 加入新主节点
  2. 从旧节点迁移部分槽位到新节点
  3. 迁移槽位对应的 key
  4. 集群重新平衡,在线无感扩容

2. 缩容

  1. 将下线节点的槽位全部迁移走
  2. 节点下线
  3. 集群自动更新槽位路由表

九、为什么哈希槽是 16384?(面试必问)

官方核心原因

  1. 心跳包大小限制
    槽位图用 bitmap 存储,16384 刚好占用2KB
  2. Redis 集群节点不建议超过 1000 个
    16384 足够分配且槽均匀
  3. 带宽 + 内存效率最优
    槽位过大会导致心跳包过大、耗流量、耗内存

一句话总结

16384 是节点规模、网络开销、性能效率三者的最佳平衡。


十、集群高可用 & 脑裂问题解决

1. 高可用机制

  • 一主多从,主从自动切换
  • 集群内置哨兵能力
  • 槽位完整则集群可用

2. 脑裂问题 & 解决方案

脑裂场景:主节点网络隔离,哨兵切换新主,旧主仍在线,出现双主
解决方案
配置min-replicas-to-write 1
原理
主节点检测到从节点连接数不足时,拒绝写入,避免双主同时写数据。


十一、面试终极总结

  1. 主从:全量同步(RDB)、增量同步(offset+复制积压缓冲区)
  2. 复制缓冲区:环形队列,缓存命令,支撑增量同步
  3. 哨兵:监控、选主、故障转移,投票半数机制保证高可用
  4. 集群:16384 哈希槽分片,去中心化,在线扩缩容
  5. 16384:心跳包大小 + 集群规模 + 性能最优
  6. 脑裂:配置最小从节点数,禁止主节点孤立写入

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询