Redis作为一款内存数据库，被广泛使用于缓存，分布式锁等场景，那么假如断电或者因其他因素导致Reids服务宕机，在重启之后数据会丢失吗？

Redis虽然是定义为一个内存数据库，但是其也支持数据的持久化，在Redis中提供了两种持久化机制：RDB持久化和AOF持久化。

RDB全称为：

Redis DataBase，是Redis当中默认的持久化方案。当触发持久化条件时，Redis默认会生成一个dump.rdb文件，Redis在重启的时候就会通过解析dump.rdb文件进行数据恢复。

RDB持久化机制有两种触发方式：自动触发和手动触发。

自动触发

自动触发方式也可以分为三种：

1.执行flushall命令（flushdb 命令不会触发）时，不过此时生成的 dump文件内的数据是空的（dump 文件还会存储一些头信息，所以文件本身是有内容的，只是没有数据），没有什么太大的实际意义。

2.执行shutdown命令时会触发生成dump文件。

3.通过配置文件自动生成，Redis中配置文件默认配置如下，只要达到这三个条件中的任意一个，就会触发Redis的RDB 持久化机制。

手动触发

除了自动触发，Redis中还提供了2个手动触发RDB机制的命令（这两个命令不能同时被执行，一旦一个命令正在执行中，另一个命令会被拒绝执行）：

1.save

这个命令会阻塞Redis服务器进程，直到成功创建RDB文件，也就是说在生成RDB文件之前，服务器不能处理客户端发送的任何命令。

2.bgsave：

父进程会执行fork操作来创建一个子进程。RDB文件由子进程来负责生成，父进程可以正常处理客户端发送的命令（这里也是Redis不仅仅只是单线程的一个体现）。

如果想要知道上一次成功执行 save或者bgsave命令的时间，可以执行lastsave命令进行查看，lastsave命令返回的是一个unix时间戳。

RDB机制相关配置文件

除了上面提到的触发生成rdb文件的配置参数，RDB持久化机制还有如下一些相关命令：

1.dir

rdb文件生成目录。默认是./（当前目录），可以执行命令config get dir进行查看，如下图所示说明当前dump文件生成目录为 /usr/local/redis-5.0.5/bin：

2.dbfilename

rdb文件名。默认是dump.rdb。

3.rdbcompression

rdb文件是否是LZF压缩文件。默认是 yes。

4.rdbchecksum

是否开启数据校验。默认是 yes。

RDB机制优点

1.RDB是一个非常紧凑的压缩文件，保存了不同时间点上的文件，非常适合用来灾备和数据恢复。

2.RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一的工作就是派生一个子进程来完成剩下的工作，父进程永远不会执行磁盘I/O或类似的耗时操作。

3.与后面介绍的AOF持久化机制比较，RDB方式恢复数据的速度更快。

RDB机制缺点

1.RDB无法做到实时备份，所以如果Redis因异常停止工作而没有正确的关机，那么从上一次备份的到异常宕机的这一段时间的数据将会丢失。

2、RDB通常需要父进程来执行fork操作创建子线程，所以如果频繁执行fork操作而CPU性能又不是很高的话可能会造成短时间内父进程不可用。

AOF全称为：Append Only File，是Redis当中提供的另一种持久化机制。AOF采用日志的形式将每个写操作追加到文件中。开启AOF机制后，只要执行更改Redis数据的命令时，命令就会被写入到AOF文件中。在Redis重启的时候会根据日志内容依次执行AOF文件中的命令来恢复数据。

AOF和RDB最大的不同是：AOF记录的是执行命令（类似于MySQL中binlog的statement格式），而RDB记录的是数据（类似于MySQL中 binlog的row格式）。

需要注意的是：假如同时开启了RDB和AOF两种机制，那么Redis会优先选择AOF持久化文件来进行数据恢复。

AOF机制如何开启

AOF机制默认是关闭的，可以通过以下配置文件进行修改

PS：和 RDB机制一样，其生成文件的路径也是通过dir属性进行配置。

AOF机制数据是否实时写入磁盘

AOF机制下数据是否实时写入磁盘，这个和MySQL的redo log机制很类似，也是需要通过参数来进行控制。

AOF数据何时写入磁盘由参数appendfsync来进行控制：

AOF文件重写

AOF机制主要是通过记录执行命令的方式来实现的，那么随着时间的增加，AOF文件不可避免的会越来越大，而且可能会出现很多冗余命令。比如同一个key值执行了10000次set操作，实际上前面9999次对恢复数据来说都是没用的，只需要执行最后一次命令就可以把数据恢复，正是为了避免这种问题，AOF机制就提供了文件重写功能。

重写原理分析

AOF重写时Redis并不会去分析原有的文件，因为如果原有文件过大，分析也会很耗时，所以Redis选择的做法就是重新去Redis中读取现有的键值对，然后用一条命令记录键值对的值。

只使用一条命令也有一个前提，那就是一个集合键或者列表键或者哈希键内包含的元素不能超过64个，一旦超过64个，就会使用多条命令来进行记录。

AOF重写缓冲区

AOF重写的时候一般都会有大量的写操作，所以为了不阻塞客户端的命令请求，Redis会把重写操作放入到子进程中执行，但是放入子进程中执行也会带来一个问题，那就是重写期间如果同时又执行了客户端发过来的命令，又该如何保证数据的一致性？

为了解决数据不一致问题，Redis 中引入了一个 AOF 重写缓冲区。当开始执行 AOF 文件重写之后又接收到客户端的请求命令，不但要将命令写入原本的 AOF 缓冲区（根据上面提到的参数刷盘），还要同时写 入 AOF 重写缓冲区：

一旦子进程完成了 AOF 文件的重写，此时会向父进程发出信号，父进程收到信号之后会进行阻塞（阻塞期间不执行任何命令），并进行以下两项工作：

1.将 AOF 重写缓冲区的文件刷新到新的 AOF 文件内。

2.将新 AOF 文件进行改名并原子的替换掉旧的 AOF 文件。

完成了上面的两项工作之后，整个 AOF 重写工作完成，父进程开始正常接收命令。

AOF机制触发条件

AOF机制的触发条件同样也分为自动触发和手动触发。

1.自动触发

自动触发可以通过以下参数进行设置：

2.手动触发

执行bgrewriteaof命令。

注意：bgrewriteaof命令也不能和上面RDB持久化命令bgsave同时执行，这么做是为了避免同时创建两个子进程来同时执行大量写磁盘操作，影响到Redis的性能。

AOF机制机制优点

1.使用AOF机制，可以自由选择不同fsync（刷盘）策略，而且在默认策略下最多也仅仅是损失1s的数据。

2.AOF日志是一个仅追加的日志，因此如果出现断电，也不存在查找或损坏问题。即使由于某些原因（磁盘已满或其他原因），日志已经写了一半的命令结束，redis-check-aof工具也能够轻松地修复它。

3.当AOF文件变得太大时，Redis 能够在后台自动重写。

4.不同于RDB的文件格式，AOF是一种易于理解和解析的格式，依次包含所有操作的日志。

AOF机制机制缺点

1.对于相同的数据集，AOF文件通常比等效的RDB文件大。

2.根据fsync的具体策略，AOF机制可能比RDB机制慢。但是一般情况下，fsync设置为每秒的性能仍然很高，禁用fsync后，即使在高负载下，它的速度也能和RDB一样快。

3.因为AOF文件是追加形式，可能会遇到BRPOP、LPUSH等阻塞命令的错误，从而导致生成的AOF在重新加载时不能复制完全相同的数据集，而RDB文件每次都是重新从头创建快照，这在一定程度上来说RDB文件更加健壮。

本文主要介绍了Redis的两种持久化机制：RDB和AOF，并分别介绍了两种持久化机制的原理，通过对两种持久化机制的对比分析了两种持久化机制各自的优点和缺点。