Redis主从复制知识---看完一篇就够了

最新推荐文章于 2023-05-01 16:22:41 发布

佳佳不掉头发

最新推荐文章于 2023-05-01 16:22:41 发布

阅读量1k

点赞数 3

分类专栏：我的总结文章标签：后端学习 redis

本文链接：https://blog.csdn.net/qq_51959224/article/details/124358957

版权

我的总结专栏收录该内容

24 篇文章 1 订阅

订阅专栏

说明:本文全本人手写,对于学习做的笔记,本来之前也是不理解主从复制,但是学习过之后对主从复制的理解更深了一步,如果你仔细的学习并且做了笔记,而且有自己的想法的话,那么你一定能够理解Redis主从复制的原理,写于2022/04/23-lsj,如果哪里写错了请指出

Redis主从复制

重点掌握:
- 介绍复制的使用方式: 如何建立或者断开复制、安全性、只读等。
- 说明复制可支持的拓扑结构:,以及每个拓扑结构的是适用场景。
- 分析复制的原理: 建立复制、全量复制、部分复制、心跳。
- 介绍复制过程中常见的开发和运维问题: 读写分离、数据不一致、规避全量复制等。

6.1配置

#例如如果要用6380作为端口启动redis,那么可以执行
redis-server --port 6380
#随后连接即可
redis-cli -h 127.0.0.1 -h 6380
#用于复制操作样例

6.1.1 建立复制

参与复制的Redis实例划分为**主节点(master),从节点(slave)。默认情况下,redis都是主节点。**每一个主节点就可以有多个从节点,每个从节点只能有一个主节点。复制是单向的只能从主节点到子节点。

配置复制的方式有三种:
1. 在配置文件中加入 slaveof {masterhost} {masterPort} 随Redis启动生效
2. 在Rredis-server 启动命令后加入**–slaveof {masterHost} {masterPort}**
3. 直接使用命令slaveof {masterHost} {masterPort}
slaveof本身是异步命令,执行slaveof命令的时候,从节点只保存主节点信息返回,后续复制流程在从节点内是异步执行(6.3节),主从结点复制成功建立之后可以通过info replication命令查看复制相关的状态
- 未复制的状态参数如下
  - $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eCwus35P-1650674588281)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421152251316.png)]$
- 复制过后的状态参数如下
  - $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TgdxBZO9-1650674588283)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421152434127.png)]$

6.1.2 断开复制,切主操作

命令:slaveof no one

可以在6380端口的从节点执行这个命令从而断开复制

**slaveof no one**断开复制的主要流程
1. 断开与主节点的复制关系
2. 从节点会晋升成主节点
注意点:
- 从节点断开后不会抛弃原来的数据,只是无法在获取主节点上的数据
切主操作,命令:slave {newMasterIP} {newMasterPort},就是把当前从节点对主节点的复制切换到另一个主节点,这样会导致从节点数据全部删除
1. 断开与旧主节点的复制关系
2. 与新主节点建立复制关系
3. 删除从节点的所有数据
4. 对新的主节点进行复制操作

6.1.3 安全性

对于重要的结点,主节点设置**requirepas参数验证密码.这时候所有客户端访问都要使用auth命令实行校验,从节点和主节点的复制连接是通过一个特殊表示的客户端来完成,因此配置从节点的masterauth**参数应该与主节点的密码保持一致,

主节点的配置文件密码在396行

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xWmBbr1N-1650674588284)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421160111943.png)]$

从节点的配置文件密码在217行,直接修改即可

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ri8ROu74-1650674588284)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421155605121.png)]$
或者启动**redis-server --port 6300 --slaveof 127.0.0.1 6379 --masterauth Lishoujia3301 **
- 随后连接即可**redis-cli -h 127.0.0.1 -p 6380**

6.1.4 只读

默认的条件下,从节点使用**slave-read-only=yes**配置为只读模式, 由于复制只能从主节点到从节点,对于从节点的任何修改主节点都无法感知,修改从节点会造成主从数据不一致,因此建议线上不要修改从节点的只读模式,就保持默认就行

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SbE51tbv-1650674588285)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421154025330.png)]$

这个就是只能读,不能写

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iimWTvfe-1650674588286)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421154334943.png)]$

6.1.5 传输延迟

主节点一般都部署在不同的机器上,复制的时候网络延迟就成为需要考虑的问题,Redis为我们提供了 repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY,默认是no,即开启tcp_nodelay功能

当关闭时,主节点产生的命令数据无论大小都会及时的发送给从节点,这样主从之间延迟变小,但增加了网络带宽,适用于主从之间的网络环境良好的场景,如同机房部署,或者同机部署。
当开启的时候,主节点会合并较小的TCP数据包进行节省带宽,默认发送时间取决于Linux内核,一般默认40ms,适用于带宽紧张的场景,如跨机房部署。
部署主从结点要考虑网络延迟,带宽使用率,防灾级别等因素,要求低延迟的时候关闭**repl-disable-tcp-nodelay,如果考虑高容灾性,可跨机房部署,开启repl-disable-tcp-nodelay**

6.2 拓扑

Redis的拓扑可以支持单层或多层的复制关系,拓扑的复杂性分为三种:

一主一从
- 一主一从是最简单的拓扑结构,用于主节点出现宕机时从节点提供故障转移支持
- 注意: 当应用写命令并发量较高且需要持久化的时候,可以只在从节点上开启AOF,这样既能保证数据的安全性同时也避免了持久化**(重写aof)**对主节点性能的干扰
- 注意: 当主节点没有持久化的时候尽量避免重启,因为重启的时候主节点因为没有持久化会清空数据,这时候从节点复制也是清空数据
一主多从
- 一主多从使得应用端可以利用多个从节点实现读写分离,对于读占比较大的场景,可以把读命令发送到从节点来分担主节点压力,同时在日常中一些费时的命令如:keys、sort可以在其中一台执行,防止慢查询对主节点造成堵塞
- 注意: 对于写并发量高的场景,多个从节点会导致主节点写命令的多次发送而过度消耗网络带宽,加重了主节点的负载
树状多从
- 树状主从结构可以降低主节点负载和需要传送给从节点的数据量,可以采用这个降低主节点的压力

6.3 原理

6.3.1 复制原理

在从节点执行slaveof命令后就开始执行复制操作

1)保存主节点信息
- 执行slaveof命令之后保存主节点信息并且返回,这时候建立复制流程还未开始
2)主从建立socket连接
- 从节点每秒有定时任务维护复制逻辑,当发现有一个新的主节点之后,会尝试与该结点建立连接
- 从节点建立socket套接字,专门用来接收主节点发送的复制命令
- 若连接失败,定时任务会无线重试,知道连接成功或者执行slaveof no one 取消复制
3)发送ping命令
- socket建立成功之后从节点会发送ping进行首次通信,ping的目的如下:
  - 检查主从之间的套接字是否可用
  - 检测主节点当前是否可接受处理命令
- 若发送ping之后pong超时或者没有收到,比如网络超时或者堵塞,这时候从节点就会断开连接,下次定时会发起重试,都是一秒
4)权限认证
- 如果主节点设置了requirepass 密码,那么从节点连接的时候要写masterauth参数,密码要和主节点一致
- 可以这样启动**redis-server --port 6380 slaveof 127.0.0.1 6379 masterauth Lishoujia3301**
5)同步数据集
- 主从复制在连接到正常通信的时候,对于首次建立复制,主节点会把所有数据都发给我从节点,Redis2.8之后有新复制命令psync进行数据同步(pysnc {运行ID}{当前从节点复制偏移量}),原来的sync也能用,新版本的同步数据分为两种情况: 全量复制和部分复制(6.3.2)(6.3.3)(6.3.4)
6)命令持续复制
- 当主节点把当前的数据同步之后,便完成了复制的建立,接下来主节点会持续的把写命令发送给从节点,保持主从数据一致

6.3.2 数据同步(psync命令)

Redis2.8之后新的数据同步命令psync,分为两种情况: 全量复制,部分复制

全量复制
部分复制
psync命令运行需要以下组件支持
- 主从节点各自的偏移量
- 主节点复制积压缓冲区
- 主节点运行id

复制偏移量
- 参与复制的主从节点都会维护自身的偏移量,从节点会将偏移量转给主节点保存起来,主节点(master)在处理完写命令后,会将命令的字长累加做记录,统计在info replication中的master_repl_offset指标中
- 从节点在接收到主节点发送的命令后,也会累加自身的偏移量,统计在info_replication中的slave_repl_offset指标中
- 从节点(slave)每秒钟都会上报自身的偏移量给主节点,因此主节点也会保存从节点的复制偏移量
- 因此可以通过对比主从结点的复制偏移量,可以判断主从是否一致
可以通过判断复制偏移量的差值来判断当前复制的健康度,如果差值过大的话就可能是网络延迟或者命令阻塞
复制积压缓冲区
- 复制积压缓冲区是保存在主节点上的一个队列,默认大小是1MB,当主节点有连接的从节点时就被创建,这时主节点响应写命令,不但会把命令发送给从节点,还会写入积压缓冲区
- 缓冲区能保存最近已经复制的功能,用于部分复制和复制命令丢失的数据补救,复制积压缓冲区的相关统计信息保存在主节点的 info replication中
  - 指标里面的复制积压缓冲区内的可用偏移量范围[repl_backlog_first_byte_offset,repl_backlog_first_byte_offset+repl_backlog_histlen]
主节点运行ID
- 每个Redis节点启动之后都会动态分布一个40位16进制的字符串作为运行id
- 作用: 用来唯一识别Redis节点
- 从节点保存的主节点运行id识别自己正在复制的是哪一个主节点,如果主节点重启更换了整体数据集,从节点在基于偏移量复制数据将是不安全的,因此运行ID变化之后从节点做全量复制,可以运行**info server**命令查看当前节点的运行id
- 每次redis重启,运行id都会改变,如何在不改变运行id的情况下重启呢?当
psync命令
- 从节点使用pysnc命令完成全量复制和部分复制功能,pysnc{runid} {offset}
  - runid:主节点运行id,如果主节点重启之后id改变,那么久进行全量复制
  - offset:当前从节点已经复制的数据偏移量
- psync功能流程:
  - 1)从节点(slave)发送psync命令给主节点,参数runid是当前从节点保存的主节点运行ID,如果没有则默认值是?,参数offset是当前从节点已复制的数据偏移量,如果没有默认是-1;
  - 2)主节点根据从节点发来的psync命令的参数和自身数据情况响应结果:
    - 回复+FULLRESYNC{runid} {offset},那么从节点进行全量复制
    - 回复+CONTINUE,从节点将触发部分复制流程
    - 回复+ERR,则是无法识别psync命令,redis版本低于2.8,从节点发送旧版本的sync命令进行全量复制
    - redis从节点有主节点的runind和offset,这时主节点重启runid改变,从节点进行全量复制,那么发送psync的时候,主节点反馈什么?是+FULLRESYNC吗? 这个问题如下:
      - $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BGmE6KEI-1650674588286)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421212623047.png)]$
      - 当从节点的runid和当前主节点的runid不一致的时候进行全量复制

6.3.3 全量复制

全量复制是Redis最早支持的复制方式,也是第一次进行主从复制的方式,不同版本的命令不同

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3IEkwzDT-1650674588287)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421214134391.png)]$

触发全量复制的条件
1. 主从结点第一次建立复制的时候
2. 从节点发送pysnc命令的时候,从节点保存有之前主节点的{runid} {offset}(全量复制可以忽略这个offset),如果之前的主节点进行重启之后runid发生变化,从节点的runid和主节点的runid不一致,那么就会触发全量复制
全量复制的流程说明
- $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iPbpUmva-1650674588287)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421215441324.png)]$

如图
如图
如图
主节点执行bgsave保存RDB到本地
发送RDB要注意对于数据量较大的主节点,生成的RDB文件超过6GB以上要小心,可以通过分析日志Full resync和MASTER<->SLAVE的时间差算出RDB从创建到传输完毕所消耗的时间,如果总的时间超过 repl-timeout所配置的值(默认是60s),从节点会报错
意思是从节点在接收主节点发送的RDB过程中,主节点仍然在执行写操作,那么写操作会保存在复制客户端缓冲区之内,从节点加载完之后主节点把缓冲区内的数据发送给从节点,保持主从数据一致性.这时候要注意:如果RDB接收的时间过长,那么对于高流量的写入操作会将复制客户端缓冲区写满甚至溢出。默认配置是client-output-bufferlimit slave 256MB 64MB 60,如果60秒内缓冲区消耗持续大于64mb或者直接超过256mb那么会直接关闭客户端连接,造成全量复制的失败
如图
如图
如图

全量复制的耗时开销如下:
- 主节点的bgsave操作
- RDB传输时间
- 从节点清空数据时间
- 从节点加载RDB时间
- 如果设置了AOF还要重写AOF的时间

6.3.4 部分复制

部分复制主要是对全量复制过高开销的一种优化措施,使用命令pysnc{runid}{offset}实现。

当从节点进行复制主节点的时候,如果出现网络闪断或者命令丢失等异常情况的时候,从节点会向主节点要求补发丢失的命令,主节点会将复制积压缓存区的数据发给从节点,不发的数据很小,开销很小

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xYLaORyS-1650674588288)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421222551415.png)]$

当主从结点之间的网络断开连接的时候,如果超过repl-timeout时间,主节点会认为从节点故障进而中断复制连接
主从连接中断的这一阵子,主节点仍在响应命令,命令会写入复制积压缓冲区内,默认最大为1MB
从节点再次连接上主节点
从节点发送pysnc{runid}{offset}命令,要求进行部分复制,因为之前从节点保存有主节点的runid和offset
主节点收到pysnc命令后首先检查runid是否一致,如果不一样则进行全量复制的操作,如果一样的话,再根据offset在自身复制积压缓冲区查找,如果偏移量之后的数据在缓冲区中,主节点则发送+CONTIUNE命令给从节点,表示可以进行部分复制
主节点根据偏移量把复制积压缓冲区的数据发送给从节点,保证主从复制正常

6.3.5 心跳

主从结点建立复制之后,他们之间维护者场链接并彼此发送心跳

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GEFBeVic-1650674588288)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220421223547294.png)]$

主从结点彼此都有心跳监测机制,各自模拟成对方的客户端进行通信,通过client list命令查看相关信息,
- 主节点连接状态是: flags=M
- 从节点连接状态是: flags=S
主节点默认十秒对从节点发送ping命令,判断从节点的存活性和连接状态,可以ton过参数**repl-ping-slave-period**控制发送频率\
从节点在主线程中默认一秒发送一次 replconf ack{offset} 命令,给主节点上报自身当前的复制偏移量
- replconf命令作用如下
  - 实时检测主从结点网络的状态
  - 上报自身的偏移量

6.3.6 异步复制

主节点不但负责数据读写,还负责把写命令同步给从节点。写命令发送过程是异步完成,主节点自身处理完写命令后直接返回给客户端,并不等待从节点复制完成

由于主从复制过程是异步的,就会造成从节点的数据想对主节点存在延迟,具体延迟多少字节,我们可以在主节点执行info replication 命令查看相关指标
- $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IfY0GrW3-1650674588289)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220422085622554.png)]$
  - slave0代表从节点的信息,记录了从节点的ip,port,从节点的状态,offset代表当前从节点的复制偏移量,master_repl_offset代表当前主节点的复制偏移量,两者的差值就是当前从节点的复制延迟量
Redis的复制速度取决于主从之间的网络环境,repl_disable_tcp_nodely(6.1.5中讲解,默认是no),命令处理速度等

6.4 开发与运维中的问题

理解完主从复制原理之后,这一届主要分析复制的应用场景,通过复制数据集可以存在多个副本当中,这些副本可以用来读写分离,故障转移,实时备份,但也有一些坑需要跳过

6.4.1 读写分离

对于读占比比较高的场景,或者对于慢查询比较多的场景,可以把一部分读流量放在从节点之上来减轻主节点的压力,同时注意永远只对主节点执行写操作,(6.1.4,默认只读,**slave-read-only=yes**不要随便改),但是实际业务端可能遇到以下几个问题

复制数据延迟
- Redis的复制是异步的无法避免,延迟取决于网络带宽和命令堵塞等问题,可能刚在主节点写入命令但是在从节点读取不到命令,需要从节点短时间的延迟。
- 但是对于大量延迟场景,可以编写外部监控程序来监听主从结点的客户端避免读取延迟过高的从节点
- $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dt7EatGB-1650674588289)(C:\Users\admin_lsj\AppData\Roaming\Typora\typora-user-images\image-20220422090837078.png)]$
  1. 监控程序会定期检查主从结点的复制偏移量(6.3.6的info replication那个图的两个值),差值就是主从结点延迟的字节量
  2. 当延迟字节量过高的时候,比如说超过10MB,监控程序就会出发报警通知客户端从节点延迟过高。可以采用Zookeeper的监听机制实现客户端通知
  3. 客户端收到从节点延迟过高的通知之后,修改读命令路径到主节点或者其他从节点身上,当延迟恢复之后,再次通知客户端恢复从节点的读命令
- 这个方法的成本较高,需要配置很多,可以采用Redis集群方案做水平扩展
读到过期数据
- 主节点设置大量的超时数据,比如说缓存数据,Redis内部要维护过期数据删除策略,删除策略主要有两种: 惰性删除和定时删除
  - 惰性删除:主节点每次处理读命令的时候都会检查键是否超时,如果超时就会执行del删除对象,并且把del命令异步传给从节点,从节点永远不会自身删除超时数据,只能通过主节点的del来删除
  - 定时删除:Redis主节点在内部定时任务会循环采样一定数量的键,发现采样的键过期的时候执行del命令,之后在同步给从节点
    - 如果这时候数据大量超时,主节点采样速率跟不上过期速度,那么从节点接收不到del命令,Redis3.2解决了这个问题,redis在读取数据之前会检查键的过期时间来决定是否返回数据
  - 惰性删除和定时删除的区别:惰性删除是主节点处理读命令的时候会检查键是否过期,然后再执行删除的命令,而定时删除是内部循环采样进行删除,Redis3.2之后如果读到大量过期数据,从节点无法接收del命令,那么就会在读取数据之前检查这个数据是否过期,然后决定返不返回
从节点故障
- 从节点故障要立刻进行切主或者切从操作(6.1.2切主操作详细)
Redis读写分离存在一定的成本,应该尽量在主节点上做充分优化,如果优化不了的时候可以考虑扩展,在使用读写分离之前可以考虑使用Redis Cluster等分布式进行解决,这样不仅扩展了读性能,还扩展了写的性能。

6.4.2 主从配置不一致

主从配置不一致也是一个容易忽略的问题。对于有些配置主从之间是可以不一致的,比如AOF的开启和关闭,但对于内存相关的配置一定要一致,比如说:maxmemory **hash-max-ziplist-entries**等参数。

当配置的**maxmemory从节点小于主节点的时候,如果复制的数据量超过从节点的maxmemory,它会根据maxmemory-policy**策略进行内存溢出控制,此时从节点数据就会丢失,但主从复制仍在进行,复制偏移量也正常,只能手动修复全量复制
当压缩列表不一样的时候,虽然主从结点存储的数据一致,但是实际内存占用情况差异会比较大。

6.4.3 规避全量复制

全量复制很耗时,下面对几种全量复制的场景进行分析和避免:

第一次全量复制
- 第一次主从复制都是全量复制,这不可避免,所以我们要避免使用数据量大的主节点进行复制或者在低峰期的时候进行主从复制
结点运行ID不匹配
- 执行slaveof {主节点ip} {主节点port} 之后从节点会保存主节点的runid,offset等信息,如果注解戴安因为故障重启,那么这时候主节点的runid就会改变,从节点保存的runid是以前主节点的runid,两个runid不一致,这时候从节点就会进行全量复制,这种情况下就应该从架构上进行规避,比如说故障转移功能,手动提升从节点为主节点,或者使用自动故障转移的哨兵(Redis Sentinel)或集群(Redis Cluster)方案
复制积压缓冲区不足
- 当主从结点网络断开连接之后,从节点再次连接之后就会发送psync{runnid} {offset} 命令进行部分复制操作,如果请求的偏移量不在主节点的积压缓冲区之内,那么就会从部分复制退化成全量复制,这种中断一般是分钟级,复制积压缓冲区的默认大小是1MB,这时候用在高峰流量期断开的话肯定是不够用的,所以可以增大复制积压缓冲区的大小。

6.4.4规避复制风暴

复制风暴是指大量从节点对同一个主节点或者对同一台机器的多个主节点短时间内发起的全量复制过程,下面介绍规避的方式:

单主节点复制风暴(多个从节点对同一个主节点)
- 一般是一个主节点挂载多个从节点的场景。当主节点重启的手,从节点会发起全量复制过程(6.4.3的运行ID不匹配),主节点会创建RDB快照(6.3.3全量复制的第四步),多个从节点共享这个RDB**(Redis做了优化,就创建一个RDB文件,避免创建多个RDB多个bgsave操作浪费时间)**
- 解决方案: 用树状拓扑结构减少对主节点的挂载,网络开销交给中间层的从节点,不必消耗顶层的主节点,但是带来了运维的复杂性,增加了手动和自动处理故障转移的难度
单机器复制风暴(多个从节点对同一台机器的多个主节点)
- Redis是单线程架构,通常单个机器部署多个Redis实例,如果单台机器设置过多的主节点的时候,若机器出现故障断开连接重启恢复之后,大量从节点进行全量复制,可能会将带宽消耗殆尽
- 避免方法:
  - 把主节点分散到多台机器上,避免在单台机器上部署多个主节点
  - 当主节点所在的机器故障之后提供转移机制(Redis Sentinel,可以用哨兵进行自动化),避免机器回复后进行密集的全量复制