目录
1、Rewrite
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
2、Redis如何实现重写？
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
3、何时重写？
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
4、AOF的优点
备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作AOF稳健，可以处理误操作。
5、AOF的缺点
比起RDB占用更多的磁盘空间
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力
存在个别Bug，造成奴不能恢复
6、用哪个好
官方推荐两个都启用(会先载入AOF文件回复数据)
如果对数据不敏感，可以选单独用RDB
不建议单独用 AOF，因为可能会出现Bug
如果只是做纯内存缓存，可以都不用
7、性能建议
如果备份方式同时存在，因为RDB文件只用作后备用途，建议只在Slave 上持久化RDB文件，而且只要15分钟各份次就够了， 只保留save 900 1这条规则，
如果Enalbe AOF,好处是即使在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只需要load自己的AOF文件就可以了。但是有代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘足够大，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，如果项目中大量使用到了redis，可以设到3G以上，默认超过原大小100%大小时重写可以改到适当的数值。
如果不Enable AOF，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动.代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比較两个Master/Slave中的RDB文件，载入较新的那个。