Redis~主从复制的原理(复制的建立、复制的断开、切换复制点、全量复制、增量复制、故障处理、复制优化)

slaveof 127.0.0.1 6379

在这里插入图片描述

  • 现在主节点(左侧)新建一个字符串键值对,然后从服务(右侧)也可以查看到该键值对

在这里插入图片描述

  • 主从节点复制成功建立后,可以使用info replication命令查看复制相关状态

在这里插入图片描述

复制的断开 (slaveof no one)


  • slaveof命令不但可以建立复制,还可以在从节点执行slaveof no one来断开与主节点复制关系

  • 断开复制主要流程:

**①断开与主节点复制关系

②从节点晋升为主节点**

  • 从节点断开复制后并不会抛弃原有数据,只是无法再获取主节点上的数据变化

切换复制点


  • 通过slaveof命令还可以实现切主操作,所谓切主是指把当前从节点对主节点的复制切换到另一个主节点

  • 在一个已经建立复制的从节点上执行slaveof {newMasterIp} {newMasterPort}命令即可

  • 切主操作流程如下:

**断开与旧主节点复制关系

与新主节点建立复制关系

删除从节点当前所有数据

对新主节点进行复制操作**

  • 切主后从节点会清空之前所有的数据,线上人工操作时小心slaveof在错误的节点上执行或者指向错误的主节点

复制拓扑


  • Redis的复制拓扑结构可以支持单层或多层复制关系,根据拓扑复杂性可以分为以下三种:一主一从、一主多从、树状主从结构

  • 一主一从结构是最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移和数据恢复支持

  • 一主多从结构(又称为星形拓扑结构)使得应用端可以利用多个从节点实现读写分离

  • 树状主从结构(又称为树状拓扑结构)使得从节点不但可以复制主节点数据,同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层,可以有效降低主节点负载和需要传送给从节点的数据量

在这里插入图片描述

  • 当主节点需要挂载多个从节点时为了避免对主节点的性能干扰,可以采用树状主从结构降低主节点压力

复制原理


  1. 当一个redis节点给另一个redis节点发送 slaveof 命令后从节点只保存主节点的地址信息便直接返回,这时建立复制流程还没有开始

  2. 从节点内部通过每秒运行的定时任务维护复制相关逻辑, 会发现存在新的主节点后,会尝试与该节点建立网络连接

  3. 连接建立成功后从节点发送ping请求进行首次通信, 从节点发送的ping命令成功返回,继续后续复制流程

  4. 如果主节点设置了requirepass参数,则需要密码验证,从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证

  5. 随后从节点就会发送一个 psync同步命令

  6. master接收到命令后, 就会启动一个后台线程, 收集自己此时的所有数据命令, master将传送整个数据集文件到slave 完成一次完全同步, 也叫全量复制

  7. 在后续如果master收到修改数据的命令, 就会给从节点也发送一份, 将从节点的数据也进行更改

  • 总之整个过程全是从节点主动进行的, 包括一开始的保存主节点信息, 尝试建立socket连接, 尝试登陆验证, 发送同步密码, 数据一致化

全量复制

  • 全量复制是Redis最早支持的复制方式,也是主从第一次建立复制时必须经历的阶段

  • 触发全量复制的命令是sync和psync,它们的对应版本如下图所示

在这里插入图片描述

部分复制

  • 部分复制就是当主从节点网络中断后,从节点再次连上主节点时会发送psync {offset} {runId}命令请求部分复制, 也就是发送过去一个偏移量吗告诉主节点我上次复制在哪了

增量复制

-增量辅助就是在建立连接进行了完全复制之后, 主节点进行修改命令时候, 就会通过socket将这个命令传输给从节点, 进行数据的一致化

心跳检测

  • 主从节点在建立复制后,它们之间维护着长连接并彼此发送心跳命令。如下图所示:

在这里插入图片描述

  • 主从节点彼此都有心跳检测机制,各自模拟成对方的客户端进行通信

  • 主节点默认每隔10秒对从节点发送ping命令,判断从节点的存活性和连接状态。

  • 节点在主线程中每隔1秒发送replconf ack {offset}命令,给主节点上报自身当前的复制偏移量

故障处理


读写分离

  • 对于读占比较高的场景,可以通过把一部分读流量分摊到从节点来减轻主节点压力,同时需要注意永远只对主节点执行写操作

在这里插入图片描述

  • 当使用从节点响应读请求时,业务端可能会遇到如下问题:

**复制数据延迟

读到过期数据

从节点故障**

数据延迟
  • Redis复制数据的延迟由于异步复制特性是无法避免的,延迟取决于网络带宽和命令阻塞情况,比如刚在主节点写入数据后立刻在从节点上读取可能获取不到。需要业务场景允许短时间内的数据延迟

  • 对于无法容忍大量延迟场景,可以编写外部监控程序监听主从节点的复制偏移量,当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点

  • 当延迟字节量过高时,比如超过10MB。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知

  • 客户端接到具体的从节点高延迟通知后,修改读命令路由到其他从节点或主节点上。当延迟恢复后,再次通知客户端,恢复从节点的读命令请求

  • 这种方案的成本比较高,需要单独修改适配Redis的客户端类库。如果涉及多种语言成本将会扩大。客户端逻辑需要识别出读写请求并自动路由, 还需要维护故障和恢复的通知。采用此方案视具体的业务而定,如果允许不 一致性或对延迟不敏感的业务可以忽略,也可以采用Redis集群方案做水平扩展降低数据的复制量

读到过期数据
  • 当主节点存储大量设置超时的数据时,如缓存数据,Redis内部需要维护过期数据删除策略。删除策略主要有两种:惰性删除和定时删除

  • 惰性删除:主节点每次处理读取命令时,都会检查键是否超时,如果超时则执行del命令删除键对象,之后del命令也会异步发送给从节点。需要注意的是为了保证复制的一致性,从节点自身永远不会主动删除超时数据

  • 定时删除:Redis主节点在内部定时任务会循环采样一定数量的键,当发现采样的键过期时执行del命令,之后再同步给从节点

  • 如果此时数据大量超时,主节点采样速度跟不上过期速度且主节点没有读取过期键的操作,那么从节点将无法收到del命令。这时在从节点上可以读取到已经超时的数据。Redis在3.2版本解决了这个问题,从节点读在复制主节点数据的时候设置的时间也会复制, 所以在从节点取数据之前会检查键的过期时间来决定是否返回数据

从节点或者主节点故障
  • 在主从模式下, 从节点或者主节点故障只能开发或者运维人员手动配置, 不然不会自动配置完善, 但是在哨兵模式下就可以实现自动恢复

复制优化


规避全量复制

  • 全量复制是一个非常消耗资源的操作,前面做了具体说明。因此如何规避全量复制是需要重点关注的运维点
  1. 第一次建立复制

由于是第一次建立复制,从节点不包含任何主节点数据,因此必须进行全量复制才能完成数据同步。对于这种情况全量复制无法避免

当对数据量较大且流量较高的主节点添加从节点时,建议在低峰时进行操作,或者尽量规避使用大数据量的Redis节点

  1. 节点运行ID不匹配

当主从复制关系建立后,从节点会保存主节点的运行ID,如果此时主节点因故障重启,那么它的运行ID会改变,从节点发现主节点运行ID不匹配时,会认为自己复制的是一个新的主节点从而进行全量 复制

对于这种情况应该从架构上规避,比如提供故障转移功能。当主节点发生故障后,手动提升从节点为主节点或者采用支持自动故障转移的哨兵或集群方案。

  1. 复制积压缓冲区不足

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)

img

总结

虽然我个人也经常自嘲,十年之后要去成为外卖专员,但实际上依靠自身的努力,是能够减少三十五岁之后的焦虑的,毕竟好的架构师并不多。

架构师,是我们大部分技术人的职业目标,一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果,实践+机遇+努力才能助你成为优秀的架构师。

如果你也想成为一名好的架构师,那或许这份Java成长笔记你需要阅读阅读,希望能够对你的职业发展有所帮助。

image

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》点击传送门即可获取!
,是我们大部分技术人的职业目标,一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果,实践+机遇+努力才能助你成为优秀的架构师。

如果你也想成为一名好的架构师,那或许这份Java成长笔记你需要阅读阅读,希望能够对你的职业发展有所帮助。

[外链图片转存中…(img-KMRLuspt-1712057531682)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》点击传送门即可获取!

  • 4
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值