Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

RDB（Redis DataBase）

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

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

关闭rdb：

bash 复制代码

save ""
 
#   save 900 1
#   save 300 10
#   save 60 10000

或者redis-cli命令：config set save ""

开启aof：

appendonly yes

或者redis-cli命令：config set appendonly yes

Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。 Rdb 保存的是 dump.rdb 文件

这里的触发条件机制，我们可以修改测试一下：

复制代码

save 120 10

如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。若要修改完毕需要立马生效，可以手动使用 save 命令！立马生效 !

优缺点

优点：

1、适合大规模的数据恢复

2、对数据完整性和一致性要求不高

缺点：

1、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

2、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

AOF（Append Only File）

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

Aof保存的是 appendonly.aof 文件

默认是不开启的，我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof !

操作：

改配置文件
重启
增加键值对
完成

如果aof文件大于64m，太大了! fork一个新的进程来将我们的文件进行重写!

优点和缺点!

优点:

1、每一次修改都同步，文件的完整会更加好!

2、每秒同步一次，可能会丢失一秒的数据

3、从不同步，效率最高的!

缺点︰

1、相对于数据文件来说，aof远远大于rdb，修复的速度也比 rdb慢!

2、Aof运行效率也要比rdb 慢，所以我们redis默认的配置就是rdb持久化! |

混合持久化

Redis混合持久化结合了RDB和AOF持久化的优点，具体好处如下：

混合持久化可以减少AOF文件的大小，加快数据恢复的速度，避免数据丢失。
混合持久化结合了RDB和AOF的优点，既可以保证数据的快速恢复，又可以保证数据的完整性和一致性。

请注意，如果RDB部分或AOF部分损坏或丢失，那么整个AOF文件将无法恢复数据或只能恢复部分数据。在使用混合持久化时，需要定期备份AOF文件，以防止数据丢失。

数据丢失问题

一般来说，如果同时开启 aof 和 rdb 持久化方式，出现数据丢失的可能性是非常小的。

因为 rdb 持久化方式会将 Redis 在内存中的数据定期进行快照备份，而 aof 持久化方式则会记录 Redis 所有的写命令，两种持久化方式的作用是互补的。

如果同时开启 aof 和 rdb，当 Redis 重启时，首先会使用 rdb 文件来还原内存数据，然后再回放 aof 文件中未被执行过的写命令，确保 Redis 重启后的数据与宕机前的数据一致。

当然，如果在 Redis 重启前，最后一次备份 rdb 文件和最后一条 aof 记录之间出现了宕机，就可能会出现数据丢失的情况，但这种情况是非常少见的。

参考文章

b站狂神说redis视频

redis 持久化