【Redis】持久化机制详解之AOF

持久化其实就4个单词： write data to disk

加强数据安全

Redis支持两种不同的持久化机制，RDB和AOF，上一篇文章介绍了RDB（感兴趣的掘友可以移步 juejin.cn/post/729974... ），这篇我们来介绍AOF(￣∇￣)/

AOF

AOF（Append Only File）持久化机制是指将Redis服务器接收到的每一条写命令（例如 SET、LPUSH等）都写入到一个追加的日志文件中，以此记录所有对数据集的修改。当Redis服务器重新启动时，它会从日志文件中读取所有写命令，并重新执行它们，以此将数据集恢复到重启前的状态。该机制的优点是在故障恢复时数据丢失较少，但相对于RDB方式，AOF方式的恢复速度可能会比较慢。

启用 AOF

如果要启用Redis AOF持久化机制需要在配置文件redis.conf中开启（默认no，开启改为yes）

bash 复制代码

appendonly yes

配置路径

指定AOF日志文件的名称为

arduino 复制代码

appendfilename "appendonly.aof"

指定AOF日志文件的路径（注意这个路径是拼在上面介绍RDB时介绍的dir后面的）

arduino 复制代码

appenddirname "appendonlydir"

按照上述配置 dir / appendonlydir / appendfilename，如果dir配置的是/myredis，那么AOF日志文件的完整路径为 /myredis/appendonlydir/appendonly.aof

如果你不知道自己的配置文件在哪里，可以通过命令行或者其他工具🔧进行查询，示例如下：

arduino 复制代码

 sudo find / -name '*redis.conf*'

tips：在vim的编辑模式下，可以使用:set nu显示行号，使用/+搜索内容快速定位查询内容

AOF 文件📃

Redis 7.0 有个新特性 Multi-part AOF ，即把原本单个的AOF文件拆成了多个AOF文件，在MP-AOF中，有三种类型的AOF：

BASE：基础文（只有一个）
- appendonly.aof.1.base.rdb
INCR：增量文件（有多个）
- appendonly.aof.1.incr.aof
- appendonly.aof.2.incr.aof
HISTORY（写在mainfest：清单文件）
- appendonly.aof.mainfest

AOF 的写回策略

配置文件redis.conf中的appendfsync是配置AOF的写回策略的，即指定何时将日志数据写入磁盘，可选值为 no、always 和 everysec，默认如下：

appendfsync everysec

always 同步写会，每个写命令执行完立刻同步地将日志写回磁盘
everysec （默认项）每秒写回，每个写命令执行完只会先写到AOF文件的内存缓冲区中，每隔1秒地将日志写回磁盘（是性能和数据安全性的折中方案）
no 操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区中，有操作系统决定何时将缓冲区8内容写回磁盘

表示写期间是否同步，默认no

perl 复制代码

no-appendfsync-on-rewrite no

AOF 的重写机制

重写机制是指启动AOF文件的内容压缩，会只保留可以恢复数据的最小指令集（相当于给aof文件瘦身，压缩后的AOF占空间更小，加载速度也更快）

由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis的不断运行，AOF的文件会越来越大，文件越大，占用服务内存越大以及AOF恢复的时间需要越长，重写机制就是解决这个问题的

重写机制主要有两种实现方式：

自动执行
- 在配置文件redis.conf中进行配置，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
arduino 复制代码
```
auto-aof-rewrite-percentage 100  # 当前aof文件的大小比上次重写时增加了100%
auto-aof-rewrite-min-size 64mb   # 重写时aof文件的大小需要大于64mb
```
- 注意：需要同时满足上面两条才会触发
  - auto-aof-rewrite-percentage 表示当前aof文件的大小比上次重写时增加的百分比
  - auto-aof-rewrite-min-size 表示重写时满足的aof文件的大小
手动执行
- 使用命令bgrewriteaof

总的来说，AOF重写机制并不是对原文件进行重新整理🔄，而是直接读取服务器现有键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件然后去替换原来的AOF文件。可以降低文件的占用空间，同时更小的AOF也可以更快的被Redis加载

如何修复AOF文件📃

如果因为网络等问题redis突然挂机等问题导致AOF写入出错，重启redis时，会进行AOF文件的载入，发现redis无法启动，报"拒绝连接"的异常

可以使用redis-check-aof --fix命令来尝试修复（只修复incr的文件即可），会把不符合其语法的内容清空

优点

使用AOF更加持久
- 可以定制fsync策略，最多丢失1秒数据
AOF是个仅附加日志，不会出现寻道问题，也不会出现在断电时出现损坏的问题，即使出于某种原因（磁盘已满等）日志以写一半的命令结尾，也可以使用redis-check-aof工具进行修复
当AOF变得太大时，Redis能够在后台自动重写AOF
- 这个重写个是完全安全的，因为当Redis继续附加到旧文件时，会使用创建当前数据集所需要的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis就会切换两者并开始附加到新的那一个
AOF以利于理解和解析的格式依次包含所有的操作日志。即使对数据库进行了清空操作，只要在此期间没有执行日志重写，就可以通过停止服务器、删除最新的清空操作，重新启动Redis来恢复数据集

总的来说就是：更好的保护数据不丢失、性能高、可做紧急恢复

缺点

AOF通常比相同数据集的等效RDB文件更大，并且恢复速度慢于RDB
AOF运行效率要慢于RDB（RDB是内核级别的命令），一般来讲如果fsync（同步策略）设置为每秒，性能较高，不设置则和RDB一样
- 但RDB能够提供关于延迟的更多保证

RDB & AOF 优先级

由配置文件（下图）可以看出，RDB和AOF是可以共存 的，并且当两者都被开启时，Redis会优先加载AOF文件

同时开启时的加载流程

同时开启RDB和AOF持久化时

重启时判断是否存在AOF文件，
1. 存在，加载AOF文件 -> 3
2. 不存在 -> 2
判断RDB文件是否存在
1. 存在，加载RDB文件 -> 3
2. 不存在 -> 3
完成启动（成功/失败）

终极方案：RDB + AOF 混合方式

结合RDB和AOF各自的优点：快速加载+避免丢失过多的数据

设置方式：

开启appendonly

bash 复制代码

appendonly yes

开启aof-use-rdb-preamble

bash 复制代码

aof-use-rdb-preamble yes

RDB做全量持久化，AOF做增量持久化，即先使用RDB进行快照存储，然后用AOF持久化所有写操作，当重写策略满足或者手动触发重写的时候，会将RDB中没有，只被AOF持久化的写操作（即最新的数据）存储为新的RDB记录📝，简单理解就是，混合模式下生成的AOF文件包含两部分：一部分是RDB文件的内容，另一部分是在重写时，由AOF储存的写操作生成的RDB纪录