redis++：Redis的两种持久化 RDB 和 AOF

Redis持久化备份数据的方式有两种：RDB(Redis DataBase) 、 AOF(Append Only  File).

RDB

什么是RDB：

　　在指定时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中，来达到恢复数据的。

如何持久化：

　　Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写进一个临时文件中，等到持久化过程结束了，再用这个临时文件替换上次持久化好的文件。

　　在这个过程中，只有子进程来负责IO操作，主进程仍然处理客户端的请求，这就确保了极高的性能。

Snapshot：

　　在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。

　　通过触发快照的形式，来做到将指定时间间隔内的数据持久化到dump.rdb。

　　例如，可以2分钟内持久化一次，将对数据库的写操作，备份到磁盘上的dump.rdb。

　　如何触发持久化呢？可以通过查看或者设置redis.conf配置文件来指定触发规则。

以下是redis配置文件的触发快照的默认配置 ：

RDB  优点与缺点

优点：

1、如果要进行大规模数据的恢复，RDB方式要比AOF方式恢复速度要快。
2、RDB可以最大化Redis性能，父进程做的就是fork子进程，然后继续接受客户端请求，让子进程负责持久化操作，父进程无需进行IO操作。
3、RDB是一个非常紧凑(compact)的文件,它保存了某个时间点的数据集，非常适合用作备份，同时也非常适合用作灾难性恢复，
  它只有一个文件，内容紧凑，通过备份原文件到本机外的其他主机上，一旦本机发生宕机，就能将备份文件复制到redis安装目录下，通过启用服务就能完成数据的恢复。

缺点：

1、DB这种持久化方式不太适应对数据完整性要求严格的情况，因为，尽管我们可以用过修改快照实现持久化的频率，但是要持久化的数据是一段时间内的整个数据集的状态，
   如果在还没有触发快照时，本机就宕机了，那么对数据库所做的写操作就随之而消失了并没有持久化本地dump.rdb文件中。
2、每次进行RDB时，父进程都会fork一个子进程，由子进程来进行实际的持久化操作，如果数据集庞大，那么fork出子进程的这个过程将是非常耗时的，
   就会出现服务器暂停客户端请求，将内存中的数据复制一份给子进程，让子进程进行持久化操作。

AOF

什么是AOF：

　　以日志的形式记录Redis每一个写操作,将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件，

　　redis启动之后会读取appendonly.aof文件来实现重新恢复数据，完成恢复数据的工作。

　　默认不开启，需要将redis.conf中的appendonly  no改为yes启动Redis。

持久化：

Redis的AOF是如何做到持久化的呢？从配置文件中，我们可以发现

appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。

数据恢复：

　　重启Redis时，如果dump.rdb与appendfsync.aof同时都存在时，Redis会自动读取appendfsync.aof文件，通过该文件中对数据库的日志操作，来实现数据的恢复。

　　当然如果该文件被破坏，我们可以通过redis-check-aof工具来修复，如redis-check-aof --fix能修复破损的appendfsync.aof文件，

　　当然如果dump.rdb文件有破损，我们也可以用redis-check-rdb工具来修复，如果appendfsync.aof文件破损了，是启动不客户端的，也就是无法完成数据的恢复。

重写：

　　当然如果AOF 文件一直被追加，这就可能导致AOF文件过于庞大。

　　因此，为了避免这种状况，Redis新增了重写机制，当AOF文件的大小超过所指定的阈值时，Redis会自动启用AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewiteaof。

重写原理：

　　AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是临时文件最后再rename）,

　　遍历新进程的内存中的数据，每条记录都会有一条set语句，重写aof文件的操作，

　　并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，有点类似于快照。

触发机制：

　　Redis会记录上一次重写时的AOF大小，默认配置是当AOF文件大小是上一次的一倍并且大于64m时，会触发从写机制。

配置文件：

优点：

1、AOF有着多种持久化策略：

　　appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

　　appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

　　appendfsync no:不同步。

2、AOF文件是一个只进行追加操作的日志文件，对文件写入不需要进行seek，即使在追加的过程中，写入了不完整的命令（例如：磁盘已满），可以使用redis-check-aof工具可以修复这种问题

3、Redis可以在AOF文件变得过大时，会自动地在后台对AOF进行重写：重写后的新的AOF文件包含了恢复当前数据集所需的最小命令集合。

　　整个重写操作是绝对安全的，因为Redis在创建AOF文件的过程中，会继续将命令追加到现有的AOF文件中，即使在重写的过程中发生宕机，现有的AOF文件也不会丢失。

　　一旦新AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并对新的AOF文件进行追加操作。

4、AOF文件有序地保存了对数据库执行的所有写入操作。这些写入操作一Redis协议的格式保存，易于对文件进行分析；

　　例如，如果不小心执行了FLUSHALL命令，但只要AOF文件未被重写，通过停止服务器，移除AOF文件末尾的FLUSHALL命令，重启服务器就能达到FLUSHALL执行之前的状态。

缺点：

1、对于相同的数据集来说，AOF文件要比RDB文件大。

2、根据所使用的持久化策略来说，AOF的速度要慢与RDB。

　　一般情况下，每秒同步策略效果较好。

　　不使用同步策略的情况下，AOF与RDB速度一样快。

RDB与AOF如何选择：

1、一般来说，如果想达到足以媲美PostgreSQL的数据安全性，应该同时使用两种持久化方式。

2、有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，

　　并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。

3、如果可以承受输分钟内的数据丢失，可以只使用RDB持久化。