Redis是内存数据库，但是一旦服务器宕机，内存中的数据将会全部丢失。
最简单的恢复方式是从后端数据库恢复，但这种方式有两个问题：
频繁访问数据库，会给数据库带来巨大的压力；
从数据库中读取相比从Redis中读取要慢很多，会导致应用响应变慢
因此，Redis要实现持久化，避免从后端数据库中进行恢复。
Redis有两种持久化机制：AOF（Append Only File）日志和RDB快照。今天先来学习AOF日志。
什么是AOF日志？AOF日志是通过保存Redis写命令来记录数据库数据的。大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。想了解更多关于两阶段提交的内容，点击查看。
而AOF日志采用写后日志，即先写内存，后写日志。
为什么采用写后日志？Redis要求高性能，采用写日志有两方面好处：
避免额外的检查开销
不会阻塞当前的写操作
但这种方式存在潜在风险：
如果命令执行完成，写日志之前宕机了，会丢失数据。
主线程写磁盘压力大，导致写盘慢，阻塞后续操作。
如何实现AOF日志？AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。
命令追加当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
文件写入和同步关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
上面的三种写回策略体现了一个重要原则：trade-off，取舍，指在性能和可靠性保证之间做取舍。
关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。
这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。
如何配置AOF？默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：
# appendonly参数开启AOF持久化 appendonly no # AOF持久化的文件名，默认是appendonly.aof appendfilename "appendonly.aof" # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的 dir ./ # 同步策略 # appendfsync always appendfsync everysec # appendfsync no # aof重写期间是否同步 no-appendfsync-on-rewrite no # 重写触发配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 加载aof出错如何处理 aof-load-truncated yes # 文件重写策略 aof-rewrite-incremental-fsync yes