AOF开启
在conf文件中，打开即可
AOF含义
AOF 保存的是appendonly.aof文件
AOF持久化工作流程
AOF缓冲区三种写回策略
进入缓存区
always-->同步写回，每个写命令执行完毕就 立刻将日志写回磁盘
everysec-->间隔1s写回，每个写命令执行完，先放入缓存区，间隔1s后写回磁盘
no--> 不立刻写回，而是将日志放到缓存区，由操作系统决定什么时候写回磁盘
AOF案例实操，配置、启动、修复、恢复
AOF的配置文件（6 VS 7）
开启AOF
Appendonly.aof文件存储路径：
7以前-->和RDB一个存储路径
7以后-->多了一个前置的 appendonlydir 文件夹
不再和RDB存放在一起，因为以前是一个aof文件，现在是三个aof文件
appendonly.aof文件存储形式：
Multi Part AOF的设计 三个类型详解：base、incr、manifest分别是什么？
小结：redis7以后的config中对应的配置项
AOF的恢复
正常恢复
everysec时，是1s间隔写回磁盘，其中有一部分还在缓存区，这时候incr文件里会有乱码，导致redis都启动失败
异常恢复命令： redis-check-aof --fix
AOF优势
INCR文件的知识点：
incr文件可以查看所有的写操作，包括flushall、flushdb，会自动记录在文件中，可以通过Linux文本编辑来删除误操作的命令 ，再重启即可恢复误操作之前的缓存数据
AOF劣势
小结：
AOF重写机制
Q：重写机制是什么？
A：启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
官网默认配置：
触发机制：
自动触发-->顾名思义，自动触发；默认是当AOF文件大小是上一次重写后大小的一倍，且 文件大于64M时
手动触发-->类似RDB的BGSAVE，在redis命令行中发送bgrewriteaof，进行后台重写
为什么要进行AOF重写？
同一个key保留最新一次的写操作，再以前的写操作都被覆盖了，无意义，所以需要进行重写丢弃
触发重写后：
appendonly.aof 的三个文件名变了，base基本文件是瘦身后的incr数据日志，即保留所有key的最新一次写操作，被覆盖的写操作被丢弃，incr被清空，开始重新记录写操作
bgrewriteaof命令执行后：
立即重写，
AOF重写的的结论：
重写的原理： 不是整理，是直接读取最新的缓存数据，然后用一条命令记录这些多条命令，再生成一个新的文件去替换原来的AOF文件
AOF优化配置项详解
开启，然后默认即可
总结
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
