Redis数据持久化—RDB持久化与AOF持久化
Redis数据持久化—RDB持久化与AOF持久化
大家好，我是白泽，今天讲一下Redis的持久化，大家都知道Redis数据库之所以快，很大的原因是因为它运行在服务器的内存中，但一旦服务器进程退出，服务器中的数据库状态也会消失，为了解决这个问题，Redis提供了两种数据持久化的机制：这俩本质上都是将数据库状态保存到磁盘里，然后下次取出来加载到内存中还原数据库，但是实现角度有所不同
RDB持久化
RDB持久化可以手动执行，也可以配置定期自动执行，该功能可以将某个时间点上的数据库的状态保存到一个RDB文件中（说白了就是数据库中一个个的键值对），只要导入RDB文件，就能还原到之前时刻数据库的状态
RDB文件的创建
有两个Redis命令可以用于生成RDB文件，一个时SAVE，一个是BGSAVE
- SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕，在服务器进程阻塞期间，服务器不能处理任何命令请求
- BGSAVE命令会派生一个子进程，由子进程负责创建RDB文件，服务器进程继续处理命令请求
RDB文件的载入
只要Redis服务器在启动时检测到RDB文件的存在，就会自动载入RDB文件，需要提一下：后面要讲的AOF持久化也会对应生成AOF文件，由于AOF文件更新的频率通常比RDB文件更高，也就意味着AOF文件中保存着更近期数据库的状态，因此如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态
自动间隔性保存
上面提到，BGSAVE命令可以不阻塞服务器进程而通过子进程去执行，所以Redis允许用户通过设置服务器的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令，举个例子如果我们向服务器提供如下配置：
save 900 1
save 300 10
save 60 10000
那么只要满足下面条件中的任意一个，BGSAVE命令就会被执行：
- 服务器在900秒内，对数据库至少执行了1次修改
- 服务器在300秒内，对数据库至少执行了10次修改
- 服务器在60秒内，对数据库至少执行了10000次修改
当然，save选项的默认配置就是上面给出的3条配置
检查保存条件是否满足
Redis服务器维护着一个dirty计数器以及一个lastsave属性，dirty计数器记录距离上一次成功执行SAVE或GBSAVE命令之后，服务器对数据库状态进行了多少次修改，lastsave是一个UNIX时间戳，记录上一次SAVE或BGSAVE的时刻
Redis服务器周期性操作函数serverCron默认每100毫秒就会执行一次，该函数用于对正在运行的数据库进行维护，它其中的一项工作就是检查save选项设置的保存RDB文件的条件是否满足，满足就执行BGSAVE命令（配合dirty和lastsave就可以实现判断）
AOF持久化
RDB文件保存的是数据库某个时刻的状态，说白了也就是一个个的键值对；AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的（好比RDB将数据库的结果存了起来，而AOF将增、删、改语句存了起来，还原时RDB是直接拷贝一份结果，AOF是再执行一遍各个语句得到结果）
AOF持久化的实现
-
命令追加：
当AOF持久化功能处于打开状态时，服务器在执行一个写命令后，将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾：
struct redisServer {
//...
sds aof_buf; //AOF缓冲区，还记得sds么，简单动态字符串~
//...
}
-
AOF文件的写入与同步：
Redis服务器进程就是一个事件循环，这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而事件事件则负责像serverCron函数这样需要定时运行的函数
因为服务器在处理文件事件时可能会执行写命令，使得一些内容被增加到aof_buf缓冲区里，所以服务器在每次结束一个事件循环之前， 都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中的内容写入和保存到AOF文件中
flushAppendOnlyFile函数的行为由服务器配置的appendfsync的值决定，如下表：
AOF文件的载入与数据还原
因为AOF文件里包含了重建数据库状态所需要的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里的写命令，就可以还原服务器关闭之前数据库的状态，Redis读取AOF文件并还原过程为：创建一个不带网络连接的伪客户端，用该客户端执行AOF文件中的写命令，还原数据库
AOF重写的概念
因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，随着服务器运行时间的流逝，AOF文件中的内容会越来越多，举个极端的例子，服务器执行了一亿次写操作，操作的内容就是对同一键的值修改了一亿次，显然其中只有最后那条操作是有效的，其余都是冗余的数据，而此时AOF文件将所有写操作都记录了下来，使得AOF文件过大，服务器开销巨大
为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写功能，通过该功能，Redis服务器可以创建一个新的AOF文件来代替现有的AOF文件，新旧两个AOF文件保存的数据库状态相同，但新AOF文件不会包含任何冗余命令
AOF文件重写的实现
AOF文件的重写并不需要对现有的AOF文件进行任何读取操作，这个功能是通过读取服务器当前数据库的状态来实现的，比如我对一个集合键执行了10次插入操作，那么相比记录10条插入命令，直接记录一条插入10个数据的集合的命令即可
总结原理就是：首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令
AOF后台重写
因为Redis是单线程模型，AOF文件重写需要扫描整个Redis数据库，将使得服务器被长时间占用去执行AOF文件重写，使得服务器失去响应，因此Redis将AOF文件重写程序放入子进程中执行
一个问题：
在子进程进行AOF文件重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的AOF文件所保存的数据库状态不一致
解决方案：
针对上述问题，Redis服务器设置了一个AOF重写缓冲区，在服务器创建AOF文件重写子进程后开始使用，将期间服务器接收到的新的写命令除了发给AOF缓冲区aof_buf之外，也发送到AOF重写缓冲区堆积，在子进程完成AOF文件重写之后，将AOF重写缓冲区中的写命令追加到重写完成的新AOF文件中，此时新的AOF文件所保存的数据库状态和服务器当前的数据库状态一致
最后，对新的AOF文件进行改名，原子地覆盖现有的AOF文件，完成新旧两个AOF文件的替换
