Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计

11月30日云栖社区在线培训,云栖社区请来了阿里云资深开发工程师夏德军为大家带来阿里云Redis内核优化的分享。本文从两大方面介绍阿里云Redis服务,一是Redis内核支持基于时间点的备份恢复,一是Redis基于AOF日志的增量同步机制设计,并分别通过假设场景,详细的分析了备份恢复流程和AOF PSYNC流程。一起来了解下吧。

直播视频回顾

Redis内核支持基于时间点的备份恢复

Redis内存数据库,须有一种机制能够把内存中的数据持久化到硬盘上,再将硬盘中数据备份到备份系统中,才能去做恢复。Redis原生的持久化机制包括RDB持久化和AOF持久化两种。

RDB持久化

RDB持久化触发方式有两种:

  • 手动触发:执行 BGSAVE命令;
  • 自动触发:配置 SAVE选项,在指定时间内发生指定次数的 key修改,自动进行后台 RDB SAVE。

RDB持久化流程如下:

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第1张图片

在做RDB SAVE时需要fork一个子进程,每次RDB SAVE生成一个对应时间点的内存快照文件。

AOF持久化

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第2张图片

  • 配置 appendonly 选项,可以动态开关;
  • RDB 持久化不太一样的是,每一次的写操作命令都会追加到 aof 文件中,根据配置的 appendfsync 选项不同,会有不同 aof 文件刷新策略;
  • Redis 通过 AOF Rewrite 的方式来“紧凑” AOF ,解决持续追加导致 AOF 文件过大的问题。

当前备份恢复方式

现在Redis内核能够支持的备份方式有两种:

1. 备份RDB:执行BGSAVE命令 -> Fork子进程 -> 生成rdb文件 -> 备份rdb文件;

2. 备份AOF:根据aof大小判断是否需要先做一次AOF Rewrite,备份aofAOF Rewrite同样需要Fork子进程。

两种方式都是备份一个全量数据文件,通常不会选择备份aofrdb格式更为紧凑,备份开销更小。

恢复时,创建实例,从备份系统拉取全量的aofrdb文件到实例数据目录,恢复数据。

当前内核备份恢复方式只能做全量数据的备份和恢复,fork子进程生成全量快照的方式开销比较大。

应用场景举例

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第3张图片

如果能够不管几点上线,都能恢复Redis数据到那个时间点,场景中的问题将不再存在。

Redis基于时间点的备份恢复

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第4张图片

我们的目标就是要恢复数据到任意时间点,我们做了基于AOF改造的增量日志,禁用AOF Rewrite,日志按照配置大小自动切分。除了每个命令执行的历史日志要保存下来,还需要添加一些额外的信息,比如:

  • 根据系统时间戳命名AOFAOF中除了包含原有的Redis协议格式的命令(Oplog),每个Oplog还对应了一个Header
  • Header中包含多个字段,其中timestamp记录了命令执行时的时间戳,基于任意时间点恢复时就依赖于该信息;
  • server_idopiddbid是为后面讲的主从同步优化所设计,reserved为保留字段;
  • Oplog Header以二进制的形式用Redis命令封装,保持AOF协议格式不变。

AOF日志管理

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第5张图片

AOF会按固定大小做切分,我们需要将AOF日志进行管理,主要有以下三点:

1. 使用AOF Index索引文件记录Redis当前维护的AOF文件;

2. 使用专门的清理命令删除AOF,同时维护AOF index文件的正确性;

3. BGSAVE完成时需要记录RDB文件对应的AOF日志名和文件写入偏移,这个信息保存在rdb index文件中。

本地定时BGSAVE

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第6张图片

我们也需要本地定时BGSAVE机制,AOF会越变越大,仍然需要某种方式来“紧凑”AOF日志,比如AOF Rewrite方式复合式进程重写AOF日志,Redis实例在本地也需要保存一份持久化的全量数据,重启时从AOF日志恢复数据是不现实的。

对此,我们引入Cron BGSAVE,当AOF日志的增长量满足一定条件时,触发BGSAVE,生成RDB文件,该RDB文件对应的时间点之前的AOF日志在本地都是不需要的,只要已经上传到备份系统,即可删除。

备份恢复流程

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第7张图片

时间点备份恢复的流程如图所示,左侧假如有一个Redis-Server实例,追加写AOF6文件,接着实时备份AOF日志,上传到备份空间中,同时也有定时全量备份,每一个RDB文件会对应一个RDB文件写入偏移,每个AOF文件会有一个起始时间;右侧指定要恢复的时间点,Redis顺序加载RDBAOF到指定地点。

备份和原来全量备份的区别在于,需要实时持续地把Redis生成的AOF增量日志不断的备份下来,我们也要有删除的机制,比如保存一个星期或一个月的情况。

Redis基于AOF日志的增量同步机制设计

Redis原生同步机制主要有两种,全量同步和增量同步。

全量同步

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第8张图片

全量同步代价非常大,全量同步意味着有一个空的Redis实例挂上来后,Master需要做一次BGSAVE,还需要网络传输RDB文件,发送给slave,大量占用主库带宽、cpu资源,大内存时fork会导致redis hang住,虽然fork是写实复制,但需要copy页表,如果内存比较大,页表也会比较大。

增量同步

Redis2.8中引入了增量同步机制,是为了解决网络偶尔的抖动导致需要全量同步的问题。

增量同步机制实现比较简单,masterslave之间维护一个一致的同步offset,此外,master还在内存里面维护了一个同步buffer,保存了最近一段时间内的更新命令日志,当slave断链重连时,会根据自己的同步偏移从master的同步buffer直接拉取数据,完成同步。

理想情况下,这个流程同步很快,代价很低,但是当网络断开时间较长时,或主库写入非常大时,同步Buffer会将历史数据覆盖掉,仍然需要全量同步。而且,现有的增量同步机制,也没有解决一主多从场景下,主从切换,其他从需要从新主全量同步的问题。

应用场景举例

有不少使用Redis的业务的重要性很高,譬如说金融业务,都有跨机房,甚至跨地域灾备的需求,而跨机房或跨地域的网络质量往往很难保证。

假设有一天,Redis业务的杭州主机房和深圳的备机房之间的光纤被人挖断了,网络中断数小时,恢复后,深圳机房所有的备实例同时发起全量同步,导致的后果很可能是:主库所在机器带宽、cpu打满,甚至有些机器会直接OOM,而备又还没有完成同步,后果可能是灾难性的,对此,我们该如何处理呢?

基于AOF日志的增量同步(AOF PSYNC

由于现有机制存在的问题,以及真实场景中业务需求的推动,我们想到不依赖于具体内存的Buffer,用增量日志做增量同步,那么,基于AOF日志的增量同步是怎么实现的呢?具体原理解释如下:

  • 当主从同步断开,需要拉取增量时,会先选择尝试基于同步偏移从主库同步buffer获取数据,如果同步buffer缺少增量数据,会开始从AOF日志获取增量;
  • AOF PSYNCAOF日志中的opid作为同步基准,slave继承从主库同步过来的opid,并记录在自己的AOF日志中;
  • 使用opid作为同步基准是因为对于带过期时间的命令,RedisAOF和写同步buffer的字节序列不一样,Redis在写AOF时会转换设置过期时间的命令为PEXPIREAT
  • AOF日志中的dbid,决定了AOF中的每条命令写入的db是哪个。AOF PSYNC同步完成后,会同步masterslave间的同步偏移。

AOF PSYNC流程

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第9张图片

1. Master收到SlaveAOF PSYNC请求后,会使用后台线程来查找offset,避免server hang住;

2. 根据slave发送的opid查找到起始的AOF文件后会异步的通知主线程;

3. 主线程会异步发送一个或多个AOF文件给SLAVE,发送完成后,需要同步aof buffer

4. 如果slave给定的opidmasterAOF中不存在(AOF可能被异常删除),会发起全量同步。

阿里云Redis服务

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计_第10张图片

与其它Redis对比,阿里云Redis服务具备高可靠、高性能、高扩展、易用的特点。

你可能感兴趣的:(数据库)