以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF(append only file)的
开启AOF功能需要设置配置：appendonly yes

1 Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3 AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5 当Redis Server 服务器重启的时候会从AOF文件载入数据。

always
同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec
每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
no
操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

redis6
AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置

redis6
有且仅有一个

base基本文件
incr增量文件
manifest清单文件

1、启动设置yes
修改默认的appendonly no改为yes

2、写操作继续，生成aof文件到指定的目录

恢复1：重启redis然后重新加载，结果OK

恢复2：
写入数据进redis，然后flushdb+shutdown服务器
新生成了dump和aof
备份新生成的aof目录，然后删除dump/aof目录再看恢复
重启redis然后重新加载试试
停止服务器，拿出我们的备份修改后再重新启动服务器看看

故意乱写正常的AOF文件
模拟网络闪断文件写error

重启redis之后就会进行AOF文件的载入，发现启动都不行
异常修复命令:redis-check-aof --fix 进行修复
重新OK

更好的保护数据不丢失、性能高、可做紧急恢复

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，
文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集
或者
可以手动使用命令 bgrewriteaof 来重新。

一句话：
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

注意 ，同时满足，且的关系才会触发
1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小

自动触发
满足配置文件中的选项，redis会记录上次重写时的AOF大小
默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时

手动触发
客户端向服务器发送bgrewriteaof命令

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
举个例子：比如有个key 
一开始你  set k1 v1
然后改成  set k1 v2
最后改成  set k1 v3
如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；
但是，我们实际效果只需要set k1 v3这一条，所以，
开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。
AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

1、开启aof
appendonly yes

2、重写峰值改为1k
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1k

3、关闭混合，设置为no
aof-use-rdb-preamble no

4、删除之前的全部aof和rdb，清除干扰项

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似