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

打印 上一主题 下一主题

主题 998|帖子 998|积分 2994



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. 单键最大1GB1. 多线程并发读写性能低于Memcache
2. 内存碎片题目需定期清理
3. 集群模式下部门命令受限(如跨节点事务)
4. 持久化可能影响瞬时性能
Redis 高可用实现方案

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

一、主从复制机制

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

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

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

1.2 增量同步(PSYNC)流程

在明白增量同步之前需要相识下面几个概念


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

  • 通过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 故障转移时序流程

       核心功能
  

  • 监控:多哨兵节点协同检测主服务器状态
  • 推举:基于Raft算法推举领头哨兵
  • 故障转移

    • 提拔从服务器为新主节点
    • 修改其他从服务器复制目标
    • 更新客户端连接地点

  
三、方案对比与选型建议

方案适用场景限制条件主从复制数据冷备份、读写分离主节点故障需手动切换哨兵模式自动故障转移的高可用场景需要至少3个哨兵节点保障决策 保举组合:主从复制+哨兵模式,兼顾数据冗余与自动容灾。

四、生产情况实践建议


  • 网络优化:主从节点尽量摆设在同机房
  • 内存设置:主节点内存建议为最大数据量的1.5倍
  • 监控指标

    • 主从复制延迟(master_repl_offset)
    • 哨兵节点的ping相应时间

  • 避免利用KEYS *等壅闭命令影响同步性能
通过合理设置主从复制与哨兵监控,可构建秒级故障规复的高可用Redis集群。


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

石小疯

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表