我们都知道 Redis 的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。

Redis 有两种持久化方案，RDB (Redis DataBase)和 AOF (Append Only File)。

RDB(Redis DataBase) 详解

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

RDB (Redis DataBase)的优缺点

优点：

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

2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件(此时内存中的数据是原来的两倍)，最后再将临时文件替换之前的备份文件。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

1.Redis服务端接受到BGSAVE命令。

2.Redis服务端通过fork()来生成一个名叫redis-rdb-bgsave的进程，由redis-rdb-bgsave子进程来创建RDB文件，而Redis主进程则继续处理客户端的命令请求。

3.当redis-rdb-bgsave子进程创建完成RDB文件，会向Redis主进程发送一个信号，告知Redis主进程RDB文件已经创建完毕，然后redis-rdb-bgsave子进程退出。

4.Redis服务器(父进程)接手子进程创建的RDB文件，BGSAVE命令执行完毕。

Redis主进程因为创建子进程，会消耗额外的内存。

需要注意的是：如果在Redis主进程fork子进程的过程中花费的时间过多，Redis仍然可能会阻塞。

BGSAVE是一个异步命令，Redis客户端向Redis服务端发送BGSAVE命令后会立即得到回复，而实际的操作在Redis服务端回复之后才开始。

AOF(Append Only File) 详解

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性)，所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF(Append Only File) 的优缺点

优点：数据的完整性和一致性更高。

缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志的性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

总 结

1. Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。

2. RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

3. Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

4. AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

5. Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

6. 若只打算用Redis 做缓存，可以关闭持久化。

7. 若打算使用Redis 的持久化。建议RDB和AOF都开启(混合持久化)。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

官方链接：

Redis Persistence

https://redis.io/topics/persistence