• rdb（redis database）
• aof（append only file）

rdb

指定时间间隔内将内存中的数据集快照写入磁盘，即snapshot快照，恢复时是将快照文件直接读到内存中
redis会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件中，等持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
这个过程中主进程的写操作会在一个临时文件中记录。
如果进行大规模数据恢复，对数据恢复完整性不是非常敏感，那RDB方式要比AOF方式更加高效。
缺点：最后一次持久化的数据可能丢失

fork

创建一个与当前进程一样的进程，新进程与原进程的所有数据（变量、环境变量、程序计数器）完全一样

保存的文件

dump.rdb

配置位置

conf文件的SNAPSHOTING位置

保存快照

1. save命令：只管保存，全部阻塞
2. bgsave命令：后台异步进行快照操作

恢复

将备份文件移动到redis安装目录并启动服务即可

优势

适合大规模时间恢复
对数据完整性和一致性要求不高

劣势

如果意外down的话，最后一次快照的就会丢失
拷贝的适合会产生两倍的膨胀内存

关闭rdb

redis-cli config set save "" <br />

AOF

以日志的形式记录每个写操作。
只许追加而不允许改写文件
将写入操作的命令统统记录，恢复的适合重新操作一遍

注意：开启AOP会自动关闭rdb

检查aof记录文件

redis-check-aof

rewrite

超过设定的阈值，redis就会启动aof文件的内容压缩。
—》 bgrewriteaof
原理：再fork一个新线程进行rewrite
机制：redis记录上次重写时的AOF大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64mb时触发（3G）
**

使用建议

建议RDB 和 AOF同时开启，但是这时候会优先使用AOF，到那时RDB可以用来保存数据库进行快速恢复。

RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了。只保留save 900 1 这条规则。

如果开启AOF，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是rewrite的最后将rewrite过程中产生的新数据写到新文件的阻塞不可避免。

尽量减少rewrite频率，AOF重写的基础大小为64M太小，可以设到5G以上，默认超过原大小100%大小时重写也可以调到适当数值。

如果只采用RDB，代价是会丢失十几分钟的数据，启动时也要比较master和slave中rdb文件哪个新。