一文让你明白Redis持久化(RDB、AOF)

为什么要持久化

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器的数据库状态就会消失(即断电即失)。为了保证数据不丢失，我们需要将内存中的数据存储到磁盘，以便 Redis 重启时能够从磁盘中恢复原有的数据，而整个过程就叫做 Redis 持久化。

Redis 持久化也是 Redis 和 Memcached 的主要区别之一，因为 Memcached 是不具备持久化功能的。

持久化的几种方式

Redis 持久化拥有以下三种方式：

快照方式（RDB, Redis DataBase）将某一个时刻的内存数据，以二进制的方式写入磁盘；

文件追加方式（AOF, Append Only File），记录所有的写操作命令，并以文本的形式追加到文件中；

混合持久化方式，Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能避免数据丢失的风险。

因为每种持久化方案，都有特定的使用场景，让我们先从 RDB 持久化说起吧。

一、什么是RDB，RDB如何实现持久化？

1、什么是RDB？

RDB是Redis Database 的缩写，其作用是在「某一个时间点，将Redis存储在内存中的数据生成快照并存储到磁盘等介质上，存在这个磁盘介质上的文件就是RDB文件」。“快照”顾名思义就是好像照相一样保存当时的数据，这里RDB文件是一个二进制的文件，并且是经过压缩的。因为RDB文件是保存在硬盘中的，即使Redis服务器进程退出，甚至运行Redis服务器的计算机宕机，但只要RDB文件仍然存在，Redis服务器就可以用它来还原数据库状态。

2、触发方式(手动、自动)

RDB 的持久化触发方式有两类：一类是手动触发，另一类是自动触发。

(1）手动触发

手动触发持久化的操作有两个命令：save 和 bgsave ，它们主要区别体现在：是否阻塞 Redis 主线程的执行。

save命令

redis 127.0.0.1:6379> SAVE

在客户端中执行 save 命令，就会触发 Redis 的持久化，但同时也是使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。

bgsave命令

redis 127.0.0.1:6379> BGSAVE

bgsave（background save）既后台保存的意思，它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，「整个过程中只有在 fork() 子进程时有短暂的阻塞」，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了，相对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适合我们使用。

在快照进行的过程中，也就是生成文件的过程中，不会对原有的RDB文件进行修改，直到快照生成完毕，直接将老的替换成新的，保证rdb文件任何时刻都是完整的。

(2) 自动触发

自动触发的含义就是不用我们手动命令去触发持久化，而是通过配置当满足某一规则的时候自动去执行 bgsave 命令。

Redis的配置文件就默认设置了3个保存点：

# 以下配置表示的条件：
# 900秒内有1个key发生了变化，则触发保存RDB文件
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000

#如果想禁用快照保存的功能，可以通过注释掉所有"save"配置达到，或者在最后一条"save"配置后添加如下的配置：
save ""

注意这里满足条件执行的是bgsave命令。

二、什么是AOF，AOF如何实现持久化？

1、什么是AOF？

以日志的形式来记录「每个写操作」，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

默认情况下，redis是没有开启AOF的。开启AOF功能需要设置配置：appendonly yes 。

2、AOF持久化流程

上面提到了AOF持久化的过程就是日志不断追加的过程，这里通过图给大家介绍具体流程：

1、Client作为命令的来源，会有多个源头以及源源不断的请求命令。

2、在这些命令到达Redis Server 以后，并不是直接写入AOF文件，会将其这些命令先放入「AOF缓存」中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。

3、AOF缓冲会根据对应的策略将命令写入磁盘上的AOF文件。

4、AOF文件随着写入文件内容的增加，会根据规则进行命令的合并，这里叫做AOF重写，从而起到AOF文件压缩的目的。

5、当Redis Server 服务器重启的时候会从AOF文件载入数据。

这里面有两点需要在详细写: 「AOF缓冲区同步文件策略」 和 「AOF重写机制」。

3、AOF缓冲区同步文件策略

上面提到了Redis 会将命令先写入到AOF缓冲区，再写入AOF文件。这里介绍一下AOF缓冲区同步文件的三个策略。

#aof持久化策略的配置
appendfsync always    #always表示每次写入都执行fsync，以保证数据同步到磁盘
appendfsync everysec   #everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
appendfsync no   #no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快

Always策略的同步操作是在主进程的主线程中进行的，由于fsync的阻塞特性，会导致其挂起，在此期间无法服务新的请求，因而吞吐量下降，但确实能够保证内存和硬盘中数据的一致性。

Everysec策略的同步操作是通过后台I/O线程进行的，由于是在子线程中进行，所以主线程并不会被阻塞，可以继续服务新的请求，但是内存和硬盘中的数据会有1秒的差别（不一定精准），这是一种折衷的方案，寻求了一个平衡。

No策略则是将同步操作的控制权交由操作系统，不阻塞主线程，但是数据一致性可能会偏差很大

官方建议使用默认配置每秒同步，它既快速又安全。这个always策略在实践中非常缓慢，没有办法做得fsync比现在更快。