AOF
基础概念
以日志的形式记录了每个写操作
在redis重新运行时,会将这些操作重新执行一遍
文件形式:appendonly.aof
开启AOF需要更改配置文件:appendonly:yes
AOF主要流程
用户--->redis--->aof缓存区---->aof
aof--->redis
三种写回策略
- always
- 优点:同步写回,数据基本不丢失
- 缺点:反复IO,性能影响大
- everysec
- 优点:性能适中
- 缺点:宕机时丢失1秒内的数据
- no
- 优点:性能好
- 缺点:依赖操作系统控制写回,数据丢失风险大
AOF功能开启的配置
6vs7
生成文件地址:
- 6是直接和rdb同目录(即我们配置好的dir)
- 7改变为在该dir之后又有一个子文件夹/appendonlydir然后存放在子文件夹中
aof文件类型:
- 6有且仅有一种
- 7有了三种,base aof和incr aof和history aof(由base和incr变化而来,在重新写回后,这次写回之前对应的base和incr成为history,history类型的aof会被redis自动删除)
- 同时为了管理这些aof,该子文件夹下还有个manifest(清单)文件来管理这些aof
异常恢复
linux执行redis-check-aof --fix 对应的incr.aof
即可恢复,由于他由对应的语法格式,所以应该是删除不符合语法规则的语句
最差情况,要么丢失一条修改操作,要么丢失一秒的操作
aof的优缺点
寻道问题:
寻道是指在文件中查找特定的命令。Redis的AOF持久化机制不需要寻道，因为它是将命令追加到文件末尾，而不是在文件中查找特定的命令。
优势
- 性能高
- 可以回滚到之前的版本(可做紧急恢复)
- 更好地保护数据不丢失
劣势
- 相同情况下aof文件比rdb文件占用空间大,aof文件加载进内存的速度没有rdb文件快
- aof运行效率慢于rdb,每秒同步策略效率较好,不同步效率与rdb相同(就是那三种写回策略,毕竟你aof间隔一小会时间就要写入硬盘,可定效率慢)
触发AOF重写
- 满足自动触发条件(默认是上次重新进度为100%且incr aof文件达到64mb才可以)
- 手动:bgrewriteaof
AOF重写机制重要原理
由于弹幕中,频繁弹到阳哥可能说的有误,所以这边是看官网总结的(7版本)
- 当AOF重写时,Redis父进程会打开一个新的incrAOF文件来记录新的写入操作
- 子进程会执行原定的重写逻辑并生成新的baseAOF
- 在这过程中Manifest文件也开始跟踪新的base和incr
- 当他们准备好时,会进行替换操作(即之前的base和incr成为history版本,被新版本替换掉,同时数字部分会叠加),使manifest文件生效
为了避免因AOF重写重复失败和重试而创建许多增量文件的问题，Redis引入了AOF重写限制机制，确保失败的AOF重写将以越来越慢的速度重试。