持久化原理：

       AOF<二进制文件>比RDB方式有更好的持久性。

       redis会将每一个收到的写命令都通过write函数追加到文件最后，类似msyql的binlog。

       当redis重启时，会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

优点：可以保持更高的数据完整性。

            如果设置追加file的时间是1s，那么redis发生故障，最多会丢失1s的数据；

            如果日志写入不完整，支持redis-check-aof来进行日志修复；

            AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），

            可以删除其中的某些命令（比如误操作的flushall）。

缺点：AOF文件比RDB文件大，且恢复速度慢。 

   AOF默认关闭。

配置文件相关参数：

            appendonly yes

            appendfilename ””     #AOF保存的文件名

同步方式相关的配置：

            appendfsync always    #一旦插入命令，立即同步到磁盘，完全的持久化，但是速度慢，不推荐

            appendfsync everysec        #AOF每秒进行同步

            appendfsync no         #不自动同步，性能最好，但是持久化没有保证

存储过程：

         将快照内容以命令的形式追加到AOF文件中，

         所以随着追加，AOF文件会越来越大，保存的AOF文件存储了执行的所有命令，

         所以可以进行修改文件来撤销输错的命令（在重写之前，如果重写了就没有办法了） 

对AOF文件进行重写：（解决AOF文件越来越大的问题）

         redis-cli -h ip -p port bgrewriteaof

重写命令的操作过程：

         在当前的快照保存结束后，开启一个子进程，将AOF文件进行重写，

         合并set命令等操作到一个临时文件，达到缩小文件大小的目的。

         重写结束后，将临时文件替换为新的AOF文件。

         （重写过程中如果有新的redis操作命令，会提交到缓存中，重写结束后追加到AOF文件内） 

         说明：redis2.4以上版本，重写机制自动触发。触发的相关redis.conf配置如下：

         auto-aof-rewrite-percentage 100

         当目前的AOF文件大小超过上一次重写文件大小的百分之几时进行重写，

         如果没有重启过，则以启动时的AOF文件大小为依据）

         auto-aof-rewrite-min-size 64mb（允许重写的最小AOF文件大小）；

数据恢复：

        重启redis服务，前提是配置文件必须设置了appendonly yes，然后会从appendfile的文件加载文件。

        反之是从RDB中加载数据的。