Redis的AOF持久化
一 RDB持久化的缺点
RDB持久化有一个缺点，那就是因为创建RDB文件需要将服务器所有的数据库的数据都保存起来，这是一个非常耗费资源和时间的操作，所以服务器需要隔一段时间才创建一个新的RDB文件，也即是说，创建RDB文件的操作不能执行得过于频繁，否则就会严重影响服务器的性能。
比方说，在save配置选项默认设置下，即使有超过10000次修改操作发生，服务器也至少会间隔一分钟才创建一个RDB文件：
save 900 1
save 300 10
save 60 10000
如果在等待创建下一个RDB文件的过程中，服务器遭遇了意外停机，那么用户将丢失最后一次创建RDB文件之后，数据库发生的所有的修改
至少也得60秒才创建一次。
二 数据丢失的例子
为了解决RDB持久化缺点，AOF持久化有一个巨大的优势，那就是，用户可以根据自己的需要对AOF持久化进行调整，让redis在遭遇意外停机时不丢失任何数据，或者只丢失一秒钟的数据，这比RDB持久化遭遇意外停机，丢失的数据要小得多。
三 AOF持久化运行原理
AOF持久化保存数据库的方法是：每当有修改的数据库的命令被执行时，服务器就会将执行的命令写入到AOF文件的末尾。
因为AOF文件里面存储了服务器执行过的所有数据库修改的命令，所以给定一个AOF文件，服务器只要重新执行一遍AOF文件里面包含的所有命令，就可以达到还原数据库的目的。
四 例子
五 安全性问题
虽然服务器执行一个修改数据库的命令，就会被执行的命令写入到AOF文件，但这并不意味着AOF文件持久化不会丢失任何数据。
在目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将存储在缓冲区里面的内容真正的写入到硬盘里。
对于AOF持久化来说，当一条命令真正的被写入到硬盘里面时，这条命令才不会因为停机而意外丢失。
因此，AOF持久化在遭遇停机时丢失命令的数量，取决于命令被写入硬盘的时间。
越早将命令写入到硬盘，发生意外停机时丢失的数据就越少
而越迟将命令写入到硬盘，发生意外停机时丢失的数据就越多。