redis(三)：redis的两种持久化方式（RDB与AOF）

一、前言

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。

redis提供两种方式进行持久化

RDB方式：将Reids在内存中的数据定时进行快照并持久到磁盘上。它是redis默认采用的持久化方式。
AOF方式：将Reids的操作命令以追加的方式写入文件，当服务器重启的时候会重新执行这些命令来恢复原始的数据

二、RDB方式

1、RDB介绍

在Redis中RDB持久化的触发分为两种：

自己手动触发；
根据你所配置的配置文件的策略，达到策略的某些条件时来自动持久化数据；

（1）手动触发可以使用两种方式：

save：在Redis主线程中工作，因此会阻塞其他请求操作，应禁止使用。
bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

（2）根据配置文件的策略自动触发：

实际上它和bgsave命令持久化原理是相同的。具体配置如下：

RDB持久化条件

以下是redis配置文件的默认配置

save 900 1   #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10    #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000  #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。

默认情况下，会持久化到dump.rdb文件，并且在redis重启后，自动读取其中文件。据悉，通常情况下一千万的字符串类型键，1GB的快照文件，同步到内存中的时间是20-30秒。

配置dir指定rdb快照文件的位置

# Note that you must specify a directory here, not a file name.
dir ./

配置dbfilename指定rdb快照文件的名称

# The filename where to dump the DB
dbfilename dump.rdb

2、RDB工作原理

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

注意事项
1.redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。
2.这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份， RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

3、RDB优缺点：

缺点：使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化
优点： RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无序执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；

三、AOF方式

1、AOF介绍

默认情况下Redis没有开启AOF（append only file）方式的持久化
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。
可以通过修改redis.conf配置文件中的appendonly参数开启

appendonly yes

AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。

dir ./

默认的文件名是appendonly.aof，可以通过appendfilename参数修改：

appendfilename appendonly.aof

2、AOF工作原理

Redis每次更改数据的时候， aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件。

三种方式如下：

appendfsync always #每次执行写入都会进行同步，这个是最安全但是是效率比较低的方式。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

3、AOF重写原理（优化AOF文件）

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。

参数说明：
#auto-aof-rewrite-percentage 100 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准。
#auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化。

4、AOF文件损坏以后如何修复

服务器可能在程序正在对 AOF 文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么 Redis 在重启时会拒绝载入这个 AOF 文件，从而确保数据的一致性不会被破坏。

当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：

1.为现有的 AOF 文件创建一个备份。
2.使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
redis-check-aof --fix readonly.aof
3.重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

四、从持久化中恢复数据

数据的备份、持久化完成后，如何从这些持久化文件中恢复数据呢？如果一台服务器上有既有RDB文件，又有AOF文件，优先加载谁呢？

其实想要从这些文件中恢复数据，只需要重新启动Redis即可。流程如下：
在这里插入图片描述
启动时会先检查AOF文件是否存在，如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。

五、如何选择RDB和AOF

一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化，但并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。
两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话，那么Redis重启时，会优先使用AOF文件来还原数据。