Redis设计与实现2.2:数据持久化
数据持久化
这是《Redis设计与实现》系列的文章,系列导航:Redis设计与实现笔记
RDB持久化
RDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件,通过该文件可以还原生成 RDB 文件时的数据库状态。
基本使用
另外,由于AOF文件更新更频繁,所以:
-
优先使用AOF进行还原
-
只有AOF关闭时才会进行RDB备份
-
BGSAVE 虽然是非阻塞的,但是在进行时会拒绝掉 SAVE、BGSAVE命令,BGREWRITEAOF 会被推迟到执行完再执行。
-
而如果 BGREWRITEAOF 正在执行,则 BGSAVE 会被拒绝。
自动保存功能
设置
save 900 1
save 300 10
只要满足如下条件的一个,BGSAVE就会被执行:
- 900s内,对数据库至少进行了1次修改
- 300s内,对数据库至少进行了10次修改
原理
上述的配置信息保存的结构如下图所示:1
另外,程序还需要记录对应这两个配置在数据库中对应的信息:
- dirty计数器:记录距离上一次成功执行 SAVE 命令或者 BGSAVE 命令之后,服务器对数据库状态进行了多少次修改
- lastsave:记录上一次成功执行备份的UNIX时间戳
Redis服务器周期性操作函数 serverCron
默认每 100 毫秒执行一次,用于对正在运行的服务器进行维护,其中一项工作就是检查 save 选项保存的条件是否满足。
RDB文件结构
这里只给出了一个简单的关系图,如果想要了解具体的内容请阅读原书。
AOF持久化
AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库的状态的。
写入AOF的步骤
三步骤:
- 命令追加:服务器执行完一个写命令后,会追加到服务器状态的
aof_buf
缓冲区的末尾 - 文件写入:serverCron 函数在定时运行的时候会调用
flushAppendOnlyFile
函数,考虑是否将上述缓冲区的内容写入和保存到 AOF 文件中 - 文件同步
写入和同步:
为了提高文件的写入效率,在现代操作系统中,当用户调用 write 函数时会先将数据保存在一个内存缓冲区里,等超过一定的时限或空间被填满再写入磁盘。
这样虽然提高了效率,但是可能会影响安全性。
为此,系统提供了
fsync
和fdatasync
可以强制让操作系统立刻同步到硬盘中。
appendfsync
参数配置:
- always:总是写入并同步
- everysec:每秒进行写入并同步
- no:写入但不同步
载入AOF的步骤
(很直观的步骤)
- 创建一个不带网络连接的伪客户端
- 从AOF文件中分析并读取一条写命令
- 使用伪客户端执行该命令
- 重复上述步骤,直到所有命令完成
AOF 重写
为什么?
由于 AOF 时通过保存被执行的写命令来记录数据库状态的,所以随着服务器运行时间的流逝,AOF 文件的内容会越来越多,文件体积也会越来越大,需要加以控制,以免对 Redis 服务器、甚至整个宿主机造成影响。
怎么做?
BGREWRITEAOF
命令进行 AOF 重写。
重写的实现?
最简单的方法是通过分析 Redis 中的数据,然后生成相应的插入指令,而不是通过分析之前的命令来判断哪些可以被跳过。
后台重写
为了在重写过程中也能处理请求,可以采用后台重写的方式。当然在重写的过程中数据也可能发生变化,所以要设置一个 AOF 重写缓冲区。(类似主从复制时的操作)
当子进程完成 AOF 重写工作后,他会向父进程发送一个信号,父进程在接到该信号之后,就会调用一个信号处理函数(阻塞),并执行如下工作:
- 将 AOF 重写缓冲区的内容写入到新的 AOF 文件中
- 对新的 AOF 文件进行改名,原子地覆盖现有的 AOF 文件