Redis-主从同步原理

前言

Redis为了保证服务高可用,其中一种实现就是主从模式,即一个Redis服务端作为主节点,若干个Redis服务端作为主节点的从节点,从而实现即使某个服务端不可用时,也不会影响Redis服务的正常使用。本篇文章将对主从模式中为了保证主节点和从节点数据一致而实现的主从同步机制进行学习。

参考:
https://redis.io/docs/manual/replication/

正文

一. 主从数据同步概述

Redis主从模式中,一个高可用的Redis服务由一个Redis主节点(Master,后续简称为主节点)和若干Redis从节点(Slave,后续简称为从节点)组成。

Redis中采用读写分离来保证主节点和从节点之间的数据一致性,具体实现如下。

  • 主节点支持数据写入数据读取,从节点只支持数据读取
  • 主节点会与从节点之间执行主从数据同步,以保证主节点数据与从节点数据一致。

主从数据同步分为如下几种情况。

  • 从节点与主节点建立连接时进行全量同步;
  • 主节点与从节点正常运行时的同步;
  • 主节点与从节点连接断开后又重连时会进行增量同步或全量同步。

本篇文章将对Redis中的主从数据同步的几种情况进行学习。

二. 从节点与主节点建立连接时的全量同步

从节点与主节点建立连接时的全量同步可以用下图进行示意。

对于上图所示步骤,说明如下。

  1. 从节点通过配置文件中的replicaof {masterip} {port}获得主节点ipport,然后向主节点发送psync {repID} {offset}指令,其中repID表示主节点唯一标识,offset为复制偏移量,因为当前从节点与主节点尚未连接,且尚未开始复制,所以repID?offset为-1;
  2. 主节点收到psync {repID} {offset}指令后,会响应从节点并发送fullresync {repID} {offset}指令,从节点会将主节点的repIDoffset保存下来;
  3. 主节点收到psync {repID} {offset}指令后,会执行bgsave异步的生成RDB文件,然后主节点将RDB文件发送给从节点,从节点接收到RDB文件后,会清空内存数据,然后加载RDB文件的数据到内存中;
  4. 由于主节点生成RDB文件时是异步生成的,此时主节点是非阻塞的,可以继续处理业务,所以在生成RDB文件期间发送RDB文件期间从节点加载RDB文件期间主节点执行的写指令均会存放到缓冲区replication_buffer中,所以当从节点加载完RDB文件后,主节点会将replication_buffer中的内容发送给从节点,从节点会执行replication_buffer中的指令,从而达到和主节点一致的状态。

特别说明:在全量同步期间,主节点是非阻塞的,同时从节点很大程度上是非阻塞的,从节点的非阻塞表现在可以通过配置让从节点在全量同步期间使用旧内存数据来处理查询指令,但是从节点在删除旧内存数据并加载RDB文件数据到内存中这段时间里,从节点是阻塞的(4.0版本前,删除旧数据和加载RDB文件都会阻塞从节点,4.0版本开始,删除旧数据可以通过配置变成不阻塞从节点,但是加载RDB文件还是会阻塞从节点)。

最后说明一个异常情况,那就是replication_buffer是有大小限制的,如果replication_buffer大小超过了限制,主节点会断开与从节点的同步连接,此时replication_buffer的数据会被清空,然后会重新开始全量同步,所以replication_buffer大小需要设置一个合理值。

三. 主节点与从节点正常运行时的同步

参见https://redis.io/docs/manual/replication/中的一段话。

When a master and a replica instances are well-connected, the master keeps the replica updated by sending a stream of commands to the replica to replicate the effects on the dataset happening in the master side due to: client writes, keys expired or evicted, any other action changing the master dataset.

即正常运行期间,主节点会向从节点发送写指令流来同步主节点的数据变更到从节点。

四. 主节点与从节点断开连接又重连时的增量同步

在第二节中提到了从节点在启动后并需要与主节点进行全量同步时,会向主节点发送psync {repID} {offset}指令,这里先对repIDoffset进行解释。

repID

repIDReplication ID,是Redis节点作为主节点启动时,或者从节点被晋升为主节点时,该主节点都会生成一个新的repID(思考一下什么情况还会有旧的repID),后续连接到该主节点的从节点在第一次全量同步的建立连接阶段会保存一份主节点的repID,所以具有相同repID的节点的数据具有相关性。

offset

offset即偏移量,可以理解为当前节点的数据的逻辑时间。举个例子,某个节点Aoffset为500,和节点A具有相同repID的节点Boffset为520,那么表明节点B的数据比节点A的数据更新,节点A需要再执行一些写指令才能够让节点A的数据状态和节点B一致。

有了上述两点认识,现在思考一个问题:主节点和从节点如果因为某些原因,断开了连接,而断开连接这段时间里主节点又处理了一些写指令,那么从节点重新连接后,应该怎么将断开连接那段时间里的写指令同步给重连的从节点?通常的想法就是再执行一次全量同步,在2.8之前的版本,确实是这么实现的,但从2.8版本开始,引入了增量同步,具体的实现如下。

  • 主节点维护着一份repl_backlog_buffer缓冲区域,叫做复制积压缓冲区,主节点在任何时候执行写指令时,都会将写指令记录在repl_backlog_buffer中,repl_backlog_buffer是一个环形数组,所以当数组满时,后续再添加的写指令会覆盖旧的写指令,因此主节点还使用了一个叫做master_repl_offset的偏移量,来记录主节点的存到repl_backlog_buffer中的最新写指令的位置,master_repl_offset就是上面提到的offset,只不过在主节点中叫做master_repl_offset
  • 从节点也有一个偏移量叫做slave_repl_offset,用来记录从节点已经从主节点的repl_backlog_buffer中同步到的最新写指令的位置;
  • 主节点收到写指令后,master_repl_offset增加,从节点从主节点的repl_backlog_buffer同步了写指令后,slave_repl_offset增加;
  • 从节点断开重连后,会向主节点发送psync {repID} {slave_repl_offset}指令,此时slave_repl_offset通常会小于master_repl_offset,所以主节点仅需要将slave_repl_offsetmaster_repl_offset之间的写指令同步给从节点,这就是增量同步

特别注意:如果repl_backlog_buffer中记录的从节点断开连接期间的写指令已经被后续的写指令覆盖,那么此时不能执行增量同步,而是需要执行全量同步,所以需要将repl_backlog_buffer的大小设置一个合理的值,来尽可能的保证不出现重连后需要全量同步的情况。

总结

以一张图进行总结。

41 声望
23 粉丝
0 条评论
推荐阅读
数据库连接池-Druid数据库连接池源码解析
本文将对Druid数据库连接池的源码进行分析和学习,以了解Druid数据库连接池的工作原理。Druid数据库连接池的基本逻辑几乎全部在DruidDataSource类中,所以本文主要是围绕DruidDataSource的各项功能展开论述。

半夏之沫阅读 993

Redis 发布订阅模式:原理拆解并实现一个消息队列
“65 哥,如果你交了个漂亮小姐姐做女朋友,你会通过什么方式将这个消息广而告之给你的微信好友?““那不得拍点女朋友的美照 + 亲密照弄一个九宫格图文消息在朋友圈发布大肆宣传,暴击单身狗。”像这种 65 哥通过朋...

码哥字节6阅读 1.3k

封面图
Redis高可用之哨兵机制实现细节
在上一篇的文章《Redis高可用全景一览》中,我们学习了 Redis 的高可用性。高可用性有两方面含义:一是服务少中断,二是数据少丢失。主从库模式和哨兵保证了服务少中断,AOF 日志和 RDB 快照保证了数据少丢失。

杨同学technotes4阅读 1.1k

1.5万字总结 Redis 常见面试题&知识点
Redis 是一个基于 C 语言开发的开源数据库(BSD 许可),与传统数据库不同的是 Redis 的数据是存在内存中的(内存数据库),读写速度非常快,被广泛应用于缓存方向。并且,Redis 存储的是 KV 键值对数据。

JavaGuide3阅读 797

封面图
Redis的数据被删除,占用内存咋还那么大?
通过 CONFIG SET maxmemory 100mb 或者在 redis.conf 配置文件设置 maxmemory 100mb Redis 内存占用限制。当达到内存最大值值,会触发内存淘汰策略删除数据。

码哥字节2阅读 608

封面图
深入理解redis——缓存双写一致性之更新策略探讨
1.Redis缓存双写一致性我们都知道,只要我们使用redis,就会遇到缓存与数据库的双存储双写,那么只要是双写,就一定会有数据一致性问题,为了保证双写一致性,我们要先动redis还是mysql?

苏凌峰阅读 2.7k

Reids的BigKey和HotKey
Redis big key problem,实际上不是大Key问题,而是Key对应的value过大,因此严格来说是Big Value问题,Redis value is too large (key value is too large)。

Java架构师2阅读 475

41 声望
23 粉丝
宣传栏