AOF定义：以日志的形式记录每个操作，将Redis执行过的所有指令全部记录下来（读操作不记录），只许追加文件但不可以修改文件，
Redis启动时会读取AOF配置文件重构数据，换句话说，就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。
注:
一.RDB与AOF同时开启 默认只加载AOF的配置文件恢复数据
二.相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB
三.AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同
在5.x版本中，AOF文件做了优化，内容为：头部为RDB文件，尾部为增量写的命令：
aof-use-rdb-preamble yes
1.RDB持久化(以快照的方式) 策略（默认）：
save 900 1 （15分钟变更一次） save 300 10 （5分钟变更10次） save 60 10000 （1分钟变更1万次）
2.RDB默认配置文件名称：
dbfilename dump.rdb
3.表示是否开启AOF持久化：
appendonly yes(默认no,关闭)
4.AOF持久化配置文件的名称：
appendfilename "appendonly.aof"
5.AOF持久化策略(默认everysec)：
appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好) appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失) appendfsync no （将缓存回写的策略交给系统，don't fsync, just let the OS flush the data when it wants ）
6.AOF配置文件损坏修复方法：
进入redis安装路径 执行:
redis-check-aof --fix AOF配置文件名称
7.AOF的Rewrite(重写) ：
定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制
当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
原理：当AOF增长过大时，会fork出一条新的进程将文件重写(也是先写临时文件最后rename)，遍历新进程的内存数据，每条记录有一条set语句。
重写AOF文件并没有操作旧的AOF文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件（有点类似快照）
重写触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100 （一倍） auto-aof-rewrite-min-size 64mb
8.RDB与AOF的选择：
做备份：当数据量大，且对恢复速度有要求，并且数据的一致性要求不高的话，可以只使用RDB
只做缓存：不用开启任何的持久化方式
两者都开启的建议：RDB数据不实时，同时使用两者时服务器只会找AOF文件，可不可以只使用AOF?建议不要，因为RDB更适合备份数据库(AOF在不断变化，不好备份)，快速重启，而且不会有AOF可能潜在的BUG,留作万一的手段。
9.优化：
1. 因为RDB文件只用作后备用途，建议只在从节点上持久化RDB文件，而且只要15分钟备份一次就够了（只保留save 900 1这条规则）。
2. 如果开启AOF，好处是在最恶劣的情况下也只会丢失不超过两秒的数据，启动脚本简单，load自己的AOF文件就可以了。
代价：
（1） 带来了持续的IO
（2）重写过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
3.只要硬盘许可，应该尽量减少AOF重写的频率，AOF重写的默认基础大小为64M太小了，可以改成5G以上，默认超过原大小100%这个配置可以改成适当的数值。
4.如果不开启AOF,仅靠主从模式实现高可用性能也可以，能省掉一大笔IO，也减少了重写时带来的系统波动，
代价：
（1）主从同时宕掉，会丢失十几分钟的数据。
（2）启动脚本要比较两个主/从中的RDB文件，载入较新的那个