redis主从同步原理---原生以及 基于binlog的主从同步不

2022/4/14 19:12:59

本文主要是介绍redis主从同步原理---原生以及 基于binlog的主从同步不,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1. 背景

上半年我们使用RocksDB做存储引擎,实施了Redis数据实时落地的项目,实现了在兼容redis协议的前提下,管理超出内存大小的数据集。

在主从同步方面,我们沿用了Redis原有的方案,该方案在实际运营中应对不良的网络状况显得很无力,因此我们在数据落地的基础上,为Redis开发了一套新的主从同步机制。

2. Redis原生同步方式

主从数据同步分一般两步走:同步已有的全量数据,和同步增量数据。同步的全量数据必须是master数据集的point-in-time的快照;增量数据则从快照完成的瞬间算起。如图(一),

图 (一) Redis原生主从同步机制

slave给master发送sync命令请求同步数据,master收到sync命令后,将内存数据镜像(point-in-time)保存为dump.rdb文件,同时将新进来的写请求保存到client-buffer中;master首先将生成的内存镜像文件dump.rdb同步给slave(全量数据同步),完成后,将client-buffer中累积的写请求同步slave(增量数据同步)。这个机制足够简单,但是在实际运营中会遇到一些问题:

  • slave一旦同master断开,重连后如果不能做psync(实际运营中psync基本没有成功过),就要同步master的全量数据
  • 实际运营中一般会做多实例部署,一台Z3服务器部署20 - 40 不等的实例数,一旦网络闪断,导致几十个master实例同时fork做bgsave,场面感人; 通常结果就是内存不够,做bgsave的进程被kill掉
  • 如果同步全量数据时,master实例上写请求量大,使client-buffer占用内存超限,master会主动断开和slave的连接,这样之前的全量数据就白做了

这里的根本矛盾是Redis本身定位和我们的要求有偏差。Redis所有操作都是基于内存, 数据存在内存,用于断开重连的backlog保存在内存,主从同步时的增量数据保存在内存,可每台服务器内存就那么多,能存储的数据量是有限的;而我们在更多场景下,要求Redis在提供足够性能的前提下,存储尽量多的数据。我们需要在性能和数据量,以及可运营性之间做折中。

3. 基于binlog的数据主从同步

前面已经提到,我们已经实现Redis数据实时落地到RocksDB中。 这里进一步,我们将数据的修改记录以一定的格式(binlog)落入RocksDB中,并实现基于binlog的主从数据同步。

3.1 落地binlog

我们对Redis每种具有写语义的命令定义一种binlog,注意是一种,而不是一条。 总共定义了16中binlog, 如图(二):

图 (二) 十六种binlog类型

所有类型binlog都需要满足两个条件, 原因后面展开:

  • 每条binlog需要记录它所修改的数据存储于RocksDB中的key
  • 一条binlog修改的数据不能对应RocksDB中多对key/value

3.2 基于binlog的主从同步

前面提到过,主从数据同步分两步,全量数据同步和增量数据同步。master收到一个新的slave的同步请求时,master给RocksDB做个快照,快照中数据分两部分,Redis的数据集和写数据时生成的binlog。master把快照中数据集发给slave即实现全量数据同步;master记录快照中最大的binlog序列号MaxSeq, 把序列号从MaxSeq+1开始的binlog逐条发给slave即可实现增量数据同步。流程很简单,如下图:

图 (三) 基于binlog的主从数据同步

3.3 主从连接断开处理

我们已经知道Redis主从同步机制要求slave断开重连master后,同步(psync绝大多数情况下不管用)master的全量数据。这个机制的问题上面已经提过。 如何解决呢? 很直观,如果slave重连后,能够从断开的位置开始,继续同步master数据,这是最好的。 为了实现这一点,我们以master的视角将slave的同步过程划分为四个状态,图(四)描绘了四个状态之间的转换图:

  • REPL_PASTE,master和slave做全量同步
  • REPL_RESUME,slave全量同步时与master断开后重连
  • REPL_FOLLOW,slave和master做增量同步
  • REPL_OUTSYNC,master无法找到slave所需要的binlog

图(四) slave同步状态转换图

具体看下每个状态下slave和master断开后重连,如何做续传的:

case 1: 正在做全量同步的slave断开与master连接,重连后的续传

一个空slave实例连上master开始做全量数据同步, slave处于REPL_PASTE状态。 master创建snapshot 1,如下图,

图(五) 空的slave实例连上master同步全量数据

此时,master将snapshot 1的数据集同步(逐个key/value对发送)给slave,并且把snapshot 1最大的binlog序列号MaxSeq发给slave。slave记录(持久化到RocksDB中)自己的同步状态为REPL_PASTE,和收到最大的binlog序列号为MaxSeq,并实时更新最后接收的key。假设slave处理完LastKey(此时master的数据集尚未完全同步给salve)即与master断开,稍后重新连上,进入REPL_RESUME状态。此时,master创建snapshot 2,如下图:

图(六) 做全量同步的slave断开重连master后做“续传” (注意:snapshot 1和snapshot 2是RocksDB不同时刻的两个状态,不可能同时存在,这里这样画图只为了方便比较)

断开时slave同步到snapshot 1的LastKey处,收到的最大binlog序列号为MaxSeq。 重连后,我们要在不清空slave数据集和不全量同步snapshot 2的前提下,把slave的数据更新为snapshot 2,达到“续传”的效果。 先来个拍脑袋的做法:在snapshot 2中找到LastKey, 从紧跟在它后面的LastKey’开始的key/value对起继续同步。 这样做不对,有两个原因: 1) LastKey可能不存在,它可能在slave断开期间被删除 2) 在LastKey之前,可能有key/value在slave断开期间被修改,也有可能新的key/value被写入

因此这种做法会导致丢失一部分写操作。为了解锁正确的姿势, 我们先找到snapshot 1和snapshot 2之间的差异:

snapshot 2 = snapshot 1 + binlog[ MaxSeq + 1 ... MaxSeq’]

也就是, 把序列号从MaxSeq+1开始到MaxSeq’结束的binlog应用到snapshot 1上,即可得到snapshot 2。进一步,由于RocksDB中key/value按照key的字典序有序存储,以LastKey为界,这些binlog一定是一部分应用到位于LastKey之前(含LastKey)的key/value对,另一部分应用到位于LastKey之后的key/value对。所以,可以把snapshot 2的数据集分成两部分处理,一部分位于LastKey之前(含LastKey),一部分位于LastKey之后。由于slave在断开前已经同步了snapshot 1位于LastKey之前(含LastKey)的数据,我们只需要把这部分数据更新到与snapshot 2一致即可。做法:把序列号位于[MaSeq+1, MaxSeq’]范围内,且只应用到LastKey之前(含LastKey)的key/value对的binlog同步到slave。此时slave进入REPL_PASTE状态。由于snapshot 2中位于lastKey之后(lastKey’紧随lastKey之后)的数据对于slave而言,是全新的,将这部分数据同步给slave后,snapshot 2的数据集就完全同步到slave了。此时slave进入REPL_FOLLOW状态。

3.1中提到,一条binlog不能修改多于一对底层key/value,这里解释下原因。在前面的处理中,要求把做snapshot 1后, 做snapshot 2之前master上生成的binlog应用到slave已同步的数据集(位于snapshot 1的LastKey之前)。 假设其中一条binlog既修改了LastKey之前的k1/v1,也修改LastKey之后的k2/v2,比如rpoplpush对应的binlog。我们知道k1/v1是snapshot 1中的数据,对其应用binlog可以将其更新为snapshot 2的数据;而k2/v2本身就是snapshot 2的数据,对其应用binlog会破坏snapshot 2的point-in-time特性。因此,rpoplpush操作需要落两条binlog,RPOP和LPUSH。

case 2:处于REPL_RESUME状态的slave和master断开后重连

重连时,slave将其断开前所处的同步状态,最后同步的key和最后同步的binlog序号发给master, slave进入REPL_RESUME状态,和case 1 的处理方式一致。

case 3: 处于REPL_FOLLOW状态的slave和master断开后重连

slave重连将后进入REPL_FOLLOW状态。 处于这个状态的slave在做增量同步,master不需要为其生成快照。 由于slave重连时把最后同步的binlog序号MaxSeq发给了master,master只需要找到序号从MaxSeq+1开始的binlog,将它们同步给slave即可,如图:

图 (七) 做增量同步的slave断开重连master后做“续传”

4. 小结

我们为Redis增加了一种新的基于binlog的主从数据同步方式,实现了主从断开后slave和master间数据“续传”,避免了每次slave都要全量同步master数据,给master带来过大压力。 另外,由于有了binlog,我们可以做历史数据恢复,这里就不具体展开了。

 

参考:redis基于binlog的主从同步



这篇关于redis主从同步原理---原生以及 基于binlog的主从同步不的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程