Redis为持久化提供了两种方式：

RDB：在指定的时间间隔能对你的数据进行快照存储(它是备份当前瞬间 Redis 在内存中的数据记录,通过快照（snapshotting）实现的)。

AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据(只追加文件（Append-Only File，AOF），其作用就是当 Redis 执行写命令后，在一定的条件下将执行过的写命令依次保存在 Redis 的文件中，将来就可以依次执行那些保存的命令恢复 Redis 的数据了)。

本文将通过下面内容的介绍，希望能够让大家更全面、清晰的认识这两种持久化方式，同时理解这种保存数据的思路，应用于自己的系统设计中。

持久化的配置

RDB与AOF持久化的工作原理

如何从持久化中恢复数据

关于性能与实践建议

持久化的配置

为了使用持久化的功能，我们需要先知道该如何开启持久化的功能。

半持久化RDB模式

开启rdb持久化

Redis进行RDB快照的条件由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。在配置文件中已经预置了3个条件：

save 900 1 #900秒内有至少1个键被更改则进行快照；
save 300 10 #300秒内有至少10个键被更改则进行快照；
save 60 10000 #60秒内有至少10000个键被更改则进行快照
默认可以存在多个条件，条件之间是“或”的关系，只要满足其中一个条件，就会进行快照。

# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /home/work/app/redis/data/
# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 启动redis时，是否检查rdb数据库的完整性
rdbchecksum yes

配置其实非常简单，这里说一下持久化的时间策略具体是什么意思。

save 900 1 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份

save 300 10 表示300s内有10条写入，就产生快照

下面的类似，那么为什么需要配置这么多条规则呢？因为Redis每个时段的读写请求肯定不是均衡的，为了平衡性能与数据安全，我们可以自由定制什么情况下触发备份。所以这里就是根据自身Redis写入情况来进行合理配置。

stop-writes-on-bgsave-error yes 这个配置也是非常重要的一项配置，这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统，可以禁止此项配置，否则请开启。

关于压缩的配置 rdbcompression yes ，建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。

禁用RDB配置

非常容易，只需要在save的最后一行写上：save ""

RDB的原理

半持久化RDB模式是Redis备份默认方式，是通过快照（snapshotting）完成的，当符合在Redis.conf 配置文件中设置的条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上，完成数据备份。Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，根据数据量大小与结构和服务器性能不同，通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需花费20～30秒钟。

rdb持久化实现过程
Redis实现快照的过程，Redis使用fork函数复制（写时复制）一份当前进程（父进程）的副本（子进程），父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件，当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

除了自动触发快照，还可以手动发送SAVE和BGSAVE命令让Redis执行快照，两个命令的区别在于：save是由主进程进行快照操作，会阻塞住其他请求。bgsave是通过fork子进程进行快照操作。

针对RDB方式的持久化，手动触发可以使用：

save：会阻塞当前 Redis 服务器响应其他命令，直到 RDB 快照生成完成为止，对于内存比较大的实例会造成长时间阻塞，所以线上环境不建议使用。

bgsave：Redis 主进程会 fork 一个子进程，RDB 快照生成有子进程来负责，完成之后，子进程自动结束，bgsave 只会在 fork 子进程的时候短暂的阻塞，这个过程是非常短的，所以推荐使用该命令来手动触发。

10331:M 06 Apr 2020 13:38:45.011 * Background saving started by pid 10879
10879:C 06 Apr 2020 13:38:45.028 * DB saved on disk
10879:C 06 Apr 2020 13:38:45.028 * RDB: 4 MB of memory used by copy-on-write
10331:M 06 Apr 2020 13:38:45.033 * Background saving terminated with success

而自动触发的场景主要是有以下几点：

根据我们的 save m n 配置规则自动触发

从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave

执行 debug reload 时

执行 shutdown时，如果没有开启aof，也会触发

由于 save 基本不会被使用到，我们重点看看 bgsave 这个命令是如何完成RDB的持久化的

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

1、执行 bgsave 命令，Redis 主进程判断当前是否存在正在执行的 RDB/AOF 子进程，如果存在， bgsave 命令直接返回不在往下执行。

2、父进程执行 fork 操作创建子进程，fork 操作过程中父进程会阻塞，fork 完成后父进程将不在阻塞可以接受其他命令。

3、子进程创建新的 RDB 文件，基于父进程当前内存数据生成临时快照文件，完成后用新的 RDB 文件替换原有的 RDB 文件，并且给父进程发送 RDB 快照生成完毕通知。

RDB 快照是某一时刻 Redis 节点内存数据，非常适合做备份，上传到远程服务器或者文件系统中，用于容灾备份。数据恢复时 RDB 要远远快于 AOF。

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

RDB 持久化方式数据没办法做到实时持久化/秒级持久化。我们已经知道了 bgsave 命令每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。

RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题。

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

不管是RDB还是AOF都是先写入一个临时文件，然后通过 rename 完成文件的替换工作。

AOF的配置

# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

#在rdb写磁盘过程中，是否需要停止aof，默认是不停，如果负载较高，建议停止。
# 这个时候数据也不会丢失，在暂时存在内存队列，rdb数据写完后，aof继续。
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100 --aof文件大小相比上次文件大小，增长100%时，重写
auto-aof-rewrite-min-size 64mb  --aof文件至少超过64M时，重写

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

还是重点解释一些关键的配置：

appendfsync everysec 它其实有三种模式:

always：把每个写命令都立即同步到aof，很慢，但是很安全
everysec：每秒同步一次，是折中方案
no：redis不处理交给OS来处理，非常快，但是也最不安全

一般情况下都采用 everysec 配置，这样可以兼顾速度与安全，最多损失1s的数据。

aof-load-truncated yes 如果该配置启用，在加载时发现aof尾部不正确是，会向客户端写入一个log，但是会继续执行，如果设置为 no ，发现错误就会停止，必须修复后才能重新加载。

AOF的原理

AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。

在 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

always：每次有写入命令都进行缓存区与磁盘数据同步，这样保证不会有数据丢失，但是这样会导致 redis 的吞吐量大大下降，下降到每秒只能支持几百的 TPS ，这违背了 redis 的设计，所以不推荐使用这种方式

everysec：这是 redis 默认的同步机制，虽然每秒同步一次数据，看上去时间也很快的，但是它对 redis 的吞吐量没有任何影响，每秒同步一次的话意味着最坏的情况下我们只会丢失 1 秒的数据， 推荐使用这种同步机制，兼顾性能和数据安全

no：不做任何处理，缓存区与 aof 文件同步交给系统去调度，操作系统同步调度的周期不固定，最长会有 30 秒的间隔，这样出故障了就会丢失比较多的数据。这就是三种磁盘同步策略，但是你有没有注意到一个问题，AOF 文件都是追加的，随着服务器的运行 AOF 文件会越来越大，体积过大的 AOF 文件对 redis 服务器甚至是主机都会有影响，而且在 Redis 重启时加载过大的 AOF 文件需要过多的时间，这些都是不友好的，那 Redis 是如何解决这个问题的呢?Redis 引入了重写机制来解决 AOF 文件过大的问题。

3、Redis 是如何进行 AOF 文件重写的?(随着命令不断写入AOF，文件会越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件)

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容越来越多，文件体积越来越大，如果不加以控制，会对redis服务器甚至宿主计算器造成影响。

所谓的“重写”其实是一个有歧义的词语，实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取，它针对的是数据库中键的当前值。

考虑这样一个情况，如果服务器对键 list 执行了以下四条命令：

RPUSHlist1234// [1, 2, 3, 4]

RPOPlist// [1, 2, 3]

LPOPlist// [2, 3]

LPUSHlist1// [1, 2, 3]

那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。

如果我们要保存这个列表的当前状态，并且尽量减少所使用的命令数，那么最简单的方式不是去 AOF 文件上分析前面执行的四条命令，而是直接读取 list 键在数据库的当前值，然后用一条 RPUSH 1 2 3 命令来代替前面的四条命令。

再考虑这样一个例子，如果服务器对集合键 animal 执行了以下命令：

SADDanimalcat// {cat}

SADDanimaldogpandatiger// {cat, dog, panda, tiger}

SREManimalcat// {dog, panda, tiger}

SADDanimalcatlion// {cat, lion, dog, panda, tiger}

那么使用一条 SADD animal cat lion dog panda tiger 命令，就可以还原 animal 集合的状态，这比之前的四条命令调用要大大减少。

除了列表和集合之外，字符串、有序集、哈希表等键也可以用类似的方法来保存状态，并且保存这些状态所使用的命令数量，比起之前建立这些键的状态所使用命令的数量要大大减少。

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

进程内已经超时的数据不再写入文件

旧的 AOF 文件含有无效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于 list、set、hash、zset 等类型操作，以 64 个元素为界拆分为多条。

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

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage：代表当前 AOF文件空间 (aof_current_size)和上一次重写后 AOF 文件空间(aof_base_size)的比值，默认是 100%，也就是一样大的时候

auto-aof-rewrite-min-size：表示运行 AOF 重写时 AOF 文件最小体积，默认为 64MB，也就是说 AOF 文件最小为 64MB 才有可能触发重写。满足了这两个条件，Redis 就会自动触发 AOF 文件重写，AOF 文件重写的细节跟 RDB 持久化生成快照有点类似，下面是 AOF 文件重写流程图：

file