Redis 提供了2个不同形式的持久化方式。

RDB （Redis DataBase）
AOF （Append Of File）

一、RDB （Redis DataBase）

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

1.Redis的RDB备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的那一批数据可能丢失。

2.Redis的RDB关于fork

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”，一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

3.Redis的RDB的保存的文件

在redis.conf中配置文件名称，默认为dump.rdb
rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

4.Redis的RDB的保存策略

save 900 1    900 秒内如果至少有 1 个 key 的值变化，则保存
save 300   10   300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000  60 秒内如果至10000 个 key 的值变化，则保存

5.Redis的RDB的优缺点

1）rdb的优点

1. 节省磁盘空间
2. 恢复速度快

2）rdb的缺点

1. 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
2. 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

二、AOF （Append Of File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

1.Redis的AOF的保存策略

1）appendfsync always：

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

2）appendfsync everysec：

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。

3）appendfsync no：

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

2.Redis的AOF的优缺点

1）AOF的优点

1. 备份机制更稳健，丢失数据概率更低。
2. 可读的日志文本，通过操作AOF稳健，可以处理误操作。

2）AOF的缺点

1. 比起RDB占用更多的磁盘空间。
2. 恢复备份速度要慢。
3. 每次读写都同步的话，有一定的性能压力。
4. 存在个别Bug，造成不能恢复。

三、Redis的AOF和RDB同时开启

AOF和RDB同时开启，系统默认取AOF的数据

四、Redis持久化方式用哪个好

1. 官方推荐两个都启用。
2. 如果对数据不敏感，可以选单独用RDB。
3. 不建议单独用 AOF，因为可能会出现Bug。
4. 如果只是做纯内存缓存，可以都不用。