前言
RDB持久化存在一个缺点是一定时间内做一次备份，如果redis意外down掉的话，就会丢失最后一次快照的所有修改（数据有丢失）。对于数据完整性要求很严格的需求，则使用AOF持久化方式。
简介
Redis的AOF持久化，通过保存Redis服务器所执行的写命令来记录数据库状态。
RDB持久化方式就是将str1，str2，str3这三个键值对保存到RDB文件中，而AOF持久化则是将执行的set，sadd，lpush三个命令保存到AOF文件中。
AOF配置
找到Redis配置文件redis.conf，开启AOF持久化配置，设置必要项。如下
1. 开启持久化，将
appendonly并将no改为yesappendonly yes
2. 设置同步方式，三种同步方式：always、everysec、no。这里将其该为always
appendfsync always
# appendfsync everysec
# appendfsync no
3. Redis设置有默认的文件名，配置如下
appendfilename "appendonly.aof"
将
appendonly、appendfsync和appendfilename设置好并保存。重新启动 Redis 服务
重启redis服务后，会生成一个appendonly.aof文件
添加几条记录，会发现在aof文件中有记录
当删除一条记录，也会写入aof文件中
以上可以印证之前的AOF的描述：以日志的方式将数据变动记录下来。
AOF恢复
正常恢复
将aof文件复制到新的redis服务器目录中，重启新的redis服务，aof文件便自动加载。
异常恢复
（1）. redis异常关闭（Windows）
通过tskill命令模拟Redis异常关闭
C:\Users\Admininstrator> tskill 3928
然后重启Redis服务
net start redis
可以看到，数据还是存在的，意味着持久化是生效的。
（2）. aof文件损坏，修复（这个好像只能在linux下修复命令，才起作用。Windows暂时没有成功，如有成功的伙伴，评论请教一下）
aof损坏，就是文件的内容格式不是所规定的格式存在。可能是人为造成，或者是服务器异常产生的。下面我们模拟aof文件损坏的情况。
① 在aof文件中添加不属于它的内容，保存
② 重启服务，使用命令修复
redis-check-aof --fix appendonly.aof
AOF重写
什么是重写？
由于AOF持久化是Redis不断将写命令记录到aof文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及aof恢复要求时间越长。
bgrewriteaof来重写。
如执行如下命令
如果不进行 AOF 文件重写，那么 AOF 文件将保存四条 SADD 命令，
bgrewriteaof命令进行AOF 重写，那么AOF 文件中将只会保留下面一条命令：
sadd animals "dog" "tiger" "panda" "lion" "cat"
由此可见，AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
auto-aof-rewrite-percentage（重写百分比）：默认值为100，以及auto-aof-rewrite-min-size（重写最小大小）：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
这里再提一下，我们知道Redis是单线程工作，如果重写AOF需要比较长的时间，那么在重写AOF期间，Redis将长时间无法处理其他的命令，这显然是不能忍受的。Redis为了克服这个问题，解决办法是将AOF重写程序放到子程序中进行，这样有两个好处：
① 子进程进行AOF重写期间，服务器进程（父进程）可以继续处理其他命令。
② 子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。
子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。
AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。
这样将 AOF 重写对服务器造成的影响降到了最低。
AOF的优缺点
优点
① AOF持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis最多也就丢失一秒的数据而已。
② AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
③ AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。
缺点
①、对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
②、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
③、RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。
