AOF

AOF

基础概念

以日志的形式记录了每个写操作

在redis重新运行时,会将这些操作重新执行一遍

文件形式:appendonly.aof

开启AOF需要更改配置文件:appendonly:yes

AOF主要流程

用户--->redis--->aof缓存区---->aof

aof--->redis

三种写回策略

1. always
   1. 优点:同步写回,数据基本不丢失
   2. 缺点:反复IO,性能影响大
2. everysec
   1. 优点:性能适中
   2. 缺点:宕机时丢失1秒内的数据
3. no
   1. 优点:性能好
   2. 缺点:依赖操作系统控制写回,数据丢失风险大

AOF功能开启的配置

6vs7

生成文件地址:

1. 6是直接和rdb同目录(即我们配置好的dir)
2. 7改变为在该dir之后又有一个子文件夹/appendonlydir然后存放在子文件夹中

aof文件类型:

1. 6有且仅有一种
2. 7有了三种,base aof和incr aof和history aof(由base和incr变化而来,在重新写回后,这次写回之前对应的base和incr成为history,history类型的aof会被redis自动删除)
   1. 同时为了管理这些aof,该子文件夹下还有个manifest(清单)文件来管理这些aof

异常恢复

linux执行redis-check-aof --fix 对应的incr.aof

即可恢复,由于他由对应的语法格式,所以应该是删除不符合语法规则的语句

最差情况,要么丢失一条修改操作,要么丢失一秒的操作

aof的优缺点

寻道问题:

寻道是指在文件中查找特定的命令。Redis的AOF持久化机制不需要寻道，因为它是将命令追加到文件末尾，而不是在文件中查找特定的命令。

优势

1. 性能高
2. 可以回滚到之前的版本(可做紧急恢复)
3. 更好地保护数据不丢失

劣势

1. 相同情况下aof文件比rdb文件占用空间大,aof文件加载进内存的速度没有rdb文件快
2. aof运行效率慢于rdb,每秒同步策略效率较好,不同步效率与rdb相同(就是那三种写回策略,毕竟你aof间隔一小会时间就要写入硬盘,可定效率慢)

触发AOF重写

1. 满足自动触发条件(默认是上次重新进度为100%且incr aof文件达到64mb才可以)
2. 手动:bgrewriteaof

AOF重写机制重要原理

由于弹幕中,频繁弹到阳哥可能说的有误,所以这边是看官网总结的(7版本)

1. 当AOF重写时,Redis父进程会打开一个新的incrAOF文件来记录新的写入操作
2. 子进程会执行原定的重写逻辑并生成新的baseAOF
3. 在这过程中Manifest文件也开始跟踪新的base和incr
4. 当他们准备好时,会进行替换操作(即之前的base和incr成为history版本,被新版本替换掉,同时数字部分会叠加),使manifest文件生效

为了避免因AOF重写重复失败和重试而创建许多增量文件的问题，Redis引入了AOF重写限制机制，确保失败的AOF重写将以越来越慢的速度重试。