当前位置: 首页 > article >正文

Redis - 高可用实现方案解析:主从复制与哨兵监控

文章目录

  • Pre
  • 概述
  • Redis 高可用实现方案
  • 一、主从复制机制
    • 1.1 全量同步流程
    • 1.2 增量同步(PSYNC)流程
  • 二、哨兵监控机制
    • 2.1 故障转移时序流程
  • 三、方案对比与选型建议
  • 四、生产环境实践建议

在这里插入图片描述


Pre

Redis-入门到精通

Redis进阶系列

Redis进阶 - Redis主从工作原理详解

Redis-18Redis主从同步

Redis-19Redis哨兵Sentinel模式-Centos6.5上3台主机1主2从3哨兵的配置及通过代码访问哨兵


概述

为了提升对高并发实时数据访问的性能,数据缓存组件应运而生,其中比较常见的就是Memcache和Redis。

Memcache是经典的内存缓存技术,对相关领域的支持比较丰富,各种框架都支持使用该技术。应用系统中经常用到的会话信息可以非常方便地保存到Memcache中,每个键保存的数据量最大为1 MB,支持的数据类型比较单一,仅支持字符串类型(string),不支持持久化操作。

Redis支持比较多的数据类型(string、list、set、sortset、hash),也支持集合计算(set类型),每个键的最大数据量为1 GB,支持持久化操作。Redis一般配合后端数据库使用,其存放的一般是用户当前频繁使用的数据。

组件优点缺点
Memcache1. 支持客户端式分布式集群
2. 一致性哈希多核结构
3. 多线程读写性能高
4. 内存分配效率高
1. 不支持持久化
2. 仅支持字符串类型
3. 节点故障可能引发缓存穿透
4. 分布式需客户端实现
5. 单键最大1MB
6. 扩容复杂度高
Redis1. 支持5种数据类型(String/List/Set/ZSet/Hash)
2. 支持持久化(RDB/AOF)
3. 高可用架构(主从+哨兵)
4. 支持分布式分片集群
5. 单线程无锁高性能
6. 单键最大1GB
1. 多线程并发读写性能低于Memcache
2. 内存碎片问题需定期清理
3. 集群模式下部分命令受限(如跨节点事务)
4. 持久化可能影响瞬时性能

Redis 高可用实现方案

Redis 实现高可用主要依靠两大机制:主从复制哨兵监控


一、主从复制机制

Redis通过主从复制实现数据冗余与读写分离,支持全量同步增量同步两种模式。

1.1 全量同步流程

当从服务器首次连接主服务器或数据差异过大时触发全量同步:

从服务器 主服务器 SYNC命令 执行BGSAVE生成RDB 记录后续命令到缓冲区 发送RDB文件 加载RDB文件 发送缓冲区增量命令 执行增量命令 从服务器 主服务器

全量同步流程:

  1. 从服务器发送 SYNC 命令:从服务器请求与主服务器建立复制关系。
  2. 主服务器生成 RDB 快照:接收到 SYNC 命令后,主服务器调用 BGSAVE 命令生成 RDB 文件,同时启动缓冲区记录后续所有的增量命令。
  3. 传输 RDB 文件:主服务器将 RDB 快照发送给从服务器。
  4. 从服务器加载 RDB 文件:从服务器加载快照文件,完成数据初步同步。
  5. 增量命令同步:主服务器从缓冲区读取断线期间的命令,发送给从服务器,从服务器执行后续写入操作。

1.2 增量同步(PSYNC)流程

在理解增量同步之前需要了解下面几个概念

  • 复制偏移量:执行复制的主从服务器会以字节为单位维护一个复制的偏移量(offset)。
  • 复制缓冲区:一个先进先出(first in first out,FIFO)的队列,用于存储服务器执行过的命令,每次执行命令时主服务器都会将命令记录下来,并存储在复制缓冲区。命令存储的仅仅是数据变更的操作,复制缓冲区的大小是1 MB。
  • 服务器运行ID:每个Redis服务器会在启动时生成自己的服务器运行ID(runid),主服务器会将自己的运行ID发送给从服务器,从服务器将其保存起来,当主从服务器断线重连之后就可依据这一ID来判断当前主服务器是否是之前的主服务器,如果是,则启动增量同步,否则启动全量同步。

Redis 2.8+版本引入PSYNC命令优化断线重连场景:

从服务器 主服务器 PSYNC runid offset FULLRESYNC runid offset 发送RDB文件 CONTINUE 发送缺失的增量命令 FULLRESYNC runid offset 全量同步 alt [runid匹配且offset在缓冲区内- ] [数据差异过大] alt [初次复制] [断线重连] 从服务器 主服务器

核心逻辑

  • 通过runid验证主服务器身份
  • 通过offset判断数据差异是否超出缓冲区容量(默认1MB)
  • 增量同步仅传输丢失的命令,避免全量复制

PSYNC命令的执行流程。

  • (1)客户端向服务器发送SLAVEOF命令,让当前服务器成为从服务器。
  • (2)从服务器根据自己是否保存主服务器的运行ID来判断是否是第一次复制,如果是第一次复制,则继续执行第3步,否则跳转到第4步。
  • (3)从服务器向主服务器发送PSYNC ? -1命令进行全量同步。
  • (4)从服务器向主服务器发送PSYNC runid offset命令进行增量同步。
  • (5)主服务器接收到PSYNC 命令后,先判断runid是否与本机ID一致,如果一致,则会再次判断offset和本机的偏移量差距有没有超过复制缓冲区大小,如果没有,就给从服务器发送CONTINUE命令,此时从服务器只需要等待主服务器传回失去连接期间丢失的命令。
  • (6)如果runid和本机ID不一致或者双方偏移量差距超过复制缓冲区大小,就会发送FULLRESYNC runid offset命令,从服务器将runid保存起来,并进行全量同步。

二、哨兵监控机制

主从复制虽然实现了数据同步,但主服务器宕机后写操作将无法进行。为解决此问题,Redis 提供了哨兵(Sentinel)机制,主要功能包括:

  • 监控(Monitoring):持续检查主从服务器的运行状态。
  • 通知(Notification):在检测到故障时,通过 API 向管理员或其他应用程序发送通知。
  • 自动故障迁移(Automatic Failover):当主服务器失效时,从剩余从服务器中选举出一个新主服务器,并指示其他从服务器切换复制目标,同时向客户端返回新主服务器的地址。

2.1 故障转移时序流程

哨兵 主服务器 从服务器 客户端 其他从服务器 定期检查主服务器状态 持续监控 选举新主服务器 接受升级为新主 通知切换到新主 返回新主服务器地址 alt [主服务器正常] [主服务器故障] 哨兵 主服务器 从服务器 客户端 其他从服务器

核心功能

  1. 监控:多哨兵节点协同检测主服务器状态
  2. 选举:基于Raft算法选举领头哨兵
  3. 故障转移
    • 提升从服务器为新主节点
    • 修改其他从服务器复制目标
    • 更新客户端连接地址

三、方案对比与选型建议

方案适用场景限制条件
主从复制数据冷备份、读写分离主节点故障需手动切换
哨兵模式自动故障转移的高可用场景需要至少3个哨兵节点保障决策

推荐组合:主从复制+哨兵模式,兼顾数据冗余与自动容灾。


四、生产环境实践建议

  1. 网络优化:主从节点尽量部署在同机房
  2. 内存配置:主节点内存建议为最大数据量的1.5倍
  3. 监控指标
    • 主从复制延迟(master_repl_offset
    • 哨兵节点的ping响应时间
  4. 避免使用KEYS *等阻塞命令影响同步性能

通过合理配置主从复制与哨兵监控,可构建秒级故障恢复的高可用Redis集群。

在这里插入图片描述


http://www.kler.cn/a/572309.html

相关文章:

  • 第五十四:渲染数据 v-text 和 v-html
  • 基于PHP+MySQL小区进出登记系统设计与实现
  • Vue+Elementui 全局配置el-table表格列宽可拖拽
  • postman请求后端接受List集合对象
  • [数据结构]设计循环队列
  • FastGPT 引申:混合检索完整实例
  • 网络原理--HTTPS的加密过程简介
  • 57、深度学习-自学之路-自己搭建深度学习框架-18、RNN神经网络的简介
  • composer 错误汇总
  • 网络原理 初识[Java EE]
  • 20250301在chrome中安装CRX猫抓
  • HarmonyOS NEXT开发进阶(十一):应用层架构介绍
  • CES Asia 2025:聚焦前沿科技,探索未来无限可能
  • 运营商三要素API:构建安全信任的桥梁
  • 加油站小程序实战教程06地图多站点显示
  • 虚拟化园区网络部署指南
  • 算数操作符、赋值操作符、单目操作符、强制类型转换
  • 全球首创!微软发布医疗AI助手,终结手写病历时代
  • 清理pip和conda缓存
  • 华为OD最新机试真题-计算疫情扩散时间-C++-OD统一考试(E卷)