Redis持久化

redis在使用的过程中，如果碰到系统宕机的情况该怎么处理呢？如果redis保存的是需要恢复的数据，这时候我们就需要使用redis的持久化的选项，redis有将数据定期持久化到硬盘的能力。

redis持久化有两种方案：RDB和AOF

RDB方式

RDB持久化方式能够在制定的时间间隔对你的数据进行快照存储,这也是Redis默认的持久化方式，这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。
可以在redis.conf中调整save配置选项，当在规定的时间内，Redis发生了写操作的个数满足条件会出发发生BGSAVE命令。
#300秒之内至少发生10次写操作
save 300 10

RDB文件保存过程

客户端直接通过命令BGSAVE或者SAVE来创建一个内存快照。
BGSAVE调用fork来创建一个子进程，子进程负责将快照写入磁盘，而父进程仍然继续处理命令。
SAVE齿形SAVE命令过程中，不再响应其他命令。

RDB的优点：

1.对性能影响最小
2.RDB文件进行数据恢复比使用AOF要快很多

RDB的缺点：

1.同步时丢失数据
2.如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。

AOF方式

AOF文件保存过程

redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof）
当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os的原因，可能不是立即写到磁盘上。这样AOF的持久化也还是有可能会丢失部分修改。不过我们可以配置文件告诉redis我们想通过fsync函数强制OS写到磁盘的时机，有三种方式（默认是每秒fsync一次）：
#每次有数据修改发生时都会写入AOF文件
appendfsync always
#每秒钟同步一次，该策略为AOF的缺省策略
appendfsync everysec
#从不同步，高效但是数据不会被持久化
appendfsync no

开启AOF持久化
appendonly yes

AOF的方式也带来了另一个问题：持久化文件会变得越来越大。例如调用incr test命令100次，文件必须保存全部100条命令，其实99条是多余的。因为要恢复数据库状态只需要一条set test 100即可。
为了压缩AOF的持久化文件，redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。过程如下：
1.redis调用fork,有父子两个进程
2.子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3.父进程继续处理client请求，除了把写命令写入到原来的AOF文件中，同时把收到的写命令缓存起来，这样子进程重写失败的话也不会出问题。
4.当子进程吧快照内容写入已命令方式写到临时文件中，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5.父进程可以使用临时文件替换老的AOF文件，并重命名，后面收到的写命令也开始往新的AOF文件中追加。
需要注意的是重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这和快照有点类似。

AOF方式的优点：

1.安全
2.容灾
3、容易读，可修改

AOF方式的缺点：

1.文件体积大
2.性能消耗比RDB高
3.数据恢复速度比RDB慢

从上边来看，如果可以承受几分钟以内的数据的损失，可以可以使用RDB持久化，如果要尽可能数据的安全性，应该选择AOF。