除了我们上次介绍的redis快照持久化之外，redis还提供了日志追加（append-only-file）的方式，这种方式会在我们对数据进行修改的时候将相关的操作命令追加到追加日志文件的末尾，所以这种方式的持久化在任何情况下都可以进行数据的恢复，我们只需要按照日志命令重新执行一下即可。在redis的配置文件中有一个appendonly yes表示开启aof。这里默认是不开启的。
这块要说的是我们在将文件写入磁盘的时候，其实先将数据写入一操作系统的一片内存区域。这期间我们要调用write函数，但是这时候我们的数据并不一定会立刻写入磁盘，真正写入磁盘都是调用的操作系统的api，所以在这块未知的时间段内我们是无法保证我们的数据已经写入磁盘的。但是我们可以采用flush方法，这个方法会在操作系统具有时间片的时候写入到磁盘。当然我们可以采用sync同步数据的方法，这个方法会阻止其对所设计的内存的数据操作直到写入完成。Always：每个写的操作都会导致aof写入磁盘的操作，这样会导致redis性能降低。例如我们有每秒200次写请求，那么redis就会有200次的对磁盘操作。所以硬件就成为一种瓶颈。但是这种策略在发生宕机事件的时候丢失的数据是最小的。Everysec：每秒一次No：让操作系统决定同步到磁盘的时机。
综合上述，一种比较这种的方式就是每秒写入一次磁盘，这样可以允许丢失的数据就是一秒钟。在redis的写入速度超过磁盘的写入速度的时候，redis还会进行适应性调整。当然如果我们配置appendfsync no，那么我们的redis就不会有任何性能损失，所有的写入磁盘操作都是操作系统决定的，也正是因为开篇我们说的哪些问题，所以如果某一时刻操作系统奔溃，那么我们就无法衡量我们redis的数据丢失情况。当然如果我们配置了这个选项，并且磁盘硬件写入速度很慢，而redis写入很快，那么在我们redis缓存写满之后就会越来越慢。综合上边说的这些，还是不建议采用这种策略。Aof这种方式固然灵活，而且有很多种策略用以兼容各种情况，但是问题就是日志文件越来越大。
