AOF日志

1.AOF日志

1.1 写后日志

AOF日志为写后日志，Redis先执行命令，把数据写入内存，然后才记录日志。如下图所示：

1.2 AOF日志记录的内容

AOF日志里记录的是Redis收到的每一条命令，这些命令以文本形式保存。以记录"set testkey testvalue"命令为例，看AOF日志的内容。其中，"*3"表示当前命令有三个部分，每个部分都是由"$+数字"开头，后面紧跟着具体的命令、键或者值。“数字”表示这部分中的命令、键或者值一共有多少字节。例如，"$3 set"表示这部分有3字节，也就是"set"命令。

1.3 为啥采用写后日志

优点：为了避免额外的检查开销，Redis在向AOF里面记录日志的时候，并不会先对这些语法进行检查。如果先记日志再执行命令，日志中就可能记录了错误的命令，Redis在使用日志恢复数据时，就可能出错。所以Redis就采用写后日志这种方式，让系统先执行命令，只有命令才能执行成功，才会被记录到日志中。否则，系统会直接向客户端报错。写后日志能避免记录错误命令的情况。
写后日志还有一个好处：在命令执行后才开始记录，不会阻塞当前的写操作。
缺点：
1.执行完一个命令，还没来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时Redis是用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果Redis用作数据库，此时命令没有记录到日志中，就无法用日志进行恢复了。
2.虽然避免了当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为AOF日志是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。

仔细分析后会发现，这两个风险都和AOF写回磁盘的时机相关的。这意味着，如果我们能够控制一个写命令执行完后AOF日志写回磁盘的时机，这两个风险也就解除了。

1.4 写回策略

AOF配置项appendfsync含有三个可选值。

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘。
• Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区的内容写入磁盘。
• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的缓冲区中，由操作系统决定何时将缓冲区内容写回磁盘。

针对避免主线程阻塞和减少数据丢失问题，这三种写回策略都无法做到两全其美。分析原因如下：

• “同步写回”可以做到基本不丢失数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免会影响主线程性能。
• “每秒写回”采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了系统性能的影响，但是如果发生宕机，上一秒未落盘的命令操作仍然会丢失。所以，这只能算是，在避免影响主线程性能和避免数据丢失两者间取了个折中。
• 虽然“操作系统控制的写回”在写完缓冲区后，就可以执行后续的命令，但是落盘的时机已经不在Redis手中了，只要AOF记录没有写回磁盘，一旦宕机对应的数据就丢失了。

总结一下：想要获得高性能，就选择No策略；想获得高可靠性保证，就选择Always策略；如果允许数据有一点丢失，又希望性能别受太大影响，就选择Everysec策略。

但是，按照系统的性能需求选定了写回策略，并不是“高枕无忧”了。毕竟，AOF是以文件的形式记录接收到的所有命令。随着接收的写命令越来越多，AOF文件会越来越大。这也就意味着，我们一定要小心AOF文件过大带来的性能问题。
这里的性能问题，主要在三个方面：

1. 文件系统本身对文件大小的限制，无法保存过大的文件。
2. 文件太大，之后再往里面追加命令记录的话，效率也会变低。
3. 如果发生宕机，AOF中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这样会影响到Redis的正常使用。

所以，AOF重写机制就登场了。

1.5 日志文件太大了怎么办

简单来说，AOF重写机制就是在重写时，Redis根据数据库的现状创建一个新的AOF文件，也就是说，读取数据库中的所有键值对，然后对每一个键值用一条命令记录它的写入。比如说，当读取了键值对“testkey”：“testvalue”之后，重写机制会记录 set testkey testvalue这条命令。这样，当需要恢复时，可以重新执行该命令，实现testkey：testvalue的写入。

为啥重写机制可以把日志文件变小？实际上，重写机制具有“多变一”功能。也就是说，旧日志文件中的多条命令，在重写后的新日志变成了一条命令。

我们知道，AOF文件是以追加的方式，逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时，AOF会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。这样一来，一个键值对在重写日志中只用一条命令就行了，而且，在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了。

虽然AOF重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另外一个问题了：重写会不会阻塞主线程？

1.6 AOF重写会阻塞吗？

和AOF日志由主线程写回不同，重写过程是由后台线程bgrewriteaof来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。

重写的过程总结为：“一个拷贝，两处日志”

“一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。

总结来说，每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。