1：AOF介绍

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据恢复工作.

AOF保存的是appendonly.aof文件

2：有关配置文件的超级有用介绍

在redis.conf配置文件中的APPEND ONLY MODE注释下,下图是redis.conf配置文件中的部分截图

#默认是no，改为yes表示打开AOF持久化

appendonly yes

#AOF持久化文件名称命名

appendfilename “appendonly-${port}.aof”

配置文件中的英文意思可以分离出两个问题

1：为什么有了RDB还要使用AOF？

默认情况下，（RDB）Redis异步地将数据集转储到磁盘上。这种模式在许多应用程序中已经足够好了，但是Redis进程或断电可能导致几分钟的写丢失(取决于配置的保存点) 。Append Only文件（AOF）是另一种持久性模式，它提供了更好的持久性。 例如使用默认数据fsync策略配置文件中(见后)复述,可以失去一秒钟ramatic事件写的像一个服务器断电,或一个写如果复述过程本身出了问题,但正确操作系统仍在运行。

2：RDB文件和AOF文件之间的关系？

可以同时启用AOF和RDB持久性，没有问题。如果在启动时启用了AOF，则Redis将加载AOF，这是具有更好持久性保证的文件。

#AOF持久化策略：每秒执行一次

appendfsync everysec

配置文件的主要英文意思是：讲了AOF的三种策略
redis默认选择everysec
在这里插入图片描述

#以性能优先，AOF允许短时间不发生重写的情况，所以设置为yes

no-appendfsync-on-rewrite yes

#AOF文件增长率，当AOF增长率达到100%时，就会自动重写AOF文件

auto-aof-rewrite-percentage 100

#AOF需要重写的最小尺寸

auto-aof-rewrite-min-size 64mb

配置文件主要英文意思是说道AOF重写，我们可以概括成以下问题
1：rewrite是什么？

AOF采用文件追加方式，文件会越米越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时， Redis会启动AOF文件的内容压缩，只保留可以恢互数据的最小指令集，可以使用命令bgrewr|teaof

2：重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重及了一个新的aof文件，（这点和快照有点类似）

3：触发机制

Redis会记录上次重写吋的A0F大小，默认配置是AOF文件大小是上次rewrite后大小的一倍且文件大子64M时触发

在这里插入图片描述

3：AOF启动/恢复/修复

正常恢复步骤
- 启动：设置Yes。修改默认的appendonly no.或为yes（去上面讲到的配置文件改）
- 将有数据的aof文件复制一份保存到自己想要的目录
- 恢复：重启redis然后重新加载
异常恢复步骤
- 启动：设置Yes。修改默认的appendonly no.或为yes（去上面讲到的配置文件改）
- 修复：Redis-check-aof --fix进行修复
- 恢复：重启redis然后重新加载

我们还是话不多说，都在图里，让大家更好知道上面的含义

举例：我们创建set数据类型，然后根据正常恢复步骤操作一遍
1：去配置文件（redis.conf）里面修改默认的appendonly no.或为yes（要学会用vim***）
2：创建key，相应的/usr/local/bin文件下会成功创建appendonly.aof文件和dumpco.rdb文件
在这里插入图片描述

3：删除dumpco.rdb文件，和appendonly.aof文件保持不变，查看是否重新启动redis，可以查询到keys值，

4：没出现值的原因是，appendonly.aof文件中有flushall，所以我们用vim修改日志文件（appendonly.aof），删除flushall，在查看是否有值
在这里插入图片描述

5：成功出现值，现在我们再来实现异常恢复工作流程，我们修改日志文件（appendonly.aof）用vim在后面打上乱码（随便打），观察是否可以启动redis，和不要删除dump.rdb文件，得到结论