【Redis】主从复制（下）--主从复制原理和流程

主从复制原理

主从节点建立复制流程图

• 保存主节点的信息
• 从节点(slave)内部通过美妙运行的定时任务维护复制相关逻辑,当定时任务发现存在新的主节点之后,会尝试与主节点建立基于tcp的网络连接.如果从节点无法建立连接,定时任务会无限重试直到连接成功或者用户停止主从复制.
• 发送ping命令
  tcp网络连接建立成功之后,从节点通过ping命令确认主节点在应用层上是工作良好的.如果ping命令的结果pong返回超时,从节点结会断开tcp网络连接,等待定时任务下一次重新建立连接.
• 权限验证
• 同步数据集
  对于首次建立复制的场景,主节点会把当前持有的所有数据全部发送给从节点,这一步操作基本是耗时最长的,所以又划分成两种情况:全量同步和部分同步.
• 命令持续复制
  当从节点复制主节点的所有数据之后,针对之后的修改命令,主节点会持续的把命令发送给从节点,从节点执行修改命令,保证主从数据的一致性.

数据同步 psync

Redis使用psync命令完成主从数据同步(首次建立复制的场景中),同步过程为:全量复制和部分复制.

• 全量复制:一般用于初次复制的场景,Redis早期支持的复制功能只有全量复制,它会把主节点的数据一次性发送给从节点,当数据量较大的时候,会对主节点和网络造成很大的开销.
• 部分复制:用于处理在主从复制中因为网络闪断等原因造成的数据丢失的场景,当从节点再次连上主节点之后,如果条件允许,主节点会补发数据给从节点.因为补发的数据远小于全量数据,可以有效避免全量复制的过高开销.

psync的语法格式

psync replicationid offset
注意:

• replicationid设置为?并且offset设置为-1,此时就是在尝试进行全量复制
• replicationid和offset设置为具体值,此时就是在尝试进行部分复制

什么是replicationid和offset?

• replicationid/replid(复制id):主节点的复制id,主节点重新启动,或者从节点晋级成主节点,都会生成一个replicationid(同一个节点,每次重启,生成的replicationid也会发生变化,相当于一个主节点的唯一标识)
• offset(偏移量):参与复制的主从节点都会维护自身复制偏移量.主节点的offset中记录的是主节点操写命令的数据字节数;从节点offset中记录的则是从节点从主节点处同步到的数据字节数.所以,可以根据对比主从节点的复制偏移量,来判断主从节点数据是否一致

我们可以再回顾主节点的复制状态中的各种属性:

这里我们圈出几个重点属性:

• master_repl_offset:主节点(master)在处理完写入命令后,会把命令的字节长度做累加记录

• 记录从节点属性中的offset:该偏移量维护的是从节点从主节点那里同步了多少字节的数据,同时从节点也会每秒向主节点上报自身的复制偏移量给主节点

• master_replid:主节点的复制id,主节点重新启动,或者从节点晋级成主节点,都会生成一个replicationid(同一个节点,每次重启,生成的replicationid也会发生变化,相当于一个主节点的唯一标识)

• master_replid2:一般默认为0,只有在异常情况下用来记录原来的master的replid.

  关于master_replid和master_replid2

  这个设定解决的问题场景是这样的:
  比如当前有两个节点:A--master和B-slave
  此时B就会记录A的master_replid.
  如果此时出现了网络抖动,B以为A挂了,B自己就会成为主节点.于是B给自己分配了一个新的master_replid.此时就会使用master_replid2来保存之前A的master_replid

  • 后续如果网络恢复了,B就可以根据master_replid2找回之前的主节点;
  • 后续如果网络没有回复,B就按照新的master_replid自成一派,继续处理后续的数据.

所以,repid+offset共同标识了一个"数据集",如果两个节点,他们的replid和offset都相同,则这两个节点上持有的数据就一定相同

psync运行流程

• 从节点发送psync给主节点,replid和offset默认值分别是?和-1
• 主节点根据psync参数和自身数据情况确定响应结果:
  • 如果回复+fullresync replidoffset ,则从节点需要进行全量复制流程
  • 如果回复+contineu,从节点进行部分复制流程
  • 如果回复-err,说明Redis主节点版本过低,不支持psync命令.从节点可以使用sync命令进行全量复制
• psync一般不需要手动执行,Redis会在主从复制模式下自动调用执行
• sync会阻塞redis server处理其他请求,psync则不会

全量复制

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

全量复制的流程

• 从节点向主节点发送psync命令,进行数据同步,由于是第一次进行复制,所以将进行全量复制
• 主节点根据命令,解析到需要进行全量复制,回复+fullresync响应
• 从节点接收到主节点的运行信息,进行保存(如主节点的ip和port)
• 主节点执行bgsave进行RDB文件的持久化
• 从节点发送RDB文件给从节点,从节点保存RDB数据到本地硬盘
• 主节点将生成RDB到就收完成期间执行的写命令,放入缓冲区中,等从节点保存完RDB文件后,主节点再将缓冲区内的数据补发给从节点,不发的数据仍然按照rdb的二进制格式追加写入到收到的rdb文件中,保持主从一致性
• 从节点清空自身原有的数据
• 从节点加载RDB文件得到与主节点一致的数据
• 如果从节点加载RDB文件完成之后,并且开启了AOF持久化功能,它会进行bgrewrite操作,得到最近的AOF文件

全量复制的缺陷

我们分析了全量复制的所有流程,就会发现:全量复制是一件高成本的操作,主节点bgsave的时间,RDB在网络传输的时间,从节点清空旧数据的时间,从节点加载RDB的时间等.所以一般应该尽可能避免对已经有的大量数据集的Redis进行全量复制

有磁盘复制 vs 无磁盘复制

默认情况下,进行全量复制需要主节点生成RDB文件到主节点的磁盘中,再把磁盘上的RDB文件通过网络发送给从节点
Redis从2.8.18版本开始支持无磁盘复制.主节点在执行RDB生成流程时,不会生成RDB文件到磁盘中了,而是直接把生成的RDB数据通过网络发送给从节点.这样就节省了一系列的写磁盘和读磁盘的开销

部分复制

部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施,使用psync replicationid offset命令来实现.当从节点正在复制主节点时,如果出现网络闪断或者命令丢失等异常情况时,从节点会向主节点要求补发丢失的命令数据,如果主节点的复制积压缓冲区存在数据则直接发送给从节点,这样就可以保持主从节点复制的一致性.补发的这部分数据一般远远小于全量数据,所以减少了开销.

部分复制的流程

• 当主从节点之间出现网络中断时,如果超过了repl-timeout的时间,主节点就会认为从节点故障并中断复制连接

• 主从连接中断期间,主节点依然响应命令,但这些复制命令都因为网络中断而无法及时发送给从节点,所以要暂时将这些命令滞留在复制积压缓冲区中

• 当主从节点网络恢复之后,从节点再次连上主节点

• 从节点将之前保存的replicationid和复制偏移量作为psync的参数发送给主节点,请求部分复制

• 主节点接到psync请求后,进行必要的验证.随后根据offset去复制积压缓冲区查找合适的数据,并且响应+continue给从节点

  • 注意:如果replid不一样,那么就需要进行全量复制,如果replid一样,那么就需要判断offset是否还在复制积压缓冲区中,如果在,就直接进行部分复制;如果不再,就进行全量复制

• 主节点将需要从节点同步的数据发送给从节点,完成一致性

复制积压缓冲区

复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小是1MB,当主节点连接从节点的时候被创建,这时主节点响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区中,缓冲区本质上是一个先进先出的定长队列,所以能够实现保存最近已复制数据的功能,用于部分复制和复制命令丢失的数据补救.
我们可以在主节点中执行info replication来观察复制缓冲区的相关属性:

• repl_backlog_active:1:开启复制缓冲区
• repl_backlog_size:148576:缓冲区的最大长度
• repl_backlog_first_byte_offset:1:起始偏移量,计算当前缓冲区可用范围
• repl_backlog_histlen:956418:已保存数据的有效长度
  所以,根据上面的属性,我们可以计算出复制积压缓冲区内的可用偏移量范围:[repl_backlog_first_byte_offset,repl_backlog_first_byte_offset+repl_backlog_histlen]
  如果进行偏移量的比对后发现,从节点需要的数据,已经超出了主节点的积压缓冲区的范围,则无法进行部分复制,只能进行全量复制了.

实时复制

我们刚才学过的全量复制和部分复制,全都是在数据进行初始化的过程中进行的,而实时复制是发生在主从节点之间已经同步完成数据了,然后架构主节点后续获得的信息继续同步到从节点中
主从节点在建立复制连接之后,主节点会把自己收到的修改操作,通过tcp长连接的方式,源源不断的输给从节点.从节点就会根据这些请求来同时修改自身的数据,从而保证和主节点数据的一致性.

另外,这样的长连接,需要通过心跳包的方式来维护连接状态(注意:这里的心跳包并不是tcp自带的心跳,而是应用层自行实现的心跳机制)

• 主从节点彼此都会存在心跳检测机制,各自模拟成对方的客户端进行通信
• 主节点默认每个10秒对从节点发送ping命令,判断从节点的存活性和连接状态
• 从节点默认每隔1秒向主节点发送replconf ack {offset}命令,给主节点上报自身当前的复制偏移量
  如果主节点发现从节点通信演出超过repl-timeout配置的值(默认60秒),则判定从节点下线,断开复制客户端连接.从节点恢复连接之后,心跳机制将继续进行.

原文地址：https://blog.csdn.net/2301_78320637/article/details/142578853

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！