目录
简介
以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记录），只允许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一遍以完成数据恢复工作
持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内;
（2） AOF缓冲区根据AOF持久化策略[ always,everysec,no]将操作sync同步到磁盘的AOF文件中;
（3）AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
劣势
1、比起RDB 占用更多的磁盘空间。
2、恢复备份速度要慢。
3、每次读写都同步的话 ,有一定的性能压力。
4、存在个别Bug ,造成恢复不能。
优势
1、备份机制更稳健，丢失数据概率更低。
2、可读的日志文本,通过操作AOF稳健,可以处理误操作。
基本操作
操作
AOF默认不开启
可以在redis.conf中开启，其配置为appendonly.aof
AOF文件与RDB路径一样。
假如说同时开启AOF和RDB，系统默认读取AOF数据（数据不存在会丢失）。
在redis.confg中看相关的配置文件
appendfilename，也管理着文件存储路径，RDB在哪他就在在
在开启的AOF的状态下,我设定了两个键值对
杀死redis进程，重新启动，发现值任然存在，随后我杀死进程，删除appendonly.aof文件，再次开启
这时启动就变成了空的
异常恢复
1、修改默认的 appendonly no ,改为yes
2、如遇到 AOF文件损坏, 通过/usr/local/bin/redis-check-aof--fix
3、appendonly.aof进行恢复
4、备份被写坏的 AOF文件。
5、恢复:重启redis ,然后重新加载
首先我们先破坏appendonly.aof
这时候返现根本连接不上，其实也后台根本没有成功启动
现在我们进行修复操作
此时就可以正常启动
同步帧率设置
appendfsync alwaysw
始终同步，每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好。
appendfsync everysecs
每秒同步,每秒记入日志- -次,如果宕机，本秒的数据可能丢失。。
appendfsync nos
redis不主动进行同步, 把同步时机交给操作系统。4
重写压缩
简介
AOF采用文件追加方式,文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
重写原理
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename) , redis4.0 版本后的重写，是指 上就是把rdb的快照,以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
大于128M才开始重写压缩
AOF和RDB方式选择
官方推荐两个都启用。
1、如果对数据不敏感，可以选单独用RDB。
2、不建议单独用AOF ,因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。