Redis面试_4

AOF持久化

AOF(Append-Only-File)持久化: 保存Redis服务器所执行的写状态来记录数据库,默认是关闭的,且其文件名为appendonly.aof.

可以通过conf set appenonly yes使得AOF持久化生效,也可以去配置文件中修改.

RDB持久化相当于备份数据库状态,而AOF持久化是备份数据库接收到的指令,所有被写入AOF的命令都是以Redis的协议格式来保存的.

1. 记录下除了查询以外的所有变更数据库状态的指令.
2. 以append的形式追加保存到AOF文件中(增量).

appendfsync配置

AOF持久化的appendfsync配置,相当于RDB持久化的SAVE m n配置

一共有三种配置方式:

1. appendfsync everysec(默认): 表示每隔一秒就将数据写入到AOF文件中.
2. appendfsync always: 表示一旦缓冲区的内容发生变化,就总是及时的把缓冲区的内容写入到AOF文件中.
3. appendfsync no: 表示将数据写入AOF的操作交给操作系统来决定,一般都会等缓冲区填满才写入到内存中去.

AOF文件不断增大的解决办法

比如当我们从0加到100,我们其实只需要保存最后一个值就可以了,但是AOF会记录下所有的运算记录,这就可以用到日志重写.

日志重写解决了AOF文件大小不断增大的问题,同样用到了写时复制,其原理如下:

1. Redis调用fork()函数,创建一个子进程.
2. 子进程把新的AOF文件(当前内存中的数据,不读取原来文件中的数据)写到一个临时文件里,不依赖原来的AOF文件.
3. 主进程持续将新的变动同时内存和原来的AOF里.
4. 主进程获取子进程重写AOF的完成信号,往新的AOF同步增量变动(也就是将步骤3中内存中的buffer数据追加到AOF文件中) .
5. 使用新的AOF文件替换掉就得AOF文件.

日志重写可以手动触发,也可以自动触发

1. 手动触发: 通过执行BGREWRITEAOF指令触发aof重写.
2. 自动触发: 忽略了,不怎么考,我就懒得记,大家百度一哈子.

Redis数据的恢复

RDB和AOF共存情况下的恢复流程

由图可知,Redis服务器启动时,会先检查是否存在AOF文件
如果存在,就直接加载AOF文件,忽略RDB文件;
如果不存在,就尝试加载RDB文件.

RDB和AOF的优缺点

• RDB优点: RDB文件本质上是一份内存快照,保存了创建RDB文件那个时间点的Redis全量数据,文件小,恢复快.
• RDB缺点: 由于RDB保存的是某个时间点的快照数据,所以无法用来保存RDB创建后的增量数据.
• AOF优点: AOF文件本质上是一份执行日志,保存了所有对Redis进行更改的指令,可读性高,适合保存增量数据,数据不易丢失.
• AOF缺点: 文件体积大,恢复时间长.

Redis通过RDB-AOF混合模式实现持久化(目前比较推荐的方式)

混合模式持久化在Redis4.0版本以后开始支持并且作为了默认配置,结合两者优点,既可以进行全量备份,也可以保存增量.

混合模式持久化过程: 先以RDB格式写入全量数据,然后子进程通过管道从父进程获取增量数据并缓存下来到AOF文件中.

这样既可以提高重写恢复速度,也可以减少文件大小, 同时还可以保证数据的完整性.

这样之后,AOF文件是RDB格式的全量数据,后半段是Redis命令格式的增量数据.

RDB-AOF混合模式持久化总结

通过BGSAVE做镜像全量持久化,AOF做增量持久化,在Redis服务器重启时,就可以完整恢复之前的状态了.