05、Redis持久化

Redis是在内存中操作的，我们服器关闭重启机器后，正常是之前在redis中操作的数据都不存在了，但是实际上我们开机后重新启动redis服务，一样可以看到之前操作的数据。这是为什么呢？

我们在redis的安装目录下可以看到有一个dump.rdb，其实这里面就写有之前的数据。

这就相当于Redis其实是把数据持久化保存到了磁盘文件中了，具有了持久化的能力。

Redis其会按照设置以快照或操作日志的形式把数据持久化到磁盘，根据持久化使用的技术不同，Redis的持久化又分为两种：RDB与AOF

一、持久化原理

Redis持久化也称为钝化，把内存中数据库的状态描述信息保存到磁盘当中，只不过不同的持久化技术，对数据的状态描述信息是不同的，生成的持久化文件也是不同的。

钝化可以通过手动的方式或者是自动的方式（全自动或者条件触发后自动），把内存中的数据信息写到持久化文件中，当系统重新启动时，自动加载持久化文件，并根据文件中数据库状态描述信息把数据恢复到内存中，这个恢复的过程也称为激活。

从上面看实际上如果用手动的方式或者是定时方式或者条件触发方式进行钝化都有数据丢失的可能。比如,redis中进行了一些操作，但是还没有及时进行钝化操作这个时候redis宕机了。那么上次保存到宕机期间的数据就会丢失。

对于不同的持久化方式，其数据的丢失率也是不一样的。我们定时执行的频率越高则丢失率越小，但频率过高又会影响性能。

Redis中默认的持久化方式是：RDB，Redis当中也可以让RDB与AOF同时存在，此时系统会使用AOF的方式做持久化。在redis服务启动时，如果它既有RDB的持久化文件又有AOF的持久化文件那么优先加载AOF持久化文件。

二、RDB持久化

RDB，Redis DataBase，是指的把内存中的某一时刻的数据快照全量写入到指定的rdb文件当中。RDB是默认开启的。当Redis启动时会自己动读取RDB快照文件，把数据从硬盘载入内存，以恢复Redis关机前的数据库状态。

持久化的执行

手动save命令

通过在redis-cli客户端中执行save命令即可立即进行一次持久化保存。

save命令在执行期间会阻塞redis-server进程，直到持久化过程完毕。在redis-server进程阻塞期间，Redis不可以处理任何读写请求，无法对外提供服务。

手动bgsave命令

通过在redis-cli客户端中执行bgsave命令可立即进行一次持久化保存。不同于save命令的是，bgsave命令会使用服务器进程redis-server生成一个子进程，由这个子进程负责完成保存过程，这时子进程进行保存过程中不会阻塞redis-server进程对客户端读写请求的处理。

自动触发条件

它本质上还是bgsave命令的执行，只是这个时候不是主动去执行命令，而是在配置文件中做相应的配置，redis会根据设置信息自动调用bgsave命令执行。

查看最近一次持久化时间

通过命令lastsave命令可以查看最近一次执行持久化的时间，其返回的是一个Unix的时间戳。

RDB优化配置

RDB的相关配置在redis.conf文件的SNAPSHOTTING部分。

save

上面那个save配置注释掉也是默认的，默认的save命令其实就等价于下面的三条配置

save 3600 1 在3600秒内发生1次写操作
save 300 100 在300秒内发生100次写操作
save 60 10000 在60秒内发生10000次写操作

在上在三个条件中任意条件满足时会执特自动保存bgsave

注意：它是一个条件逐步放宽的递进判断，先看60秒是否执行10000次，如果没有到10000次则等到5分种的时候看是否达到了100次，达到则保存没有达到再看1小时同有没有发生过一次写操作，有则保存否则不保存。

注意：如果save后的置配置”“ 那么说明一个保存点都没有就不会启用RDB持久化

stop-write-on-bgsave-error

默认情况下，如果RDB快照已启用（至少一个保存点），并且最近的bgsave命令失败，Redis会停止接受写入。这样设置是为了让用户意识到数据没有正确保存到磁盘上，防止发生一些后续灾难性问题，如果后面bgsave命令可以正常工作了，Redis会自己动允许再次写入。

rdbcompression

当进行持久化时启用LZF压缩算法压缩字符串对象，它对性能会有一定的影响但是它可以大幅度地降低文件大小，加速主从节点间的数据同步。

rdbchecksum

从RDB5开始，RDB文件的CRC64检验和就会被放在文件末尾。这可以防止RDB文件的损坏，但是这对于保存与加载RDB文件会大约有10%的性能损耗

dbfilename

指定RDB文件的默认名称，默认值为dump.rdb

rdb-del-sync-files

主从复制时，是否删除用于同步的从机上的RDB文件，默认是no（不删除）不过注意，只有当从机的RDB和AOF持久化功能都没有开启时才生效

dir

指定RDB与AOF文件的生成目录，默认在Redis的安装根目录

RDB文件结构

dump.rdb文件整体分为五个部分：

SOF

它是一个常量，表示开始，是一个字符串REDIS，仅仅包含这五个字符

rdb_version

这是一个整数，长度是4个字节，用来表示RDB语言件的版本号

databases

它是RDB文件中最重要的数据部分它可以包含任意多个非空数据库。而每个database又是由三部分构成的

SODB：是一个常理，占1个字节，用于标识一个数据库的开始
db_number：数据库编号
key_value_pairs：当前数据库中的键值对数据

关于key_value_parirs又由很多的用于描述键值对的数据构成：

VALUE_TYPE：一个常量，占1个字节，标识键值对中的value类型
EXPIRETIME_UNIT：一个常量，占1个字节，用于标识过期时间的单位是秒还是毫秒
time：当前key-value的过期时间
key
value

EOF

它是一个常量，占一个字节，用于表示RDB数据的结束，校验和的开始

check_sum

校验和check_sum用于判断RDB文件中的内容是否出现数据异常，它采用的是CRC校验算法

关于CRC校验算法简单说明：

在持久化时，先把SOF，rdb_version及内存数据库快照这三者的二进制数据拼接起来，形成一个二进制数（假定为a），然后再用这个a除以校验和check_sum，此时可以得到一个余数b，然后再把b拼接到a后面，形成databases。在加载时，需要先使用check_sum对RDB文件进行数据损坏验证。验证的过程是：只需要RDB文件中除EOF与check_sum外的数据除以check_sum。只要除得的余数不是0，就说明文件发生损坏。

注意：余数是0也不能肯定文件有没有损坏，这种校验只能校验数据是损坏的而不是校验数据没有损坏。

RDB持久化过程

对于Redis默认的RDB持久化，在进行bgsave持久化时，redis-server进程会fork出一个bgsave子进程，这个子进程以异步的方式负责完成持久化，而在持久化的过程中，redis-server进程不会阻塞，其会继续接收并处理用户的请写请求。

bgsave子进程的工作原理：

由于子进程可以继承父进程的所有资源，且父进程不能拒绝子进程的继承权。所以bgsave子进程有权读取到redis-server进程写入到内存中的用户数据，使得把内存数据持久化到dump.rdb成为可能。

bgsave子进程在持久化时首先会把内存中的全量数据copy到磁盘中的一个RDB临时文件，copy结束后，再把这个文件rename为dump.rdb，替换掉原来的同名文件。

在进行持久化过程中，如果redis-server进程接收到了用户写请求，则系统会把内存中发生数据修改的物理块copy出一个副本，等内存中的全量数据copy结束后，会再把这个副本中的数据copy到RDB临时文件。这个副本的生成是由于linux系统的写时复制技术（Copy-On-Write）实现的

关于写时复制技术说明：

它是linux系统的一种进程管理技术。

原来在Unix系统中，当一个主进程fork()出一个子进程后，内核进程会复制出主进程的整个内存空间中的数据，然后分配给到子进程，这种方式存在以下问题：

这个过程非常耗时
这个过程降低了系统性能
如果主进程修改了其内存数据，子进程副本中的数据是没有修改的，数据一致性没有办法保证

现代的Linux使用了更有效的方式：写时复制。子进制会继承父进程的所有资源其中就包含了主进程的内存空间。也就是子进程与父进程共享内存。只要是内存被共享，那么内存就是只读的（有写保护）。而写时复制则是在任何一方需要写入数据到共享内存时都会出现异常，此时内核进程就会把需要写入的数据copy出一个副本写入到另一块非共享内存区域。

三、AOF持久化

AOF，Append Only File，是指Redis把每一次的写操作都以日志的形式记录到一个AOF文件中的持久化技术，当需要恢复内存数据时，把这些写操作重新执行一次，便会恢复到之前的内存数据状态。

前面我们说的RDB的持久化是可能会有数据丢失的问题，在生产上如果丢失数据可能会丢失近30s的数据，这在高并发的场景下还是比较麻烦的，而对于现在我们说的AOF持久化，我们只要配置合适则我们只会丢失最后一秒或者说最后一次的写操作数据。

AOF的安全性相对于RDB更好一些。

基础配置

开启AOF

配置文件中修改参数：appendonly yes

默认的情况下它的配置值是no，表示不开启的，当把它改为yes后则表示开启AOF

查看当前appendonly的参数配置，使用命令：config get appendonly

修改appendonly的参数值命令：config set appendonly yes

执行完上面这个命令后则在缓存中修改了配置，需要进行rewrite一下,命令：config rewrite

文件名配置

Redis 7在文件配置这块有了比较大的变化，之前的版本中aof只有一个文件appendonly.aof，现在有三类多个文件：

基本文件：可以是RDB格式也可以是AOF格式。其存放的内容是由RDB转为AOF当时内存的快照数据，这个文件可以有多个
增量文件：以操作日志形式记录转为AOF后的写入操作，这个文件可以有多个
清单文件：用于维护AOF文件的创建顺序，保证在激活时的应用顺序，这个文件只有一个

appendfilename参数配置："appendonly.aof"

因为有多类，所以这里这个配置是多类文件的前缀。如下所示：

基础文件：appendonly.aof.1.base.rdb （有可能存在多个，所以这里有序号）

增量文件：appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof（随着写入的命令增加这里会有多个文件）

清单文件：appendonly.aof.manifest (这个文件只有一个)

混合式持久化开启

对于基本文件可以是RDB格式也可以使用AOF格式，通过aof-use-rdb-preamble属性可以选择，其默认值为yes，也就是说默认AOF持久化基本文件为rdb格式文件，也就默认采用混合式持久化。

AOF文件目录配置

为了方便管理，可以专门为AOF持久化文件指定存放目录，目录名由appenddirname属性指定，这个目录存放在redis.conf配置文件dir属性指定的目录，默认就是Redis的安装目录。

AOF文件格式

AOF文件有三类：基本文件、增量文件与清单文件，其中基本文件一般是rdb格式，下面我们看一下增量文件与清单文件的内容格式。

在介绍AOF文件格式前我们先看看Redis的协议

增量文件的扩展名为.aof，使用的是AOF格式。AOF格式其实就是Redis通讯协议格式，AOF持久化文件的本质就是基于Redis通讯协议的文本，把命令以纯文本的方式写入到文件中。

Rdedis协议规定，Redis文本是以行划分的，每行以\r\n结束，每一行都有一个消息头，用来表示消息的类型。消息头由六种不同的符号表示，其意义如下：

+ 表示一个正确的状态信息
- 表示一个错误信息
* 表示消息体总共有多少行，不包含当前行
$ 表示下一行消息的长度，不包含\r\n
空表示一个消息数据
: 表示返回一个数值

AOF文件

我们打开AOF文件其内容如下：

上面这个文件总共有四条命令：

# 第一条命令
*2
$6
SELECT
$1
0

第一条命令说明：

*2表示这个命令包含两个参数

$6表示第一个参数包含6个字符

SELECT这6个字符是第一个参数的值

$1表示第3个参数包含1个字符

0表示第二个参数的值

# 第二条命令
*3
$3
set
$1
a
$10
aaaaaaaaaa

第二条命令说明：

*3表示当前命令包含三个参数

$3表示第一个参数包含3个字符

set表示第一个参数的值

$1表示第二个参数包含1个字符

a表示第二个参数的值

$10表示第三个参数包含10个字符

aaaaaaaaaa表示第三个参数的值

后面的两个命令与处二个命令是类似的不再说明！

清单文件

打开清单文件查看其内容如下：

这个文件首先会按seq列举出所有基本文件，基本文件type类型为b，然后再按序号列举出所有增量文件，增量文件的类型是i。redis在启动时数据恢复也是按这个文件由上到下依次加载它们中的数据的。

Rewrite机制

随着使用时间的推移，AOF文件会越来越大。为了防止AOF文件太大而占用大量的磁盘空间，降低性能。redis引入了Rewrite机制来对AOF文件进行压缩。

什么是Rewrite？

rewrire就是对AOF文件进行重写整理。当Rewrite开启后，主进程redis-server创建出一个子进程bgrewriteaof，由这个子进程来完成rewrite过程。其首先对现有aof文件进行rewrite计算，把计算结果写到一个临时文件，写入完毕后，再rename这个临时文件为原aof文件名，覆盖原有文件。

Rewrite计算

rewrite计算也称为rewrite策略，rewrite计算遵循以下策略：

读操作不写入文件
无效命令不写入文件
过期数据不写入文件
多条命令合并写入文件

手动开启Rewrite

客户端执行命令bgrewriteaof

这个命令会使主进程redis-server创建出一个子进程bgrewriteaof，由这个子进程来完成rewrite过程，在rewrite期间，redis-server依然是可以对外提供读写服务的。

自动开启Rewrite

前边的手动开启需要人为执行命令bgrewriteaof。一般来说不会使用手动的方式而是采用自动的方式。由于rewrite过程是一个计算的过程，需要消耗大量的系统资源，所以rewrite过程并不是随时随地任意开启的，而是通过设置一些条件，当满足条件后才会启动。

配置文件中有两个配置：

auto-aof-rewrite-percentage：开启rewrite的增大比例，默认是100%。指定为0，表示禁用自动rewrite

auto-aof-rewrite-min-size：开启rewrite的AOF文件最小值，默认是64M。这个值的作用是防止过小的AOF文件进行rewrite，从而导致性能下降

自动重写AOF文件，当AOF日志文件大小增长到指定的百分比时。Redis主进程redis-server会fork出一个子进程bgwriteaof来完成rewrite过程。

其原理如下：

Redis会记住最新的rewrite后的AOF文件大小作为基本大小，如果从主机启动后就没有发生过重写，那么这个基本大小就是启动时的AOF大小。如果当前AOF文件大于基本大小的配置文件指定的百分比阈值时且当前AOF文件大于配置文件中指定的最小阈值时，会触发自动rewrite

AOF优化配置

appendfsync

当客户端提交写操作命令后，这个命令就会写入到aof_buf中，从aof_buf中的数据持久化到磁盘AOF文件的过程称为数据同步。

什么时候进行同步呢？这个配置就是指定这个同步的策略，其策略有三种：

1、always：立即同步，命令写到aof_buf后立即追加到AOF文件当中，效率低下，安全高

2、no：由操作系统来负责同步，Linux默认同步周期是30秒，效率高

3、everysec：默认策略，每秒种同步一次，这种方案兼顾性能与安全是一种折中的方案

no-appendfsync-on-rewrite

这个属性用来指定，当aof fsync策略设置为always或everysec，当主进程创建的子进程正在进行bgsave或者bgrewriteaof时，主进程是否不做数据同步，如果设置为no表示还是要同步，如果这里配置为yes则表示这个时候不同步。

注意：如果同步的时候存在大量的数据需要同步，会阻塞主进程对外提供服务，有延迟问题。如果这时不同步则会存在更新的数据等待同步，如果丢失数据会导致更多的数据丢失风险。

aof-rewrite-incremental-fsync

当bgrewriteaof在执行过程也是先把rewrite计算的结果写入到aof_rewrite_buf缓存中，然后当缓存中的数据达到一定量后会进行数据同步（把数据写入到临时文件）这个属性用于控制每次写入的数据量不超过4MB,避免单次写入数据过大引起长时间阻塞，默认是yes

aof-load-truncated

在进行aof持久化的过程中可能会出现系统突然宕机的情况，此时写入到AOF文件中的最后一条数据可能不完整，当主机启动后，redis在AOF文件不完整的情况下是否可以启动，这就取决于这个配置

yes：不完整的情况下直接从AOF文件中截断，不影响redis的启动

no：不完整的情况下不可以被截断删除，Redis无法启动

aof-timestamp-enabled

这个属性设置为yes则会开启在AOF文人年中增加时间戳的显示功能，可方便按时间对数据进行恢复。但是这个方式可能与AOF解析器不兼容，所以默认为no，不开启。

AOF持久化过程

持久化过程如下：

Redis接收到的写操作并不直接追加到磁盘的AOF文件中，而是把每一条命令按Redis的通讯协议格式暂时存到AOF缓冲区aof_buf
根据设置的数据同步策略，当同步条件满足时，把缓冲区中的数据一次性写入到AOF文件，一次性的写入减少磁盘IO次数
当磁盘的AOF文件大小达到rewrite条件时，redis-server主进程会fork出一个子进行bgrewriteaof，由这个子进行完成rewrite操作
子进程bgrewriteaof首先会对磁盘AOF文件进行rewrite计算，把计算的结果写到一个临时文件，全部写入完毕后，再rename这个临时文件为磁盘的原文件名，覆盖原文件
如果在rewrite过程中又有写操作命令追加，那么这些写操作会暂时写入到aof_rewrite_buf缓冲区。等把全部rewrite计算结果写入到临时文件后，会先把aof_rewrite_buf缓冲区中的数据写入临时文件，然后再rename为磁盘文件的名称进行文件覆盖

四、RDB与AOF对比

RDB的优势与不足

优势：文件较小，数据恢复快

不足：数据安全性较差，写时复制会降低性能，RDB文件的可读性差

AOF的优势与不足

优势：数据安全性高，AOF文件可读性强

不足：AOF文件大，写操作会影响性能，数据恢复慢

持久化技术选型

官方是推荐使用RDB与AOF的混合持久化的
若对数据安全性要求不高，则推荐使用纯RDB持久化方式
不推荐使用纯AOF持久化方式
如果Redis仅用于缓存，则无需使用任何持久化技术