编辑
2023-10-23
缓存中间件
0
请注意,本文编写于 208 天前,最后修改于 51 天前,其中某些信息可能已经过时。

目录

RDB和AOF
AOF文件过大怎么办?

RDB和AOF

​ Redis有两种持久化方式,RDB和AOF。

RDB

​ 该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件,通过该文件可以还原生成RDB文件时的数据库状态。服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止。

​ RDB有手动触发和自动触发两种方式。手动触发可以使用bgsave命令,使用bgsave命令后,Redis会执行fork创建子进程完成RDB过程。自动触发则是需要配置save相关的配置,如“save m n”,表示m秒内数据集存在n次修改时,自动触发bgsave。

RDB的优缺点

优点:RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照,非常适合用于备份,全量复制等场景。比如每6小时执行bgsave备份,并将RDB文件拷贝到远程机器或者文件系统中,用于灾难恢复。Redis加载RDB恢复数据远远快于AOF方式。

缺点:没有办法做到实时持久化/秒级持久化。bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。

另外值得一提的是,因为AOF文件的更新频率通常比RDB文件的更新频率高,所以:

​ 如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据库状态。

​ 只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

AOF

​ AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的,就跟记流水一样,一条一条的记录命令到文件中。AOF持久化保存数据库状态的方法是将服务器执行的SET、SADD、RPUSH三个命令保存到AOF文件中。被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的,因为Redis的命令请求协议是纯文本格式。

AOF文件过大怎么办?

AOF重写

​ AOF持久化是通过保存被执行的写命令来记录数据库状态的,所以随着服务器运行时间的流逝,AOF文件中的内容会越来越多,文件的体积也会越来越大,如果不加以控制的话,体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响,并且AOF文件的体积越大,使用AOF文件来进行数据还原所需的时间就越多。

​ 为了解决AOF文件体积膨胀的问题,Redis提供了AOF文件重写(rewrite)功能。通过该功能,Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

​ AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作,这个功能是通过读取服务器当前的数据库状态来实现的。就是遍历数据库,获取Redis所有类型的键,再拼成一条命令去记录键值对,代替之前记录这个键值对的多条命令。

​ Redis会将AOF重写程序放到子进程里执行,但是使用子进程也有一个问题需要解决,因为子进程在进行AOF重写期间,服务器进程还需要继续处理命令请求,而新的命令可能会对现有的数据库状态进行修改,从而使得服务器当前的数据库状态和重写后的AOF文件所保存的数据库状态不一致。

Redis是怎么处理这个问题的呢

​ 为了解决这种数据不一致问题,Redis服务器设置了一个AOF重写缓冲区,这个缓冲区在服务器创建子进程之后开始使用,当Redis服务器执行完一个写命令之后,它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。

本文作者:whitebear

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!