Redis（1）——持久化

一、RDB

[1.1 RDB的触发方式](#1.1 RDB的触发方式)

[1.2 bgsave的流程](#1.2 bgsave的流程)

[1.3 实际执行](#1.3 实际执行)

[1.4 RDB的优缺点](#1.4 RDB的优缺点)

二、AOF

[2.1 开启AOF](#2.1 开启AOF)

[2.2 AOF文件写入](#2.2 AOF文件写入)

[2.3 AOF重写机制](#2.3 AOF重写机制)

[2.4 AOF重写的流程](#2.4 AOF重写的流程)

[2.5 混合持久化](#2.5 混合持久化)

[2.6 数据恢复](#2.6 数据恢复)

Redis的直观的特性就是相比数据库更快，效率更高，这是因为Redis的数据存储在内存上，所以我们可以做到快速读写，但是如果数据值存放到内存上是不持久的，如果主机或进程重启，数据就不存在了。

所以我们Redis的数据既要存储在内存上以此来实现"快"，同时也要存储到硬盘上，以此来实现持久化。这样如果Redis重启后也可以从硬盘中读取数据来恢复内存中的数据

那么Redis该如何把数据存储到硬盘上呢，Redis向我们提供了两种策略

RDB：Redis DataBase ：定期备份

AOF：Append Only File：实时备份

一、RDB

RDB定期把我们Redis内存中的数据，都写入到硬盘中，生成一个"快照"。可以理解为Redis给内存当前存储的数据赶紧拍个照片生成一个文件，存储到硬盘中，后续如果Redis重启，就可以通过硬盘里的"快照"文件恢复内存的数据

1.1 RDB的触发方式

1. 手动触发

我们可以通过在Redis命令行中输入指定命令来触发快照的生成

save ：执行save的时候，Redis就会把让所有资源都用来进行"快照生成"操作，此时就会阻塞Redis的其他命令，所以我们一般不建议使用save命令
bgsave ：bg就是background的意思，所以这个"快照生成"的过程是在背后进行的，不会阻塞Redis，也就不会影响Redis处理别的命令

2. 自动触发

除了在Redis客户端命令行输入指令的方式，我们还可以在Redis的配置文件中进行配置，让Redis在一定时间内自动进行RDB

在etc/redis文件夹中有一个redis.conf配置文件

文件中这里的配置就是对RDB的自动触发配置

3600 1：在3600秒（1小时）至少有1次数据修改

300 100：在300秒（5分钟）至少有100次数据修改

60 10000：在60秒（1分钟）至少有10000次数据修改

如果觉得这个配置不符合我们的业务需求，也可以在这个配置文件中进行修改

同时我们可以在这个配置文件中查看快照文件的位置

我们进入快照文件查看，这个rdb文件是一个二进制文件，内存中的数据以二进制的形式保存到这个文件中，redis重启的时候就会去读取这个文件，从而恢复内存中的数据，如果我们对这个文件进行了修改，redis服务可能就无法启动了

1.2 bgsave的流程

当我们触发bgsave命令时，父进程首先会判断当前是否有其他正在执行的子进程，如果存在bgsave直接返回，不做任何操作
如果没有其他子进程，父进程调用fork()，就会创建一个子进程，这个子进程会拥有父进程的所有信息，可以说父进程和子进程是相同的，子进程的物理内存是通过写时复制机制和父进程共享
- 写时复制：如果是读操作的命令，子进程仍然和父进程共享内存空间，但是如果客户端输入写操作的命令，父进程就会申请一块新的空间，在这个新的空间进行修改。
- 比如：父进程有个变量n=10，调用fork(),子进程也会有一个变量n=10，并且和父进程的n变量共享一块内存空间，父进程还要继续相应客户端的命令，如果客户端输入了写操作的命令，修改n=20，此时父进程就会申请一块新空间存储n=20，子进程的n还是等于10，并且跟父进程也不是共享一块空间了
- 根据结果来说，就是子进程只会拥有fork()调用之前的所有数据。
fork()调用之后，子进程遍历当前内存所有的数据，按照RDB文件的格式，将数据写入一个临时文件
写入完成之后，再把这个文件重命名为dump.rdb，替换原来旧的RDB快照文件

1.3 实际执行

先查看dump.rdb详情信息，inode是800816，文件内部的信息如下

我们现在一个客户端上设置三个键值对，此时我们去另一个客户端查看一下快照文件

可以看到dump.rdb的详情信息，他的inode此时是802428，和之前相同，可见并没有把我们直接设置的键值对储存起来，这是因为我们还没有满足自动触发rdb的条件

此时我们手动触发rdb

再去查看一下快照文件的信息，发现inode已经和之前不同了，说明确实进行了快照文件的替换

我们进入文件查看，发现里面确实存储了我们之前设置的键值对

我们再设置一个key4键值对

设置完后我们进入rdb快照文件，里面仍只有三个键值对，并没有我们刚刚设置的key4

此时我们退出客户端，重新启动redis服务，再进入客户端，发现key4竟然还是保存的

我们再进入rdb文件，发现key4保存在文件中了

说明，自动触发rdb快照除了配置redis.conf文件，在重新启动服务器的时候，redis也会自动触发rdb机制，保存快照文件

上述重启redis服务器的方式是正常关闭服务器的方式，我们再试一下非正常关闭服务器

先设置键值对key5

然后进行查看redis服务的进程号

直接使用kill -9命令删除进程，这样属于非正常关闭，我们再进入redis客户端，发现key5并没有存储成功

1.4 RDB的优缺点

优点

RDB是一个二进制文件，代表Redis在某个时间点上数据快照，非常适用于备份等场景
Redis加载RDB恢复数据远远快于AOF的方式

缺点

RDB存储数据没有办法做到实时持久化，上述提到的自动触发RDB也是有时间限制的，满足一段时间内固定次数修改才会触发RDB，那么如果还未触发之前服务器就挂了，这段时间内我们的数据就丢失了
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性会有风险

二、AOF

AOF持久化是以独立日志的方式记录每次写命令，AOF文件是文本文件，重启时再重新执行AOF文件的命令达到恢复数据的目的。相比于RDB一段时间记录数据，AOF解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。如果将RDB比作是照片，记录了十点和十一点两张照片，那么AOF就是摄影，拍摄了十点到十一点一个小时的内容，所以保证了实时性