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

1.RDB持久化

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

1.1 RDB文件的保存

 RDB文件的保存有两个命令可以实现,分别是savebgsave,执行后都会生成新的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命令执行期间,客户端发送的savebgsave命令会被拒绝执行,但是客户端发送的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命令的实现原理。

作者:zkyangll原文地址:https://blog.csdn.net/qq_35850405/article/details/127944005

%s 个评论

要回复文章请先登录注册