1：AOF的配置和原理
RDB最大的不足之处在于：一旦数据库出现问题，上次RDB文件保存保存之后的这段时间内的数据都会消失，对于数据完整性要求较高的系统，是不符合需求的。
AOF能彻底弥补RDB这一缺陷，在使用AOF的时候，redis会将每一个收到的写命令都通过write()系统函数追加到aof文件中，类似于MySQL的binlog。当redis重启后，会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
不过AOF的完全持久化会让持久化文件会变得越来越大。(比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了)。但是Redis提供了bgrewriteaof命令，可以压缩AOF的持久化文件。Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，这样便实现了控制AOF文件的增长。
设置appendsonly 为 yes,append文件名称（自行设置）
redis的刷新模式和日志重写：
由于写操作也存在缓冲，所以有可能AOF操作并没有写到硬盘中，一般可以通过fsync()来强制输出到硬盘中。而fsync()的频率可以通过配置文件中的flush策略来指定（如下图），可以选择每次事件循环写操作都强制fsync或者每秒fsync至少运行一次。
always：每次有数据修改发生时都会写入AOF文件。 everysec:每秒钟同步一次，该策略为AOF的缺省策略。 NO:跟随系统OS-sync同步，大概30S一次。
当rewrite子进程开始后，父进程接受到的命令会添加到aof_rewrite_buf_blocks中，使得rewrite成功后，将这些命令添加到新文件中。在rewrite过程中，原来的AOF也可以选择是不是继续添加，由于存在性能上的问题，在rewrite过程中，如果fsync()继续执行，会导致IO性能受损影响Redis性能。所以一般情况下rewrite期间禁止fsync()到旧AOF文件。这策略可以在配置文件中修改。