持久化

首先我们说下什么是持久化，持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）。另外我们使用的 Redis 之所以快就是因为数据都存储在内存当中，为了保证在服务器出现异常过后还能恢复数据，所以就有了 Redis 的持久化。

RDB 和 AOF

前面说了什么是持久化，现在说说 Redis 的持久化，众所周知 Redis 的持久化有两种方式，一种是快照形式 RDB，另一种是增量文件 AOF。

RDB

RDB 持久化方式是会在一个特定的时间间隔里面保存某个时间点的数据快照，我们拿到这个数据快照过后就可以根据这个快照完整的复制出数据。这种方式我们可以用来备份数据，把快照文件备份起来，传送到其他服务器就可以直接恢复数据。但是这只是某个时间点的全部数据，如果我们想要最新的数据，就只能定期的去生成快照文件。

RDB 的实现主要是通过创建一个子进程来实现 RDB 文件的快照生成，通过子进程来实现备份功能，不会影响主进程的性能。同时上面也提到 RDB 的快照文件是保存一定时间间隔的数据的，这就会导致如果时间间隔过长，服务器出现异常还没来得及生成快照的时候就会丢失这个间隔时间的所有数据；那有同学就会说，我们可以把时间间隔设置的短一点，适当的缩短是可以的，但是如果间隔时间段设置短一点频繁的生成快照对系统还是会有影响的，特别是在数据量大的情况下，高性能的环境下是不允许这种情况出现的。

我们可以在 redis.conf 进行 RDB 的相关配置，配置生成快照的策略，以及日志文件的路径和名称。还有定时备份规则，如下图所示，里面的注释写的很清楚，简单说就是在多少时间以内多少个 key 变化了就会触发快照。如save 300 10 表示在 5 分钟内如果有 10 个 key 发生了变化就会触发生产快照，其他的同理。

面试官：说下 Redis 是如何保证在宕机后数据不丢失的

除了我们在配置文件中配置自动生成快照文件之外，Redis 本身提供了相关的命令可以让我们手动生成快照文件，分别是 SAVE 和 BGSAVE ，这两个命令功能相同但是方式和效果不一样，SAVE 命令执行完后阻塞服务器进程，阻塞过后服务器就不能处理任何请求，所以在生产上不能用，和SAVE 命令直接阻塞服务器进程的做法不同，BGSAVE 命令是生成一个子进程，通过子进程来创建 RDB 文件，主进程依旧可以处理接受到的命令，从而不会阻塞服务器，在生产上可以使用。

在这里测试一下自动生成快照，我们修改一下快照的生成策略为save 10 2，然后在本地启动Redis 服务，并用 redis-cli 链接进入，依次步骤如下

1. 修改配置，如下
2. 启动 Redis 服务，我们可以从启动日志中看到，默认是会先读取 RDB 文件进行恢复的
3. 链接 Redis 服务，并在 10s 内设置 3 个 key
4. 这个时候我们会看到 Redis 的日志里面会输出下面内容，因为触发了规则，所以开启子进程进行数据备份，同时在对应的文件路径下面，我们也看到了 rdb 文件。

面试官：说下 Redis 是如何保证在宕机后数据不丢失的

从上面可以看出，我们配置的规则生效了，也成功的生成了 RDB 文件， 后续在服务器出现异常的情况，只要重新启动就会读取对应的 RDB 文件进行数据备份。

AOF

AOF 是一种追加执行命令的形式，它跟 RDB 的区别是，AOF 并不是把数据保存下来，而是保存执行的动作。在开启 AOF 功能的时候，客户端连接后执行的每一条命令都会被记录下来。这其实让阿粉想起来的 MySQL 的 binlog 日志，也是记录操作的命令，后续可以根据文件去恢复数据。

AOF 是追加命令格式的文件，同样的我们可以定义多长时间把数据同步一次，Redis 本身提供了三种策略来实现命令的同步，分别是不进行同步，每秒同步一次，以及当有查询的时候同步一次。默认的策略也是使用最多的策略就是每秒同步一次，这样我们可以知道，丢失的数据最多也就只有一秒钟的数据。有了这种机制，AOF 会比 RDB 可靠很多，但是因为文件里面存在的是执行的命令，所以AOF 的文件一般也会比 RDB 的文件大点。

Redis 的 AOF 功能，默认是没有开启的，我们可以通过在配置文件中配置appendonly yes是功能开启，同时配置同步策略appendfsync everysec 开启每秒钟同步一次，我们拿到 AOF 文件过后，可以根据这个文件恢复数据。

同样的我们在redis.conf 中可以看到默认是没有开启 AOF 功能的，并且我们也可以指定对应的文件名称和路径。

面试官：说下 Redis 是如何保证在宕机后数据不丢失的

接下来，我们测试一下开启 AOF 功能，先修改配置然后重启 Redis 的服务器，我们会发现已经没有读取 RDB 文件的日志了，并且在日志文件路径下面已经生成了一个 aof 文件。需要注意的是，因为我们重启的服务，并且开启了 AOF，所以现在 Redis 服务器里面并没有我们之前添加的数据（说明什么问题呢？）。

面试官：说下 Redis 是如何保证在宕机后数据不丢失的 面试官：说下 Redis 是如何保证在宕机后数据不丢失的

接下来我们使用客户端连接进入，设置如下值，接下来我们可以看看 aof 文件里面的内容

面试官：说下 Redis 是如何保证在宕机后数据不丢失的 面试官：说下 Redis 是如何保证在宕机后数据不丢失的

我们可以看到aof 文件里面的内容就是执行的命令，只不过是以一种固定的格式存储的，我们在备份的时候如果不需要哪些数据，可以手动删掉对应的命令就可以重新备份数据。

文件载入顺序

上面我们提到了Redis 的两种持久化方案，并且两种方案都会生成对应的文件，那 Redis 在恢复数据的时候是怎么载入文件的呢？并且在两个文件都存在的情况下，会以哪个为准呢？

通过上面的测试，其实我们可以看出 Redis 是以 AOF 为优先的，毕竟 AOF 相对 RDB 来说在出现异常的情况下保存的数据更加完整。