本文共2777字，该系列将针对Redis这个内存数据库的持久化机制进行一系列的讲述，包括RDB、AOF、AOF重写。

Redis作为一款高性能的内存数据库，不仅是在工作中常常用到，面试的时候也逃不了。首先我们知道Redis作为一款内存数据库，其数据保存在内存之中，当处理客户端的请求时，所有的操作都是在内存中进行的，这也是它高效的一个原因。

但是我们也都知道，数据是瞬息万变的，而存储在内存中，也同样面临着另一个严峻的问题，那就是只要服务器由于各种原因关机，或者Redis-Server进程关闭，内存中的数据就都会消失不见。当我们将Redis作为数据库来使用的时候，这种内存数据的丢失可谓是灾难性的。

所幸，Redis为了避免这种情况的发现，或者说降低这种风险导致的异常，它为我们提供了将内存中数据持久化到硬盘上的机制，使数据从内存中，变成硬盘上的文件，可以进行导入和复制。

这套机制便是本文的重点，RDB和AOF机制。

持久化的流程

持久化一共要有下面五个过程：

（1）客户端向服务端发送写操作(数据在客户端的内存中)。

（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。

（3）服务端调用write这个系统调用，将数据往磁盘上写(此时写进来的数据，会在系统内存的缓冲区中)。

（4）操作系统再将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。

（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

这5个过程是在理想条件下一个正常的保存流程，但是在大多数情况下，我们的机器等等都会有各种各样的故障，这里划分了两种情况：

（1）Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成。

（2）操作系统发生故障，必须上面5步都完成才可以。

在这里只考虑了保存的过程可能发生的故障，其实保存的数据也有可能发生损坏，需要一定的恢复机制，不过在这里就不再延伸了。现在主要考虑的是redis如何来实现上面5个保存磁盘的步骤。它提供了两种策略机制，也就是RDB和AOF。

RDB

RDB是一种快照存储持久化方式，什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。

RDB的持久化方式我们了解了，那它是如何触发这个持久化的呢？

为了实现这个过程，Redis提供了三种机制：save、bgsave、自动化。

SAVE

该方式是指通过发起一个save命令来触发RDB机制，进行同步持久化。

由于save命令是一个同步操作，会阻塞当前Redis服务器，也就是说当客户端向服务器发送save命令请求进行持久化时，服务器会阻塞save命令之后的其他客户端的请求，直到数据同步完成。

同时执行完成时候，如果存在老的RDB文件，就把新的替代掉旧的，如果持久化的数据量太大，同步数据会执行很久，而这期间Redis服务器也无法接收其他请求，所以，最好不要在生产环境使用save命令，很容易被追责哦。

BGSAVE

该方式是指通过发起一个bgsave命令来触发RDB机制，进行异步持久化。

与save的区别就在于，执行bgsave命令时，Redis服务器主进程会forks一个子进程，异步进行持久化操作，RDB的同时还可以响应客户端请求。在将数据保存到rdb文件之后，子进程会退出。

所以，与save命令相比，Redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但要注意的是，forks子进程的操作是同步的，所以forks子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。目前基本上Redis内部所有的RDB操作都是采用 bgsave 命令。

自动化

该方式是指配置文件的配置来触发RDB机制。

除了通过客户端发送命令外，还有一种方式，就是在Redis配置文件中的save指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启RDB数据同步。

例如我们可以在配置文件redis.conf指定如下的选项：

# 900s内至少达到一条写命令

save 900 1

# 300s内至少达至10条写命令

save 300 10

# 60s内至少达到10000条写命令

save 60 10000

之后在启动服务器时加载配置文件。

# 启动服务器加载配置文件

redis-server redis.conf

这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。

当不需要持久化的时候，我们可以注释掉所有的 save 配置后来停用保存功能。

RDB文件

我们可以发现，不论是通过save、bgsave还是自动化，持久化时都会生成rdb文件，我们来简单的了解下其生成的过程：

1. 生成临时rdb文件，并写入数据。
2. 完成数据写入，用临时文件替代正式rdb文件。
3. 删除原来的db文件。

RDB默认生成的文件名为dump.rdb，当然，我可以通过配置文件进行更加详细配置，比如在单机下启动多个redis服务器进程时，可以通过端口号配置不同的rdb名称，如下所示：

# 是否压缩rdb文件

rdbcmpression yes

# rdb文件的名称

dbfilename redis-6379.rdb

# rdb文件保存目录

dir ~/redis/

RDB的优点

1. RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作，对Redis服务器性能影响较小。
3. RDB 在恢复大数据集时的速度比起其他方式（AOF），更快。

RDB的缺点

1. 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
2. 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
3. 数据丢失：

• 如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
• 由于开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，但父进程修改内存时，子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

下一节：AOF及AOF重写持久化机制

10分钟后，你将彻底理解Redis的持久化机制（下）