九. Redis 持久化-AOF(详细讲解说明，一个配置一个说明分析，步步讲解到位 2)

九. Redis 持久化-AOF(详细讲解说明，一个配置一个说明分析，步步讲解到位 2)

1. Redis 持久化 AOF 概述

Redis 持久化-AOF 官方文档地址： https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

​

AOF 是什么？

1. AOF(Append Only File)
2. 以日志的形式来记录每个写 操作(增量保存) ，将 Redis 执行过的所有写指令记录下来(比如 set/del 操作会记录)，读操作 get 不记录）
3. 只许追加文件但不可以改写文件
4. Redis 启动之初会读取文件重新构建数据
5. redis 重启的话就根据日志文件的内容将写指令从前到后执行一次，以完成对数据的恢复工作。

2. AOF 持久化流程

上流程图解读：

1. 客户端的请求写命令会被 append 追加到 AOF 缓冲区内
2. AOF 缓冲区根据 AOF 持久化策略(always，everysec，no) 将操作 sync 同步到磁盘的 AOF 文件中
3. AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量
4. Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

3. AOF 的配置

关于 AOF 的配置和 RDB 的配置都是一样的，都是在 /etc/redis.conf 文件当中配置的。

在 redis.conf 中配置文件名称，默认为 appendonly.aof 文件，作为备份快照文件的。

设置为 no 将 AOF 持久化开启。

appendonly yes

需要将 Redis 服务器关闭，再重新启动 Redis 服务器，配置才会生效。

[root@localhost ~]# redis-server /etc/redis.conf
[root@localhost ~]# redis-cli

重点：

• AOF 文件的保存路径，同 RDB 的路径是一致的配置，都是存储到同一个地方的。RDB 配置的路径是在哪里 ,AOF 配置的路径也就是在哪里。
• AOF 和 RDB 同时开启，系统默认取 AOF 的数据 。当开启 AOF 后，Redis 从 AOF 文件取数据。

AOF 演示：

**AOF ** 只对 set[添加/修改] 和 del 操作记录下来了。

get[读]操作，并没有记录下来。

4. AOF 启动/修复/恢复

基本说明：

AOF 的备份机制和性能虽然和 RDB 不同，但是备份和恢复的操作同 RDB 一样，都是拷贝备份文件，需要恢复时再拷贝到 Redis 工作目录下，启动系统即加载。

正常恢复：

1. 修改默认的 appendonly no ,改为 yes
2. 将有数据的 aof 文件定时备份，需要恢复时，复制一份保存到对应目录(查看目录: config get dir )
3. 恢复：重启 Redis 然后重新加载。
4. 这里就演示了，和前面的 RDB 备份/恢复是一样的，大家可以移步至🌟🌟🌟

[root@localhost ~]# cp appendonly.aof appendonly.aof.bak # 复制拷贝

异常恢复：

1. 如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复
2. 建议先: 备份被写坏的 AOF 文件
3. 恢复：重启 redis，然后重新加载

演示异常恢复：

这里我们将 appendonly.aof 文件进行一个刻意的修改，造成数据的异常。

[root@localhost ~]# redis-check-aof --fix /root/appendonly.aof # 修复文件（已经是在root 目录下了）
[root@localhost ~]# ./redis-check-aof --fix appendonly.aof # 修复文件（已经是在root 目录下了，所以不用使用 /root 指定位置）

同步频率设置：

配置位置：

appendfsync everysec 配置说明：

1. appendfsync always 始终同步，每次 Redis 的写入都会立刻计入日志；性能较差但数据完整性比较好。
2. appendfsync everysec 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能会丢失。
3. appendfsync no 表示 Redis 不主动进行同步，把同步时机交给操作系统。更多详细内容https://baijiahao.baidu.com/s?id=1740774723808931509&wfr=spider&for=pc

5. Rewrite 压缩

1. AOF 文件越来越大，需要定期对 AOF 文件进行重写达到压缩。
2. 旧的 AOF 文件含有无效命令被忽略，保留最新的数据命令，比如 ：set a a1；set a b1；set a c1； 保留最后一条指令就可以了。
3. 多条写命令可以合并为一个，比如 ： set a c1 b b1 c c1
4. AOF 重写降低了文件占用空间
5. 更小的 AOF 文件可以更快的被 Redis 加载。

重写触发配置：

1. 手动触发：

直接调用 bgrewriteaof 命令：

127.0.0.1:6379> bgrewriteaof

2. 自动触发：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-min-size : AOF 文件最小重写大小，只有当 AOF 文件大小大于 该值的时候才能重写，默认配置 64MB。

auto-aof-rewrite-percentage ：当前 AOF 文件大小和最后一次重写的大小之间的比率等于或者大于指定的增长百分比，比如 100 代表当前 AOF 文件时上次重写的两倍时候才重写。

注意：

• 系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size
• 如果 Redis 的AOF当前大小 >= base_size+base_size * 100%(默认) 当前大小 >= 64mb(默认) 的情况下，Redis 会对 AOF 进行重写。

6. AOF 持久化小结(优势 & 劣势)

优势：

1. 备份机制更稳健，丢失数据概率更低。
2. 可读的日志文本，通过操作 AOF 稳健，可以处理误操作 。

劣势：

1. 比起 RDB 占用更多的磁盘空间(会记录数据和指令)
2. 恢复备份速度比 RDB 更慢(因为每次恢复数据是重新执行我们备份在appendonly.aof 文件当中的指令，而 RDB 是存储了数据，直接拿出来，所以比 RDB 更慢一些)。
3. 每次读写都同步的话，有一定的性能压力。

7. 选择 RDB 还是 AOF ?

选择 RDB 还是 AOF，官方文档说明： https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

• 官方推荐两个都启用
• 如果只做缓存：如果你只希望你的数据在服务器运行的时候存在, 你也可以不使用任何持久化方式

8. 最后：

“在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时刻再次相遇。”