AOF日志持久化
rdb是快照，整个内存的快照（缺点几分钟才照一次，如果在下一次照之前突然宕机了，那么上一次快照到下一次快照之间的数据就损失了）。而aof是日志。
aof(append of file)的配置
appendonly no #是否打开aof日志功能
appendfsync always* #每一个命令，都立即同步到aof。安全，对redis操作的速度慢
appendfsync everysec#折衷方案，每秒写1次
appendfsync no #日志写入磁盘的工作交给操作系统，由操作系统判断缓冲区大小，统一写到aof日志中（根据操作系统的规则），对redis操作的速度快，但同步效率低
**no-appendfsync-no-rewrite yes **#正在导出rdb快照的过程中，要不要停止同步aof( aof一般设成每秒一次，rdb生成快照的时候，由于几分钟才执行一次，数据量大，所以执行时间肯定不止一秒，在这个过程中默认aof肯定要执行。但这个时候应该就让rdb一个进程执行就行了，减轻对磁盘的IO)
**auto-aof-rewrite-percentage 100 **#aof文件大小比起上次重写时的大小，增长率100%时，重写。
appendfilename appendonly.aof#这个是用来配置其aof日志文件名的，默认是appendonly.aof
**aof日志文件保存的目录和之前rdb设置的目录一样，因为他们都是用dir设置的 **
aof的工作原理
客户端对服务端主进程不断发送命令，服务端的aof子进程就将你执行的每条命令立即写到文本文件中。
好处：我们就可以用写到那个文本文件中的日志对数据进行恢复
缺点：redis图的是内存的快，但如果每次将命令写如文本文件中，则对磁盘的IO会降低内存所带来的效率。所以我们一般要设置成一段时间才对磁盘进行IO,降低磁盘IO所带来的效率的损失。
问题
同一个key,才操作100次，redis（内存中）只有一个具体值。而aof则会有100次操作，导致缺点是afo文件过大，另外从aof恢复数据的时候会过慢，因为它也会操作100次。
解决：所有的key在内存中只有一个具体的状态。我把内存中的key/value逆化成相关的命令。比如：
set age=0
incr age
……
……incr age
age=100
set age 100
这就是重写，重写是什么呢？重写就是把内存中当下数据的具体值，写入到aof日志里，以解决aof日志过大的问题。aof重写会先删除距离上次重写增长的内容
。
aof重写相关配置
auto-aof-rewrite-percentage 100#aof文件大小比起上次重写时的大小增长100%时，就重写
auto-aof-rewrite-min-size 64mb#因为最开始aof文件很小，可能导致写一个两个命令就重写，这样前期的重写密度过大，所以设置一个最小值。只有超过这个值才开始重写。
注意：一般开启aof，redis命令执行的效率就下降了
如果rdb和aof文件都存在，优先用谁来恢复数据？
答：aof
rdb和aof是否可以同时启用？
答：可以
恢复时rdb和aof哪个恢复的快？
答：rdb快。因为rdb是数据的内存映射。直接载入到内存的，而aof是命令，需要逐条执行
bgrewriteaof
不满足那些个条件时都会重写
