Redis 提供了两种持久化方式，一种是基于快照形式的 RDB，另一种是基于日志形式的 AOF，每种方式都有自己的优缺点，本文将介绍 Redis 这两种持久化方式，希望阅读本文后你对 Redis 的这两种持久化方式有更加全面、清晰的认识。

RDB 快照方式持久化

先从 RDB 快照方式聊起，RDB 是 Redis 默认开启的持久化方式，并不需要我们单独开启，先来看看跟 RDB 相关的配置信息： 

################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# save ""
# 自动生成快照的触发机制 中间的是时间，单位秒，后面的是变更数据 60 秒变更 10000 条数据则自动生成快照
save 900 1
save 300 10
save 60 10000

# 生成快照失败时，主线程是否停止写入
stop-writes-on-bgsave-error yes

# 是否采用压缩算法存储
rdbcompression yes

# 数据恢复时是否检测 RDB文件有效性
rdbchecksum yes

# The filename where to dump the DB
# RDB 快照生成的文件名称
dbfilename dump.rdb

# 快照生成的路径 AOF 也是存放在这个路径下面
dir .

关于 RDB 相关配置信息不多，需要我们调整的就更少了，我们只需要根据自己的业务量修改生成快照的机制和文件存放路径即可。

RDB 有两种持久化方式：手动触发 和 自动触发，手动触发使用以下两个命令：

除了执行命令手动触发之外，Redis 内部还存在自动触发 RDB 的持久化机制，在以下几种情况下 Redis 会自动触发 RDB 持久化：

上面就是 RDB 持久化的方式，可以看出 save 命令使用的比较少，大多数情况下使用的都是 bgsave 命令，所以这个 bgsave 命令还是有一些东西，那接下来我们就一起看看 bgsave 背后的原理，先从流程图开始入手：

redis原理及实现（了解Redis的原理及其持久化方式的实现）(1)

bgsave 命令大概有以下几个步骤：

上面就是 bgsave 命令背后的一些内容，RDB 的内容就差不多了，我们一起来总结 RDB 持久化的优缺点，RDB 方式的优点：

有优点同样存在缺点，RDB 的缺点有：

如果我们对数据要求比较高，每一秒的数据都不能丢，RDB 持久化方式肯定是不能够满足要求的，那 Redis 有没有办法满足呢，答案是有的，那就是接下来的 AOF 持久化方式

AOF 文件持久化方式

Redis 默认并没有开启 AOF 持久化方式，需要我们自行开启，在 redis.conf 配置文件中将 appendonly no 调整为 appendonly yes，这样就开启了 AOF 持久化，与 RDB 不同的是 AOF 是以记录操作命令的形式来持久化数据的，我们可以查看以下 AOF 的持久化文件 appendonly.aof 

*2
$6
SELECT
$1
0
*3
$3
set
$6
mykey1
$6
你好
*3
$3
set
$4
key2
$5
hello
*1
$8

大概就是长这样的，具体的你可以查看你 Redis 服务器上的 appendonly.aof 配置文件，这也意味着我们可以在 appendonly.aof 文件中国修改值，等 Redis 重启时将会加载修改之后的值。看似一些简单的操作命令，其实从命令到 appendonly.aof 这个过程中非常有学问的，下面时 AOF 持久化流程图：

redis原理及实现（了解Redis的原理及其持久化方式的实现）(2)

在 AOF 持久化过程中有两个非常重要的操作：一个是将操作命令追加到 AOF_BUF 缓存区，另一个是 AOF_buf 缓存区数据同步到 AOF 文件，接下来我们详细聊一聊这两个操作：

1、为什么要将命令写入到 aof_buf 缓存区而不是直接写入到 aof 文件？

我们知道 Redis 是单线程响应，如果每次写入 AOF 命令都直接追加到磁盘上的 AOF 文件中，这样频繁的 IO 开销，Redis 的性能就完成取决于你的机器硬件了，为了提升 Redis 的响应效率就添加了一层 aof_buf 缓存层， 利用的是操作系统的 cache 技术，这样就提升了 Redis 的性能，虽然这样性能是解决了，但是同时也引入了一个问题，aof_buf 缓存区数据如何同步到 AOF 文件呢？由谁同步呢？这就是我们接下来要聊的一个操作：fsync 操作

2、aof_buf 缓存区数据如何同步到 aof 文件中？

aof_buf 缓存区数据写入到 aof 文件是有 linux 系统去完成的，由于 Linux 系统调度机制周期比较长，如果系统故障宕机了，意味着一个周期内的数据将全部丢失，这不是我们想要的，所以 Linux 提供了一个 fsync 命令，fsync 是针对单个文件操作（比如这里的 AOF 文件），做强制硬盘同步，fsync 将阻塞直到写入硬盘完成后返回，保证了数据持久化，正是由于有这个命令，所以 redis 提供了配置项让我们自行决定何时进行磁盘同步，redis 在 redis.conf 中提供了appendfsync 配置项，有如下三个选项： 

# appendfsync always
appendfsync everysec
# appendfsync no

这就是三种磁盘同步策略，但是你有没有注意到一个问题，AOF 文件都是追加的，随着服务器的运行 AOF 文件会越来越大，体积过大的 AOF 文件对 redis 服务器甚至是主机都会有影响，而且在 Redis 重启时加载过大的 AOF 文件需要过多的时间，这些都是不友好的，那 Redis 是如何解决这个问题的呢？Redis 引入了重写机制来解决 AOF 文件过大的问题。

3、Redis 是如何进行 AOF 文件重写的？

Redis AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程，重写之后的 AOF 文件会比旧的 AOF 文件占更小的体积，这是由以下几个原因导致的：

重写之后的 AOF 文件体积更小了，不但能够节约磁盘空间，更重要的是在 Redis 数据恢复时，更小体积的 AOF 文件加载时间更短。AOF 文件重写跟 RDB 持久化一样分为手动触发和自动触发，手动触发直接调用 bgrewriteaof 命令就好了，我们后面会详细聊一聊这个命令，自动触发就需要我们在 redis.conf 中修改以下几个配置 

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

满足了这两个条件，Redis 就会自动触发 AOF 文件重写，AOF 文件重写的细节跟 RDB 持久化生成快照有点类似，下面是 AOF 文件重写流程图：

redis原理及实现（了解Redis的原理及其持久化方式的实现）(3)

AOF 文件重写也是交给子进程来完成，跟 RDB 生成快照很像，AOF 文件重写在重写期间建立了一个 aof_rewrite_buf 缓存区来保存重写期间主进程响应的命令，等新的 AOF 文件重写完成后，将这部分文件同步到新的 AOF 文件中，最后用新的 AOF 文件替换掉旧的 AOF 文件。需要注意的是在重写期间，旧的 AOF 文件依然会进行磁盘同步，这样做的目的是防止重写失败导致数据丢失，

Redis 持久化数据恢复

我们知道 Redis 是基于内存的，所有的数据都存放在内存中，由于机器宕机或者其他因素重启了就会导致我们的数据全部丢失，这也就是要做持久化的原因，当服务器重启时，Redis 会从持久化文件中加载数据，这样我们的数据就恢复到了重启前的数据，在数据恢复这一块Redis 是如何实现的？我们先来看看数据恢复的流程图：

redis原理及实现（了解Redis的原理及其持久化方式的实现）(4)

Redis 的数据恢复流程比较简单，优先恢复的是 AOF 文件，如果 AOF 文件不存在时则尝试加载 RDB 文件，为什么 RDB 的恢复速度比 AOF 文件快，但是还是会优先加载 AOF 文件呢？我个人认为是 AOF 文件数据更全面并且 AOF 兼容性比 RDB 强，需要注意的是当存在 RDB/AOF 时，如果数据加载不成功，Redis 服务启动会失败。