Redis（2）- Redis持久化

一、前言

Redis 的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。

二、持久化流程

既然redis的数据可以保存在磁盘上，那么这个流程是什么样的呢？

要有下面五个过程：

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

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

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

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

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

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

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

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

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

三、RDB机制

RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

1 触发机制

RDB持久化触发机制分为：手动触发和自动触发

（1）手动触发

save命令：会阻塞当前服务器，直到RDB完成为止，如果数据量大的话会造成长时间的阻塞，线上环境一般禁止使用

bgsave命令：就是background save，执行bgsave命令时Redis主进程会fork一个子进程来完成RDB的过程，完成后自动结束（操作系统的多进程Copy On Write机制，简称COW）。所以Redis主进程阻塞时间只有fork阶段的那一下。相对于save，阻塞时间很短。

命令	save	bgsave
IO类型	同步	异步
阻塞	是	是（发生在fork）
复杂度	O（n）	O（n）
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork，消耗内存

（2）自动触发

1）场景一：配置redis.conf，触发规则，自动执行

在redis.conf配置文件中，里面有如下配置，我们可以去设置：

①save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

默认如下配置：

# 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生bgsave命令。
# save <seconds> <changes>
# 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次bgsave操作

save 900 1 
save 300 10 
save 60 10000

# 以上配置的含义：
# 900秒之内至少一次写操作
# 300秒之内至少发生10次写操作、
# 60秒之内发生至少10000次写操作
# 只要满足任一条件，均会触发bgsave

不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。

②stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

③rdbcompression ：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。

④rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

⑤dbfilename ：设置快照的文件名，默认是 dump.rdb

⑥dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。

2）场景二：执行shutdown命令关闭服务器时，如果没有开启AOF持久化功能，那么会自动执行一次bgsave

3）场景三：主从同步（slave和master建立同步机制）

（更多同步内容在第三节展开）

2 RDB执行流程

Redis 使用操作系统的多进程 cow(Copy On Write) 机制来实现RDB快照持久化

（1） 执行bgsave命令的时候，Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务，如果有的话，直接返回

（2） Redis主进程会fork一个子进程来执行执行RDB操作，fork操作会对主进程造成阻塞（影响Redis的读写），fork操作完成后会发消息给主进程，从而不再阻塞主进程。（阻塞仅指主进程fork子进程的过程，后续子进程执行操作时不会阻塞）

（3） RDB子进程会根据Redis主进程的内存生成临时的快照文件，持久化完成后会使用临时快照文件替换掉原来的RDB文件。（该过程中主进程的读写不受影响，但Redis的写操作不会同步到主进程的主内存中，而是会写到一个临时的内存区域作为一个副本）

（4） 子进程完成RDB持久化后会发消息给主进程，通知RDB持久化完成（将上阶段内存副本中的增量写数据同步到主内存）

3 RDB的优缺点

优点

• RDB文件小，非常适合定时备份，用于灾难恢复
• Redis加载RDB文件的速度比AOF快很多，因为RDB文件中直接存储的时内存数据，而AOF文件中存储的是一条条命令，需要重演命令。

缺点

• RDB无法做到实时持久化，若在两次bgsave间宕机，则会丢失区间（分钟级）的增量数据，不适用于实时性要求较高的场景
• RDB的cow机制中，fork子进程属于重量级操作，并且会阻塞redis主进程
  存在老版本的Redis不兼容新版本RDB格式文件的问题

四、AOF机制

AOF日志是持续增量的备份，是基于写命令存储的可读的文本文件。每当有一个写命令过来时，就直接保存在我们的AOF文件中。

AOF日志会在持续运行中持续增大，由于Redis重启过程需要优先加载AOF日志进行指令重放以恢复数据，恢复时间会无比漫长。所以需要定期进行AOF重写，对AOF日志进行瘦身。

目前AOF是Redis持久化的主流方式。

1 开启方式

AOF默认是关闭的，通过redis.conf配置文件进行开启

## 此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能  
## 只有在“yes”下，aof重写/文件同步等特性才会生效  
appendonly yes  

## 指定aof文件名称  
appendfilename appendonly.aof  

## 指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec  
appendfsync everysec  
## 在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”  
no-appendfsync-on-rewrite no  

## aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”  
auto-aof-rewrite-min-size 64mb  

## 相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比  
## 每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)
## aof文件增长到A*(1 + p)之后，触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

同步策略比较

策略	优缺点
always	每一条AOF记录都立即同步到文件，性能很低，但较为安全。
everysec	每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，可能导致最多1秒的AOF记录丢失。
no	Redis永不直接调用文件同步，而是让操作系统来决定何时同步磁盘。性能较好，但很不安全。

2 重写机制

重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

重写过程中，对于新的变更操作将仍然被写入到原AOF文件中，同时这些新的变更操作也会被Redis收集起来。当内存中的数据被全部写入到新的AOF文件之后，收集的新的变更操作也将被一并追加到新的AOF文件中。然后将新AOF文件重命名为appendonly.aof，使用新AOF文件替换老文件，此后所有的操作都将被写入新的AOF文件。

3 触发机制

和RDB类似，分为手动触发和自动触发

（1）手动触发

直接调用bgrewriteaof命令

redis-cli -h ip -p port bgrewriteaof

（2）自动触发

根据配置文件auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发

触发条件 (aof_current_size > auto-aof-rewrite-min-size ) && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

4.AOF的优缺点

（1）优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
• AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
• AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

（2）缺点

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
• 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

五、RDB和AOF比较

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

六、RDB和AOF混合使用

1.前言：

• 仅使用RDB快照方式恢复数据，由于快照时间粒度较大，时回丢失大量数据。
• 仅使用AOF重放方式恢复数据，日志性能相对 rdb 来说要慢。在 Redis 实例很大的情况下，启动需要花费很长的时间。

2.解决方案

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。相当于：

• 大量数据使用粗粒度（时间上）的rdb快照方式，性能高，恢复时间快。
• 增量数据使用细粒度（时间上）的AOF日志方式，尽量保证数据的不丢失。

在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

但混合持久化是Redis 4.0才引入的特性，现在很多 公司可能都还在使用3.x版本。使用不了这一特性

3.建议

在主从服务器中，Master使用AOF，Slave使用RDB快照，master需要首先确保数据完整性，它作为数据备份的第一选择；slave提供只读服务或仅作为备机，它的主要目的就是快速响应客户端read请求或灾切换。

至于具体使用哪种持久化方式，就看大家根据场景选择。没有最好，只有最合适。