1. 什么是AOF：
AOF(Append Only File)：以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)，只允许追加文件不允许改写文件，redis启动时会读取该文件重新构建数据。即：redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
但是默认情况下，redis是没有开启AOF的，开启AOF功能需要设置配置：appendonly yes
AOF保存的是appendonly.aof文件
2. AOF持久化工作流程：
3. AOF缓冲区三种写回策略：
1）always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘
2）everysec(默认)：每秒写回，每个写命令执行完先把日志写到AOF缓冲区，再每隔一秒把缓冲区内容写入磁盘
3）no：操作系统控制写回，每个写命令执行完先把日志写到AOF缓冲区，再由操作系统决定何时将缓冲区内容写回磁盘
4. AOF功能开启与配置：
1）开启AOF功能：
2）默认AOF文件每秒写回：
3）更改aof文件存储位置：
注意：更改后rdb文件不会再存储到dumpfiles下，而是也直接在myredis下
4）文件名前缀：
经过以上配置，结果如下：
base：表示基础AOF，一般由子进程重写产生，该文件最多只有一个。
incr：表示增量AOF，一般会在AOFRW开始执行时被创建，该文件可有多个。
history：表示历史AOF，由base和incr变化而来，每次AOFRW成功完成时，本次AOFRW之前对应的base和incr都会变成history，history类型的AOF会被redis自动删除
为了管理这些AOF文件，引入了manifest(清单)文件来跟踪管理这些AOF
注意：redis7之前的版本AOF文件有且仅有一个。
实际操作后，文件组织情况和我们预想的一致：
实践与证明过程：https://www.bilibili.com/video/BV13R4y1v7sP?p=40&vd_source=a579082d717747b1e99fe189207e7c29
AOF异常恢复演示：https://www.bilibili.com/video/BV13R4y1v7sP?p=41&vd_source=a579082d717747b1e99fe189207e7c29
修复命令：
redis-check-aof --fix appendonly.aof.1.incr.aof
5. AOF的优势与缺点：
5.1 优势：
1）更好的保护数据不丢失：使用默认每秒写回策略也最多只会丢失一秒钟的写入
2）性能高：AOF仅是一个附加日志，不会出现寻道问题，也不会在断电时出现损坏问题，并且多数问题redis-check-aof工具能轻松修复它
3）可做紧急恢复：例如最后一条命令是flushall，只需要打开增量文件把flushall删除，再重启服务，数据就恢复到flushall之前了
5.2 缺点：
1）AOF文件通常比相同数据集的等效RDB文件大
2）AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同
6. AOF重写机制(重点)：
6.1 重写机制的必要性：
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。
6.2 重写机制的峰值：
6.3 混合重写机制：
可以改为no，改为no则与rdb无关，清除干扰项
6.4 结论：
AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制:通过redis.conf配置文件中的auto-aof-rewrite-percentage:默认值为100，以及auto-aof-rewrite-min-size: 64mb配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
6.5 重写机制的原理：
1）在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2）与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3）当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
4）当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中。
5）重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
7. RDB与AOF混合持久化（持化双雄）：
7.1 数据恢复顺序和加载流程：
即：AOF优先级高于RDB
7.2 混合持久化中RDB持久化的必要性：
在混合持久化情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。但是RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。
7.3 混合持久化结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。
RDB镜像做全量持久化，AOF做增量持久化。
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。
简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----> AOF包括了RDB头部+AOF混写。
8. 纯缓存模式：
应用场景：做纯粹的高并发高性能缓存服务器时
关闭RDB：save ""
关闭AOF：appendonly no
同时关闭RDB+AOF，但在RDB+AOF都禁用的情况下，仍然可以使用save/bgsave命令生成rdb文件，仍可以使用bgrewriteaof命令生成aof文件。