当前位置：首页 > news >正文

Redis 数据持久化之AOF

news 来源：原创 2025/8/18 23:55:19

AOF（Append Only File）

在这里插入图片描述

在这里插入图片描述
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之redis重启的化就根据日志文件的内容将写指令从前往后执行一次以完成数据的恢复工作。
在这里插入图片描述
默认情况下，redis是没有开启AOF(append only file)的，开启AOF功能需要设置配置：appendonly yes。
AOF保存的是appendonly.aof文件

AOF持久化的工作流程
在这里插入图片描述

AOF缓冲区的三种写回策略
配置文件Redis.conf的定义

1.Always
同步写回：每个写命令执行完立刻同步地将日志写回磁盘
2.everysec
每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
3.no
操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

三种写回策略小总结
在这里插入图片描述
AOF配置/启动/修复/恢复
版本6与7的AOF区别

开启AOF的功能

使用默认的写回策略，每秒钟

AOF保存文件的路径设置

redis 6 中AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis,conf配置文件的dir配置
在这里插入图片描述
redis 7中的设置

redis6 中appendonlyfile有且仅有一个

到了redis 7中采用了Multi Part AOF的设计，从1到3：基础文件+增量文件+清单文件
在这里插入图片描述

文件的定义

实操
1.开启AOF的功能

2.备份AOF相关的文件，同时删除RDB相关的文件

3.执行flushdb

4. 清空以及恢复appendonly相关的文件

5.重启redis服务，数据恢复

相关的步骤总结

异常恢复

1.故意乱写改动AOF文件

vim appendonly.aof.1.incr.aof

在这里插入图片描述
2. shutdown redis然后重启
3. 查看docker 日志

存在异常，需要使用指令进行修复
redis-check-aof --fix /home/run/redis/data/appendonlydir/appendonly.aof.1.incr.aof

AOF的优势

更好的保护数据不丢失、性能高、可做紧急回复
AOF的缺点
在这里插入图片描述
相同数据集的数据而言，AOF要远大于RDB文件，恢复速率慢于RDB。AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和rdb相同

AOF重写机制
上面AOF的缺点中，提到过AOF的文件会变得越来越大，于是AOF出现了日志重写的机制，当AOF文件的大小超过所设定的峰值的时候，redis就会自动启动AOF文件的内容压缩
在这里插入图片描述

一句话：启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

相关配置
在这里插入图片描述

触发机制
自动触发：满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
什么叫只保留可以恢复数据的最小指令集？
在这里插入图片描述
案例说明

关闭混合的配置

自动触发

故意设置大key

查看appendonlyfile中文件的变化,大小从51变成240

再循环对1个k1设置，直到达到1kb的阈值

达到阈值后，重写后的日志文件从1变为2

base.aof文件中变成了12行，只保留了最小的结果集，开启了瘦身计划
在这里插入图片描述

手动重写BGREWRITEAOF

日志文件从2变成3，人工干预，没有达到阈值

AOF重写结论

AOF重写原理

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

AOF常用参数配置以及优化
在这里插入图片描述

RDB-AOF 混合持久化

在这里插入图片描述
可否共存，共存听谁的？AOF

在这里插入图片描述
数据恢复顺序和加载流程

在同时开启rdb和aof持久化时，重启是只会加载aof文件，不会加载rdb文件
在这里插入图片描述

怎么选，用哪个？
在这里插入图片描述

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据。
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

RDB+AOF混合模式
在这里插入图片描述

在这里插入图片描述

1 开启混合方式设置

设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

2 RDB+AOF的混合方式----------> 结论：RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。
简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。AOF包括了RDB头部+AOF混写

在这里插入图片描述
纯缓存模式–同时关闭RDB与AOF

AOF（Append Only File）

相关文章：