Redis学习笔记(九)Persistence

本文会介绍Redis持久化特性的实现机制,包括RDB的优缺点、AOF的优缺点,以及对选择RDB还是AOF做了分析,建议所有的Redis用户阅读。若想对Redis持久性有一个更广泛的认识,请参考文末第二篇参考链接。

1.Redis持久性方案

Redis提供了以下几种持久性方案供用户选择:

(1)RDB,实现在指定的时间间隔对数据集执行实时的快照备份。

(2)AOF,记录了Redis服务器接收到的每个写操作,这些写操作将在服务器启动时再次执行,以重新构建原始的数据集。当AOF文件太大时,Redis还能够在后台重构这个文件,达到缩小AOF文件的目的。

(3)禁用持久化功能,这样一来,你的数据只会在Redis服务器运行时存在。

(4)同时使用AOF和RDB。

选择何种持久性方案最重要的一点是,理解RDB和AOF持久化特性的优缺点。

2.RDB

Redis快照(snapshot)是最简单的持久化模式,每次快照都会生成一个包含整个数据集的文件。默认情况下,这个文件以dump.rdb命名。

(1)配置

使用RDB快照有两种方式:一种是直接使用SAVE或BGSAVE命令生成快照;另一种是在配置文件中配置。比如,每隔60秒后,如果至少有1000个key发生了变化,就生成一次快照,相应的在redis.conf中配置如下条目即可:

(2)机制

那么RDB是如何工作的呢?当RDB需要备份数据到磁盘时,会发生如下事情:

1)首先,Redis调用fork()函数生成一个子进程;
2)然后,子进程将数据写入临时的RDB文件中;
3)最后,用新的RDB文件替换掉旧的RDB文件。

(3)优点

RDB文件非常适合备份,比如,您可以在24小时内每隔一个小时就生成一个RDB文件,并将每天的RDB快照保存30天。这使得,当某些灾难事件导致您的数据损坏时,您可以轻松的通过RDB文件恢复到不同的版本。

RDB非常有利于灾难性恢复,因为将单个压缩文件传输给其他存储媒介很方便。

RDB能使Redis性能最大化,因为Redis父进程唯一要做的就是生成一个子进程,持久化工作全部交由子进程完成,父进程不会执行类似磁盘I/O操作。

与AOF相比,面对大型数据集,RDB能够更快速的启动。

(4)缺点

如果你想要在Redis停止工作后(比如异常断电),最小化数据丢失的可能,RDB不是一个很好的选择。您可以对RDB持久性策略进行配置,比如当配置为:在100次写操作之后,每隔5分钟生成一个快照。这意味着,RDB会在5分钟或更长时间生成一个.rdb文件,如果Redis服务异常关闭,那么我们可能会丢失最近几分钟内的数据!

RDB需要调用fork()函数生成子进程去完成持久化到磁盘的操作。然而,当数据集很大时,系统调用fork()是比较消耗资源的,也有可能会使Redis服务在短暂的时间内无法为客户端服务。虽然AOF也需要调用fork()函数,但是您可以调整希望重写日志的频率。

3.AOF

仅追加文件(Append Only File, AOF),是Redis另一种主要的完全持久策略。它的工作方式非常简单:每次执行写操作修改内存中数据集时,都会将其记录下来。在重新启动时,Redis重新执行所有操作,以重构数据集。

(1)配置

在配置文件中,打开AOF功能,如下所示:

(2)AOF重构

随着写操作不断的执行,AOF文件会越来越大。对此,AOF的重构机制可以缩小AOF文件。比如,我们将counter递增了100次,AOF中就会记录100次递增操作。然而,数据集当前状态中counter的有效值其实只有一个(即最后一次递增的结果),其他99个条目对构建数据集当前状态并不是必须的。

Redis支持了这一特性,使用BGREWRITEOF命令后,Redis就能够在后台重建AOF,而不会中断其服务。

需要注意的是:Redis2.2以前,我们需要时不时手动运行BGREWRITEOF命令。而在Redis2.4之后,Redis能够自动触发日志重构。

(3)持久性策略

您可以在redis.conf文件中修改AOF同步策略,有以下三种策略:

Redis建议每秒同步一次,既安全,又快速。

(4)AOF损坏

不排除追加AOF文件的时候,服务器崩溃导致AOF文件损坏的可能。如果真的发生了这种情况,您可以通过以下方法来修复:

1)备份当前的AOF文件;
2)使用redis-check-aof工具修复AOF文件;
3)使用diff –u命令验证两个AOF文件的差异;
4)重启Redis服务。

(5)优点

AOF更持久,它拥有几种同步策略:不需要同步、每秒同步、每次查询同步。默认是使用每秒同步一次。即使是每秒同步一次,AOF的性能仍然很高。如果异常宕机,也可能只是损失一秒钟的写操作。

AOF日志只能以追加模式记录,即使在对日志记录的过程中异常终止了(比如磁盘写满等原因),redis-check-aof工具也能够轻松地修复日志。

Redis可以在AOF太大的时候在后台重写AOF文件。即使是当Redis继续向旧的文件中追加记录时,重写AOF文件也是绝对安全的。当新的AOF重写完毕,Redis就会交换新旧AOF文件,并开始向新的AOF追加记录。

AOF以一种易于理解和解析的格式包含所有的操作日志。你甚至可以轻松地导出AOF文件。例如,即使您使用FLUSHALL命令对所有内容进行了刷新,您仍然可以恢复数据集,只需停止Redis服务器、删除最新命令并重新启动Redis。

(6)缺点

对于同一个数据集,AOF文件通常比RDB文件要大。

AOF可能比RDB要慢,这取决于确切的同步策略。

在过去,Redis的某些特定命令会产生一些罕见的bug,导致产生的AOF在重新加载时不能完全复制相同的数据集。这种错误很少见,但是这种错误对于RDB来说几乎是不可能的。因为,AOF的工作机制是渐进式更新一个现有的状态,而RDB快照可以一次次的创建所有的东西,这在概念上更加健壮。

4.RDB or AOF

一般的建议是:两者都使用。尤其是如果您希望获得与PostgreSQL所提供的数据安全性相当的安全性,那么就两者都使用吧。

如果您非常关心您的数据,但也能够忍受灾难发生时丢失几分钟的数据,那么您可以只使用RDB。

也有许多用户会单独使用AOF,但是Redis并不鼓励这样做。因为,RDB不时地快照存储功能对于数据库备份、快速重启和万一AOF引擎出现错误时,都是一个很好的备选策略。

需要注意的是:Redis小组表示,在未来的某个时候很可能会将AOF和RDB统一为一个持久性模型。

 

参考:
https://redis.io/topics/persistence
http://oldblog.antirez.com/post/redis-persistence-demystified.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注