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

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;   
    // 上面这个数组的长度
    int saveparamslen;              
    // 记录上一次持久化到现在服务器修改了多少键值对
    long long dirty;                
    // 记录上一次RDB持久化的Unix时间戳
    time_t lastsave;                
}

 在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;      
}

 我们再看一下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命令的实现原理。

到此这篇关于Redis RDB与AOF持久化方式详细讲解的文章就介绍到这了,更多相关Redis RDB与AOF内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！