aof原理：
来看一看aof的配置:
这是是否开启aof功能的开关
这是aof工作的三种方式：
#每一个命令都立即同步到aof，安全但是速度慢
#折衷方案，每秒写一次
#写入工作交给操作系统，有操作系统判断缓冲区大小统一写到aof，同步频率低，速度快。
#正在导出rdb快照的过程中要不要停止同步aof
#aof文件大小比起上次重写时的大小，增长率%100时重写。
#aof文件，至少超过64m时重写。
注意：在dumprdb过程中，aof如果停止同步，会不会丢失？
答:不会，所有的操作缓存在内存的队列里，dump完成后统一操作。
注意：aof重写是指什么？
答：aof重写是指把内存中的数据，逆化成命令，写入到aof日志里。以解决aof文件过大的问题
问：如果rdb和aof文件都在，优先使用哪个恢复数据？
答：aof
问：2种是否可以同时用？
答：可以，而且推荐这么做。
问：恢复时哪个恢复速度快？
答：rdb快，因为是数据的内存映射，直接载入到内存，而aof需要逐条执行。
下面看执行：
执行两条语句看
生成了aof文件且生成了日志。
对了aof还有个问题，就是你对同一个key操作一百次，可能这个key只是数值增加了一百次，对内存来说这个key占的内存并不多，但是写到aof文件中就是多了一百条命令，这里就出现两个后果：
1.造成aof文件过大
2.恢复的时候也太繁琐，慢。
看例子：
怎么解决呢？
在某个时间点将key/value逆化成一个命令，这就是aof重写。aof每次重写都会使aof的容量减小。重写的配置见上文。
测试可以通过redis-benchmark -n num 来测试，在测试的同时实时查看aof文件的大小，当达到64m的时候文件大小会骤减。
当然也可以通过命令bgrewriteaof命令重写（这就不会存在命令冗余了）。这涉及到redis的运维。
