Redis支持两种数据的持久化方式，分别是RDB和AOF，并且支持两种方式共存。

RDB

全称：Redis DataBase

持久化策略：指在指定的时间间隔内将内存中的数据集快照写入磁盘，即Snapshot快照，它恢复时是将快照文件直接读到内存里。

做法：Redis单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（rename）。

fork的作用：复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

RDB的save命令：

RDB持久化默认保存的是dump.rdb文件，路径于Redis的安装目录一致，通过save或bgsave命令配置触发规则。

使用save命令时只管保存，其他命令均阻塞

使用bgsave时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求

redis.conf配置：

#redis.conf配置文件的三种策略，关闭则配置 save ""
#当900秒内出现一次key的变化
save 900 1
#当300秒内出现10次key的变化
save 300 10
#当60秒内出现10000次key的变化
save 60 10000

恢复：可以通过定时备份dump.rdb文件到其他目录，当redis故障时，将备份文件 dump.rdb 移动到 Redis 安装目录并启动服务即可。

优势：适合大规模的数据恢复，对数据完整性和一致性要求不高的数据。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，RDB方式要比AOF方式更加的高效。

劣势：RDB是在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，而且Fork子进程备份时，内存中的数据被克隆了一份，所以需要有2倍的硬盘空间

RDB的特点：

1、RDB是非常紧凑的文件

2、需要经常fork子进程来保存数据到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级别不能响应客户端请求

3、RDB适合做冷备

AOF

全称：Append Only File

持久化策略：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。

redis.conf配置：

AOF持久化默认保存的是appendonly.aof文件，路径与Redis的安装目录一致，需要通过配置才能开启#redis.conf中的AOF持久化开关appendonly yes#可以配置重写的百分比及文件大小auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb#指定更新日志条件，共有3个可选值：#no：表示等操作系统进行数据缓存同步到磁盘（快） #always：同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好 #everysec：异步操作，每秒记录一次，如果一秒内宕机，有数据丢失appendfsync everysec 过程：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。

为了解决 AOF 文件体积膨胀的问题，Redis 提供了文件重写（rewrite）功能，重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和快照有点类似（aof可以放到fork子进程来重写，这样不会阻塞主进程的CRUD）

AOF特点：

1、AOF文件是一个只进行追加的日志文件

2、Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写

3、AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松

4、对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积

5、根据所使用的fsync策略，AOF的速度可能会慢于RDB

6、相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB，AOF运行效率要慢于RDB,每秒同步策略效率较好，不同步效率和RDB相同。

7、RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启

8、AOF适合做热备

两种持久化的配置常见做法

1、可以同时开启RDB AOF，如果同时开启两种持久化方式，当Redis重启的时候会优先载入AOF文件来恢复原始的数据

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

3、Enable AOF，启动脚本较简单只加载自己的AOF文件就可以了，代价：持续的IO，AOF重写的最后将重写过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

3、只要硬盘许可，应该尽量减少AOF重写的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

4、如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。

优点：省掉一大笔IO、减少了重写时带来的系统波动。

代价：如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

5、如果Redis仅做缓存，那RDB AOF都可以关闭，这样最高效。

6、为了解决AOF文件太大问题，可以开启混合持久化。

开启混合持久化 aof-use-rdb-preamble yes 用将 RDB 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。