大家都知道Redis经常被使用在缓存的场景中，那有没有想过这么一个问题，一旦服务器宕机，内存中的数据全部丢失，我们该如何进行恢复呢？如果直接从后端数据库恢复，不仅会给数据库带来巨大的压力，还会使上层应用响应变慢。所以redis的持久化机制是很重要的。接下来我们一起来探讨一下Redis的持久化机制。目前Redis持久化主要有两大机制，即AOF(Append Only File)日志和RDB快照。接下来我们就来分别学习一下。
AOF日志
AOF日志，即写后日志，它的含义是Redis先执行命令，把数据写入内存，然后再写入日志。Redis为什么要先执行命令后写入日志呢？首先我们来看一下AOF日志里记录了什么内容。AOF记录的是Redis收到的每一条命令，这些日志以文本的形式保存。假如我们执行了set hello world命令，AOF的内容如下:
其中“*3”代表当前命令有3部分，每部分是由”$+数字”开头，后面紧跟着具体命令、键和值。这里的数字代表后面的命令、键和值一共有多少个字节。例如 “$3 set”表示这部分有3个字节，也就是“set”命令。
Redis为了避免额外的检查开销，再往AOF里写入日志的时候，并不会对这些命令进行语法检查。所以如果先写日志再执行命令，日志中就可能会记录一些错误的命令，Redis使用日志恢复的时候就会出错。而写后日志这种方式，就是先去执行命令，如果命令执行出错，则不写入日志，只有执行成功的命令才会写入日志中。所以Redis使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。AOF还有一大好处，它是在命令执行后才记录日志，所以不会阻塞当前的写操作。
不过，AOF也有潜在的两个风险，首先如果刚执行完一个命令，还没来的及写日志就宕机了，那么这个命令和相应的数据就有丢失的风险。其次，AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF日志也是在主线程中执行的，如何在把日志文件写入磁盘很慢时，就会阻塞后续操作。针对这个问题，AOF给我们提供了三种写回策略，也就是AOF的配置项appendfsync的三个可选值。
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
这三种写回策略都无法做到两全其美，都有自己的优缺点，我们只能根据我们的业务场景，是需要高性能还是高可靠性来选择不同的写回策略。
最后，AOF还有一个问题，就是AOF以文件的形式记录在磁盘里。随着Redis接受的写命令越来越多，那么AOF日志文件也会越来越大，所以需要采取一定的手段来控制AOF日志文件的大小。这个时候，AOF重写机制就派上用场了。AOF重写机制是指在重写时，Redis会根据数据库的现状创建一个新的AOF文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。为什么重写机制可以把日志文件变小呢?实际上，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。例如我们对某个key进行了6次写入操作，那么旧的日志文件中就会有6条记录，而重写后的日志文件中就只有一条命令，所以AOF重写会减小文件的大小。那么AOF重写会阻塞主线程吗？毕竟把整个Redis的数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。和AOF日志由主线程写回不同，重写过程是由后台子进程bgrewriteaof来完成的，这也是为了避免阻塞主线程，导致Redis的性能下降。每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝（采用操作系统的写时复制技术，不会真正的拷贝，写时复制技术下面会分析）一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。因为主线程未阻塞，仍然可以处理新来的操作。为了避免数据丢失，在AOF重写过程中，新进入的写命令会写入到两份日志中。第一处日志就正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。