AOF（Append Only File）
将所有的命令都记录下来，类似histrory的操作， 恢复的时候会将这个文件全执行一遍
简介
-
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录）。
-
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建资料，换一种说法，redis重启的话，就是根据日志文件的内容，将写指令从前到后执行了一次，才完成了资料的恢复。
配置AOF
重启Redis，检查目录是否有appendonly.aof文件
测试AOF
- 修改aof文件
- 重启Redis，失败
-
修复（
sudo redis-check-aof --fix appendonly.aof）
注意
经过实测，如果删除appendonly.aof，将不可修复
重写规则
-
aof 预设会让文件无限追加，文件会越来越大
-
如果aof文件大于64MB，redis会fork一个新的程式，来将文件进行重写。
优点、缺点
优点：
- 每一次修改都会同步，文件的完整性更好
- 每秒同步一次，可能会丢失一秒的资料
- 从不同步，效率最高
缺点：
- 相对于资料文件来说，aof远远大于rdb，修复的速度也比rdb慢！
- AOF执行效率也要比rdb慢，所以我们redis的配置就是rdb持久化
扩充：
- RDB 持久化方式能够在指定的时间间隔内对你的资料进行快照储存
- AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的资料，AOF命令以Redis 协议追加储存每次写的操作到档案末尾，Redis还能对AOF档案进行后台重写，使得AOF档案的体积不至于过大。
- 如果你只希望你的资料在服务器执行的时候存在，你也可以不使用任何持久化
- 同时开启两种持久化方式
1、在这种情况下，当redis重启的时候会优先载入AOF档案来恢复原始的资料，因为在通常情况下AOF档案储存的资料集要比RDB档案储存的资料集要完整。
2、RDB 的资料不实时，同时使用两者时伺服器重启也只会找AOF档案，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份资料库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留著作为一个万一的手段。
效能建议
- 因为RDB档案只用作后备用途，建议只在Slave(从盘)上持久化RDB档案，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
- 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒资料，启动指令码较简单只load自己的AOF档案就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite 过程中产生的新资料写到新档案造成的阻塞几乎是不可避免的。只要硬碟许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小预设值64M太小了，可以设到5G以上，预设超过原大小100%大小重写可以改到适当的数值。
- 如果不Enable AOF ，仅靠 Master-Slave Repllcation（主从复制） 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave（主从盘） 同时当机，会丢失十几分钟的资料，启动指令码也要比较两个 Master/Slave 中的 RDB档案，载入较新的那个，微博就是这种架构。
