Redis基于RDB+AOF的数据恢复策略研究

张文帅

摘要：该文针对Redis数据库中两个问题，RDB（Snapshot）恢复数据不完整和AOF（Append Only File）恢复速度慢，提出了RDB+AOF的数据恢复方案。该方案借鉴检查点思想，依赖RDB和AOF两种方法，不但具有AOF恢复数据全面的特点，又兼具RDB恢复速度快的优势。按照此方案修改Redis源码并作对照实验，结果证明该方案可行且有效。

关键词：Redis；数据恢复；检查点；RDB+AOF

中图分类号：TP391 文献标识码：A 文章编号：1009-3044（2016）14-0007-04

Research on a Data Recovery Strategy Based on RDB and AOF in Redis

ZHANG Wen-shuai

（School of Mechanical Electronic and Information， China University of Ming and Technology（Beijing）， Beijing 100083， China）

Abstract： This paper in order to solve two problems in Redis database，one is that the restored data is not complete through RDB（Snapshot），the orther is the speed is slow through AOF（Append Only File），put forword a data recovery method which combined RDB with AOF.The scheme， which is used checkpoint for reference， depends on the two methods of RDB and AOF， which not only has the characteristics of comprehensive recovery like AOF， but also has the advantage of rapid recovery like RDB.In accordance with this program to modify the Redis' source code and do a control experiment， the results show that the program is feasible and effective.

Key words： Redis； data recovery； checkpoint； RDB+AOF

数据库技术的发展，带动了NoSQL（非关系数据库）的崛起，其中Redis（REmote DIctionary Server）数据库因其高效性得到广泛应用。它是一个用C语言编写的开源的内存数据库，支持数据持久化。

持久化是内存数据库数据恢复的前提。Redis支持两种数据持久化方法：一种是RDB，能周期性地对数据库做快照并写入磁盘。RDB恢复速度较快，但两次快照期间的数据都会丢失；另一种是AOF，将每次写操作都记录日志，并定期写入磁盘。AOF恢复速度较慢，但能恢复全部数据，不会造成数据丢失的现象。

本文通过分析RDB和AOF的原理和特点，结合多种数据库在数据恢复技术方面的方法和经验，提出了一种RDB+AOF相结合的方案，该方案将解决RDB恢复数据不完整和AOF恢复速度慢的缺点，对于Redis能够完整快速恢复数据具有很重要的实用意义。

1 数据库恢复技术概述

1.1 关系数据库恢复技术

关系数据库恢复技术主要有数据转储和登录日志文件两种，为了维护事务的特性，必须使用日志方式，以便数据恢复时可以进行相应的redo（重做）和undo（撤销）操作，维持事务一致性。为了解决日志恢复速度慢的缺陷，关系数据库在日志基础上发展了检查点技术。

传统日志恢复方法需要遍历整个日志文件，且要重新执行所有操作，这将造成很多时间浪费，为此发展了检查点技术。该技术在日志文件中增加检查点，检查点是这个时刻数据库的一致性备份，再增加一个重新开始文件，用于记录检查点在日志文件中的地址，数据恢复时从重新开始文件找到某个检查点在日志文件中的地址，并从日志中找到这个检查点开始数据恢复，节省了遍历日志和重复操作的时间和资源。

检查点技术对事务的恢复工作可分为以下三种情况[1]：

（1）在检查点之前完成的事务，更新已经写到数据库中，不需要再重做；

（2）检查点之后、故障点之前完成的事务，虽然事务已结束，但它们对数据库的修改可能还未来得及写到磁盘上，必须要重做；

（3）故障点时刻尚未结束的事务，它们的操作是不完整的，需要撤销。

1.2 内存数据库恢复技术

内存数据库（MMDB）由于内存的易失性，需要将数据持久化到磁盘，不同于普通外存数据库，MMDB需要一次性将数据全部加载到内存，因此日志文件的大小是限制MMDB数据恢复的一个重要因素。

MMDB依然沿用了检查点技术，并在此基础上，结合了影子内存技术、模糊检查点技术、多版本控制技术等[2，3]，这些方法的共同点都是减少undo日志的记录。它们将MMDB的操作在影子页上执行，如果事务提交，则记录redo日志，将影子页的操作反映到MMDB，若事务撤销，则只需放弃影子页即可。这样便可以不记录undo日志，且双版本可以提供数据库的动态转储。

对于内存数据库，数据持久化也是重要一环。梁智兴通过添加非易失性内存作为备份缓冲区，提出两步备份机制[4]；周晓云利用高速局域网充当内存缓冲区，提出了利用网络工作站内存加速内存数据库日志记录持久化的技术方案[5]。这些都是对数据持久化的改进。

2 Redis数据库恢复技术概述

Redis数据库是一种高效的内存数据库，它的数据恢复包括两个步骤：数据持久化和数据恢复。Redis数据库提供两种持久化方式， RDB和AOF[6]。数据持久化生成的文件用于Redis数据库重启时的数据恢复。

2.1 RDB

RDB就是Snapshot快照存储，是默认的持久化方式。它按照一定的策略周期性的将数据存储到磁盘，生成名为dump.rdb的文件，RDB的执行周期可以通过配置文件中的save来配置[7]。

Redis数据库会在达到RDB配置周期或接收到客户端的save和bgsave命令时触发RDB操作[8]。其中save触发RDB操作时，Redis阻塞客户端新的请求，是为静态转储；而对于bgsave命令，Redis可以继续接收处理新命令，是为动态转储。

RDB操作借用copy on write机制进行写时复制[9]，父进程fork一个子进程，由子进程进行内存遍历将数据写入临时文件，父进程仍处理客户端请求，待子进程执行完毕，将临时文件rename为dump.rdb，因此无论RDB是否成功，dump.rdb都是完整的。

dump.rdb是一种紧凑的二进制文件，文件很小利于备份，也常用于主从复制。RDB方式恢复速度快，但周期性的特点注定不能恢复两个周期之间的数据。

2.2 AOF

AOF是一种追加性日志文件，Redis数据库会将收到的所有写命令按AOF文件协议顺序追加到AOF文件中，因此AOF比RDB方式有更好的持久化性。在数据恢复时，Redis数据库通过重新执行AOF文件中保存的写命令，在内存中重建整个数据库的内容。

AOF可以通过在配置文件中设置appendonly为yes/no来开启或关闭，还可以设置fsync为no/everysec/always来改变同步策略为关闭或每秒同步或每个写操作同步。

AOF操作生成appendonly.aof，这是一种文本文件，按AOF协议记录所有写操作[10]。日志不断追加，文件会越来越大，Redis提供了AOF重写机制。AOF重写在appendonly.aof增长到设定值或接收到bgrewriteaof命令时触发。

AOF重写由父进程fork一个子进程，子进程遍历数据库内存并将数据记录到临时文件，父进程继续接收客户端请求，将后续写操作追加到appendonly.aof和AOF重写缓存，待子进程执行完毕，将缓存内容追加到临时文件，并rename为appendonly.aof完成重写操作[11]。

AOF可以记录所有写操作，恢复时可以恢复全部数据，但日志文件体积较大，且恢复时需模拟客户端重新执行日志所记录的操作，恢复速度较慢。

3 RDB+AOF的恢复方案

RDB恢复数据不完整，AOF恢复速度慢，为了解决这两大问题，本文提出了RDB+AOF的方案。

3.1 方案简介

RDB+AOF组合方案是指Redis同时开启RDB和AOF选项，以AOF为主记录日志，当日志文件达到阈值触发AOF重写时，不再使用原有的重写机制，而让Redis服务fork一个子进程执行RDB操作，生成一个临时RDB文件，主进程依然接受客户端请求，并将命令写入AOF文件和一个临时AOF文件中，待子进程结束，将新生成的RDB临时文件rename为dump.rdb，而将临时AOF文件rename为appendonlyfile.aof，至此一次RDB+AOF组合的持久化就完成了。

持久化生成的RDB和AOF文件都将用来进行数据恢复，恢复策略是首先Redis数据库加载RDB文件，将数据库恢复到最新一次快照时的状态，然后模拟客户端，将AOF文件中的命令执行一遍，使数据库恢复到上次关机或故障时的状态，这样数据库的恢复就完成了。

RDB+AOF方案的具体执行流程如图1：

3.2 方案原理

要结合RDB和AOF两种方案，需要分析一下RDB+AOF的可行性。

（1）基于命令执行的数量触发

RDB依据配置在一定时间内完成一定的命令就会触发，例如60秒内修改了10000条记录；而AOF是按AOF协议将命令记录到日志文件，在文件大小达到阈值时触发重写，本质也是完成一定的命令导致AOF重写。

根据Redis命令的原子性，RDB和AOF重写都将在完成命令的时刻执行，因此执行时不会有执行一半的命令，保证了文件的完整性，也为RDB+AOF相结合提供了保障。

（2）copy on write机制

Copy on write机制是父子进程共享同一物理内存，即子进程借用父进程的内存做遍历操作，若此时父进程接收到写命令，父进程会为写命令影响到的内存数据开辟新内存，写命令所造成的脏数据只会影响到这块新开辟的内存，子进程使用的依旧是RDB或AOF重写开始时的内存空间，这种写时复制机制完美解决了动态复制的问题。

RDB和AOF重写都使用copy on write机制，这为RDB+AOF方案中用RDB代替AOF重写提供了保障。

（3）非事务一致性

Redis虽然提供简单的事务支持，但并不提供回滚功能，也就是不保证事务一致性，因此日志并不需要记录undo日志。因此RDB和AOF文件本质都是数据的映像，没有什么区别，为RDB+AOF方案提供了便利条件。

（4）日志的追加性

日志文件是按时间追加的，在RDB+AOF方案中，检查点之前的日志对数据恢复已经没有作用，可以删掉减小文件体积，这就是用AOF临时文件覆盖原文件对理论支持。

3.3 对照试验

本次实验有三个目标：数据持久化速度、数据恢复速度和数据恢复完整性。

本实验的实验环境为Mac OS X 10.11.1系统，2.7 GHz Intel Core i5处理器，8G内存以及Redis3.0.7。

3.3.1 数据持久化速度

数据持久化速度以写入相同数据量所用时间来计算。如图2为分别写入100、10000、100000、1000000条数据时RDB、AOF以及RDB+AOF三种方案的耗时情况。

图2中AOF方式的同步策略为每秒同步，由图中可以看出每秒同步的AOF方式与RDB方式在持久化方面性能相差不大，而RDB+AOF方案是以AOF为主要持久化方案，只在AOF重写时由RDB代替，因而性能接近AOF方式。

3.3.2 数据恢复速度

数据恢复速度以加载相同数据量所用时间来表示。对数据持久化所得文件进行加载，得到三种方式加载时间的对比，如图3所示：

从图中可以看出，三种方式数据恢复速度相差很大，AOF方式恢复速度是RDB方式的2倍左右，而RDB+AOF方式恢复速度介于两者之间。

比较RDB和AOF两种方式对相同数据持久化产生的文件大小，如表1所示：

表中所示AOF文件是RDB文件的2倍左右，这也可以解释为何AOF方式恢复时间是RDB方式的2倍。

而RDB+AOF方式的恢复速度介于两者之间，具体情况如表2所示：

从表2中可以看出，RDB+AOF方式随着RDB和AOF文件大小的比例在变化，在RDB+AOF方案中，随着AOF重写，数据不断从AOF文件转移到RDB文件，它的恢复时间也从AOF方式向RDB方式的方向不断减少，理想状态下将达到RDB方式的恢复速度。

3.3.3 数据恢复完整性

数据恢复完整性以恢复的数据量为准。对三种方案分别写入5条新数据，然后kill掉Redis服务，重启服务后检查新数据的恢复情况，如表3所示：

从表中可以看出，RDB+AOF方案完美继承了AOF恢复数据完整性的优点。

4 结论

本文借鉴检查点恢复方法的思想，在Redis数据库中，巧妙地结合了RDB和AOF两种方法，利用AOF日志完整记录数据库操作，又通过RDB代替AOF重写，利用RDB文件恢复速度快的特性减少了恢复时间。RDB+AOF恢复方案，能够在完整恢复数据库的前提下提高恢复速度，在持久化时，数据会随AOF重写从AOF文件转移到RDB文件，理想情况下可以达到RDB的恢复速度。但重写本身也是一个耗时操作，数据持久化需要和数据恢复达到平衡，才能达到最合适的用户体验，这将是进一步的研究方向。

参考文献：

[1] 周如意. 基于检查点的数据库恢复技术[J]. 沙洲职业工学院学报， 2006（2）：11-14.

[2] 黄琳， 路京， 林中. 基于影子页面的MMDB的数据恢复方法[J]. 计算机工程与设计， 2008， 29（10）：2470-2473.

[3] 杜晔. 空间实时内存数据库恢复机制研究与实现[D]. 中国科学院研究生院， 2012.

[4] 梁智兴， 罗军. 基于两步备份机制的内存数据库恢复方法研究[J]. 网络安全技术与应用， 2010（1）：24-27.

[5] 周晓云， 覃雄派. 基于网络内存的内存数据库高效恢复技术[J]. 系统工程理论与实践， 2011， 系统工程理论与实践， 2011， 31（增刊2）：81-87（S2）：81-87.

[6] 马豫星. Redis数据库特性分析[J]. 物联网技术， 2015（3）：105-106.

[7] Hey！ Linux. Redis持久化实践及灾难恢复模拟[EB/OL]. http：//heylinux.com/archives/1932.html， 2012-09-27.

[8] 常飞梦. 验证redis的快照和AOF[EB/OL]. http：//blog.csdn.net/lichangzai/article/details/8692103， 2013-03-19.

[9] 娄振林专栏. redis源码分析（7）——rdb[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44650847/， 2015-04-15.

[10] 娄振林专栏. redis源码分析（5）——aof[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44035453/， 2015-03-17.

[11] 娄振林专栏. redis源码分析（6）——aof rewrite[EB/OL]. http：//blog.csdn.net/chosen0ne/article/details/44461497/， 2015-03-23.