Redis RDB与AOF持久化方式详细讲解

时间:2022-11-23 zkyangll 人气:0

1.RDB持久化

首先，RDB持久化方式会产生一个经过压缩的二进制文件，Redis服务器在启动之初，通过这个文件可以还原数据库的状态。那么我们接下来看下RDB文件是如何实现保存和载入的。

1.1 RDB文件的保存

RDB文件的保存有两个命令可以实现，分别是save和bgsave,执行后都会生成新的RDB文件，区别是save会阻塞服务器的进程，直到RDB文件创建完成为止，期间服务器不能处理任何客户端的命令请求。而bgsave通过派生出一个子进程，由子进程来完成RDB文件的创建，期间服务器正常处理客户端的命令请求。其实这两个命令的底层实现方式都一样，只不过一个是主进程来做，另一个是通过子进程来完成。

在redis.conf文件中，有两个参数是和rdb的文件保存相关：

// 这个是rdb文件的名称
dbfilename dump.rdb
// 这个是rdb文件的保存路径，这是相对路径，相对于redis-server的启动路径
dir ./

1.2 RDB文件的载入

在redis服务器启动之初，会去查找有没有rdb的持久化文件存在，如果有就会自动载入，当然前提是没有开启aof持久化的功能。在rdb载入期间会，服务器处于阻塞装填，直到载入工作完全结束。

1.3 RDB持久化时服务器的状态

save命令执行期间，所有客户端命令都会被拒绝执行。

bgsave命令执行期间，客户端发送的save和bgsave命令会被拒绝执行，但是客户端发送的bgrewriteaof不会拒绝但会被阻塞，直到当前的bgsave命令执行完毕。但是值得说明的是，如果服务器在执行bgrewriteaof命令期间，客户端发送的bgsave命令会被服务器拒绝。当然这是站在性能角度考虑，否则fock出两个子进程，大量的进行磁盘的读写，会影响整个服务器的性能。

1.4 RDB持久化策略

用户可以通过配置文件给RDB的持久化设置保存策略，看一下redis.conf文件中的配置：

save 900 1
save 300 10
save 60 10000

以上的默认配置可以表示为：服务器在900秒之内，至少进行了1次的修改，在300秒之内至少进行了10次修改，在60秒之内至少进行了10000次修改。这三种策略只要满足一个，即可触发RDB的持久化。

这里需要了解一下，Redis是怎么基于这些配置策略实现自动化间歇性保存RDB文件的，还是回到RedisServer这个这个结构体的源码中看一下：

struct redisServer {
    // 数组，用于保存redis.conf配置的持久化策略
    struct saveparam *saveparams;   /* Save points array for RDB */
    // 上面这个数组的长度
    int saveparamslen;              /* Number of saving points */
    // 记录上一次持久化到现在服务器修改了多少键值对
    long long dirty;                /* Changes to DB from the last save */
    // 记录上一次RDB持久化的UNIX时间戳
    time_t lastsave;                /* Unix time of last successful save */
}

在redisServer中，有saveparams数组专门保存我们配置的持久化策略，这里使用到了saveparam这个结构体，看一下源码：

struct saveparam {
	// 这里是配置文件save的第1个参数
    time_t seconds;
    // 这里是配置文件save的第2个参数
    int changes;
};

这样，配置文件中的持久化策略就记录到了redisServer.saveparam属性中，还是会基于serverCron这个时间事件函数，100ms执行一次，每次会检查 dirty 和 lastsave 记录的修改键值对数量和时间差，是否匹配到了saveparam中配置的持久化策略，如果命中就进行新一轮的RDB持久化。

2.AOF持久化

和RDB不同，AOF是通过记录Redis服务器中执行的写命令来记录数据库状态的，类似于mysql的binlog，当然保存的内容是经过协议转换的命令。在服务器启动之初，通过载入和执行AOF文件中的命令来还原数据库的状态。

2.1 持久化的实现

在服务器执行命令之后，并不是立刻写入aof文件中，而是先写入 aof_buf缓冲区里面，这也是redisServer的一个属性结构：

struct redisServer {
    // aop缓冲区，记录服务器写入的命令
    sds aof_buf;      /* AOF buffer, written before entering the event loop */
}

我们再看一下redis.conf关于aof持久化的一个配置：

// 这个表示每次执行都会写入
# appendfsync always
// 这个表示每秒写入一次
appendfsync everysec
// 这个由操作系统决定，无法控制
# appendfsync no

AOF实现持久化的原理是这样的，客户端执行的命令会先记录到 redisServer.aof_buf 中，然后基于配置文件的appendfsync策略决定什么时候同步到AOF文件中。这里的同步也会经过两个步骤：

aof_buf 内容写入到操作系统文件缓存 pagecache；
pagecache 落盘写入到屋里磁盘设备中；

我们知道Redis是基于Reactor网络模型，不断进行事件循环，每进行一轮的事件循环，都会执行步骤1，所以从aof_buf 到 pagecache总是会发生。但是步骤2就跟appendfsync有关系了：

always表示只要步骤1发生，步骤2也会发生，所以是最安全，但是效率最慢的一个。
everysec表示步骤1发生后，步骤2每秒执行一次落盘，是效率和数据安全折中的方案，停机故障时有丢失1秒钟数据的风险。
no表示步骤1发生后，何时落盘由操作系统决定，数据丢失风险大，效率也一般，因为数据量过大，单次落盘的时间也最长。

默认配置是everysec，即每秒执行一次数据落盘保存。

2.2 文件的载入与数据还原

因为AOF文件中包含了重建数据库状态的所有写命令，所以服务器只要读入并全部执行一遍就可以完成数据库状态的还原。服务器在启动之初，会创建一个不带网络连接的伪客户端来做这件事，在载入命令完成后，这个客户端的使命就结束了。

2.3 AOF文件的重写

随着写入到AOF文件的命令越来越多，这个文件体积会越来大，会对宿主机或文件还原造成一定的影响，所以需要通过AOF文件的重写来解决文件体积膨胀的问题。

AOF文件重写并不是对现有AOF文件进行处理，而是基于数据库当前的状态来实现的。服务器会从数据库中读取键对应的值，然后用一条命令去记录键值对，代替之前可能存在的多条命令，写入到一个新的AOF文件中，这就是AOF重写功能实现的原理。需要注意的是，对于某些元素比较多的集合或者列表(默认配置是64个)，这个一条命令可能拆分成多条实现，避免造成客户端输入缓冲区溢出的情况。

和bgsave一样，AOF重写的动作也是放到子进程去执行，这样可以保证父进程可以继续处理名请求。但是这里会有一个问题，就是AOF文件重写期间，父进程处理命令请求之后，会和重写AOF文件时的数据库状态不一致。Redis解决这个问题的方法是设置一个AOF重写缓冲区，子进程一单创建并且开始重写命令之后，父进程处理的所有写命令请求都会记录到AOF重写缓冲区。当子进程重写工作完成之后，会生成一个新的AOF文件，向父进程发送一个信号，父进程在接受此信号，开始执行以下工作：

将AOF重写缓冲区的内容写入到新的AOF文件中，保证新文件和服务器当前的状态一致；
对新的AOF文件改名，并原子的替换现有的AOF文件，完成新旧文件的替换。

以上两步，父进程会造成服务器进程的阻塞，但其他时间，都不会阻塞，整个重写动作对服务器性能的影响降到了最低，以上就是bgrewriteaof命令的实现原理。

加载全部内容