redis持久化——RDB与AOF

一、持久化简介

Redis 的数据 全部存储 在 内存 中，如果 突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘 中。

方式一：RDB

RDB：快照方式，允许你每隔一段时间对内存数据做一次快照然后存储到硬盘中。该方式是Redis默认的持久化方式。

RDB可以通过在配置文件中配置时间或者改动键的个数来定义快照条件，编辑配置文件redis.conf，找到

save 900 1  #15分钟之内至少有一个建被更改则进行快照
save 300 10  #5分钟之内至少有10个建被更改则进行快照
save 60 10000  #1分钟之内至少有1000个建被更改则进行快照

他们之间是或的关系，RDB持久化到磁盘的文件默认路径是在当前目录，文件名为dump.rdb，你可以通过配置文件配置dir和dbfilename来指定文件目录和文件名称，RDB文件还可以进行压缩，你可以通过配置rdbcompression参数来进行压缩。
RDB快照过程：
1、Redis使用fork函数复制一份当前的父进程作为子进程
2、父进程继续处理用户的请求，子进程开始把内存中的数据持久化到磁盘上
3、当子进程把内存中的数据写入到临时文件完成之后，会把该临时文件替换掉旧的RDB文件。

RDB优点：RDB文件内容紧凑，文件小（比AOF文件小）非常适合于灾难恢复，而且能最大程度的使用Redis性能，因为Redis主程序可以fork一个子进程来单独处理RDB持久化，而Redis主进程毋须参与这个过程，另外相对于AOF的数据恢复，RDB数据恢复比AOF快得多。

RDB缺点：由于RDB是间隔一段时间进行快照持久化，那么有可能就在系统发生故障的时候，你就会丢失这段时间内的数据。另外由于RDB在处理持久化数据的时候，有可能就是在数据量庞大的时候，fork出的子进程会非常耗时，如果系统在这时候发生故障，那么你就会丢失这段时间的数据。

方式二：AOF

AOF：通过将发送到服务器的写操作命令记录下来，形成AOF文件，文件默认名称是appendonly.aof，可以通过appendfilename来指定文件名称。你可以通过配置文件打开AOF功能

appendonly yes

AOF的原理是直接把用户插入到服务器的命令追加到结尾，那么文件会原来越大，一些重复的写命令也会越来越多，这时，我们可以利用BGREWRITEAOF 命令来重写AOF，重写的配置如下：

auto-aof-rewrite-percentage 100 #aof文件大小超过上次重写时文件大小的百分之几开始重写，如果之前没有写过，则根据启动时文件大小。

auto-aof-rewrite-min-size 64mb #限制允许重写时的最小文件大小。

AOF在同步内存数据到磁盘上时，并不是马上把文件写如到磁盘中，而是先把文件缓存到系统，然后每隔30秒将文件写入到磁盘中，我们可以在配置文件中配置同步的策略

appendfsync always #每次都同步，保证数据不会丢失，但会慢
appendfsync everysec #每秒同步，系统默认同步策略
appendfsync no #不主动同步，由操作系统决定，快，但数据容易丢失

AOF同步过程：
1、Redis 执行 fork() ，现在同时拥有父进程和子进程。
2、子进程开始将新 AOF 文件的内容写入到临时文件。
3、对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
4、当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
5、搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。