Redis的持久化

文章

林里克斯

Redis的持久化详解

Redis支持两种方式的持久化，一种是RDB方式;另一种是AOF方式。前者将会根据指定的规则“定时”将内存中的数据存储在硬盘里，而后者在每次执行命令后将命令本身记录下来，两种持久化方式可以单独使用其中一种，但更多情况下是将二者一起结合使用。

1.RDB方式
2.快照原理
3.AOF方式

1.RDB方式

RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时redis会自动将内存中的所有数据生成一份副本并存储在硬盘上，这个过程称为“快照”。

redis会在以下几种情况下对数据进行快照备份：

(1).根据配置规则进行自动快照；
(2).用户执行SAVE或BGSAVE命令；
(3).执行FLUSHALL命令；
(4).执行复制(reolication)时；

（ 1 ）redis允许用户自定义快照条件，当符合快照条件时，redis会自动执行快照操作。进行快照的条件可以由用户在配置文件配置自定义，主要有两个参数构成：时间窗口M和改动的建的个数N。每当时间M内被更改的键的个数大于N时，既符合自动快照条件。

例如redis默认配置文件中三个条件：

save 900 1
save 300 10
save 60 10000

每条快照条件占一行，并且以save参数开头。同时可以存在多个条件，条件之间是“或”的关系。就这个例子而言，save 900 1的意思是在15分钟(900秒)内有一个或一个以上的键被更改则进行快照。同理，save 300 10表示在5分钟（300秒）内至少有10个键被修改则进行快照。

（ 2 ）除了让redis自动进行快照外，当服务进行重启、手动迁移以及备份时我们也会需要手动执行快照。redis提供了两个命令来完成这一任务。

SAVE命令和LASTSAVE

当执行SAVE命令时，redis同步地进行快照操作，在快照执行的过程中会阻塞所有来自客服端的请求。当数据库中的数据比较多时，这一过程会导致redis长时间不响应，所以要避免在生产环境中使用这一命令。需要手动执行快照时推荐使用BGSAVE命令。BGSAVE命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应来自客服端的请求。执行BGSAVE后redis会立即返回OK表示开始执行快照操作，如果想知道快照是否完成，可以通过LASTSAVE命令来获取最后一次成功执行快照的时间，返回结果是一个Unix时间戳。

eg： redis> LASTSAVE
(integer) 1497881164

恢复数据：如果需要恢复数据，只需将命令保存的dump.rbd文件移动到redis安装目录并启动服务即可。

（ 3 ）当执行FLUSHALL命令时，redis会清楚数据库中的所有数据。需要注意的是，不论清空数据库的过程是否触发了自动快照条件，只要自动快照条件不为空，redis就会执行一次快照操作。例如，当定义的快照条件为当1秒内修改10000个键时进行自动快照，而当数据库里只有一个键时，执行FLUSHALL命令也会触发快照，即使这一过程实际上只有一个键被修改了。当没有定义自动快照条件时，执行FLUSHALL则不会镜像快照。

（ 4 ）当设置了主从模式是，redis会在复制初始化时进行自动快照。即使没有定义自动快照条件，并且没有手动执行过快照操作，也会生产RBD快照文件。

2.快照原理

redis默认会将快照文件存储在redis当前进程的工作目录中的dump.rdb文件中，可以通过配置文件(redis.conf)的dir和dbfilename两个参数分别指定快照文件的存储路径和文件吗。

(1)redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
(2)父进程继续接收并处理客服端发来的命令，而子进程开始将内存中的数据写入硬盘的临时文件；
(3)当子进程写入完所有数据后会用改临时文件替换旧的RDB文件，至此一次快照操作完成。

通过上诉过程可以发现redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实现redis数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录1000万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20~30秒。

通过RDB方式实现持久化，一旦redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。例如，使用redis存储缓存数据时，丢失最近几秒的数据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

3.AOF方式

当使用redis存储非临时数据时，一般需要打开AOF持久化来降低进程中止导致的数据丢失。AOF可以将redis执行的每一条写命令追加到硬盘文件中，这一过程显然会降低redis的性能，但是大部分情况下这个影响是可以接受的，另外使用较快的硬盘可以提高AOF的性能

（ 1 ）开启AOF默认情况下redis没有开启AOF(append only file)方式的持久化，可以通过配置文件(redis.conf)appendonly参数启用 appendonly yes开启AOF持久化后每执行一条会更改redis中的数据的命令，redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过配置文件(redis.conf)的dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改： appendfilename appendonly.aof

（ 2 ）AOF的实现AOF文件以纯文本的形式记录了redis执行的写命令，例如在开启AOF持久化的情况下执行了如下三个命令：

SET jarbo 1
SET jarbo 2
GET jarbo

redis会将前2条命令写入AOF文件中，此时AOF文件中的内容如下：

*2
$6
SELECT
$1
0
*3
$3
set
$3
jarbo
$1
*3
$3
set
$3
jarbo
$1
2

可见AOF文件的内容正是redis客服端向redis发送的原始通信协议的内容，从中可见redis确实只记录了前2条命令。然而这时有一个问题是第1条命令其实是冗余的，因为这条命令的执行结果会被第2条命令覆盖。随着执行的命令越来越多，AOF文件的大小也会越来越大，即使内存中实际数据可能并没有多少。很自然地，我们希望redis可以自动优化AOF文件，就上例而言，就是第1条无用的记录删除掉，只保留有用的那一条。实际上redis也正是这样做的，每当达到一定条件时redis就会自动重写AOF文件，这个条件可以在配置文件(redis.conf)中设置：

no-appendfsync-on-rewrite  yes      # 正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 10000   #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb      #aof文件,至少超过64M时,重写

auto-aof-rewrite-percentage参数的意思是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据。
auto-aof-rewrite-min-size参数限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余我们也并不太关心。除了让redis自动执行重写外，我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。

上例中的AOF文件重写后的内容为：

*2
$6
SELECT
$1
0
*3
$3
SET
$3
jarbo
$1
2

可见冗余的命令已经被删除了。重写的过程只和内存中的数据有关，和之前的AOF文件无关，这与RDB很相似，只不过二者的文件格式完全不同。在启动时redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些。

（ 3 ）同步硬盘数据虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用都无法容忍这样的损失，这就需要redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在redis中我们可以通过appendfsync参数设置同步的实际：

#appendfsync always
appendfsync everysec
#appendfsync no

默认情况下redis采用everysec规则，即每秒执行一次同步操作。always表示每次执行写入都会执行同步，这是最安全也是最慢的方式。no表示不主动进行同步操作，二十完全交由操作系统来做（即每30秒一次），这是最快但最不安全的方式。一般情况下使用默认值everysec就足够了，即兼顾了性能有保证了安全。 redis允许同时开启RDB和AOF，即保证了数据安全又使得进行备份等操作十分容易。此时重新启动redis和redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。