Redis持久化之AOF详解（redis开启aof持久化）

Redis有两种持久化方式：

一种为AOF方式， AOF保存的是Redis服务器端执行的每一条命令。

另一种为RDB方式，RDB保存某一个时间点的数据，内存快照；

两种方式各有优劣。

今天我们先来学习一下AOF:

大家觉得如果是你来设计，你会在执行命令之前记录这个日志还是在执行命令之后来记录日志呢？

貌似放前放后都有问题

前: 阻塞当前的写请求，如果有语法错误，会记录大量无用日志，记了个寂寞。(但是我理解redis本身也有语法解析的步骤啊。记录日志只要语法解析之后就可以了。)

后: 有可能命令执行了，但是日志没来得及记录，那么再恢复的时候就丢了。

那么redis是如何决策的？它选择在命令执行后来记录日志。并提供了

三种写回策略

其实，对于这个问题，AOF 机制给我们提供了三个选择，也就是 AOF 配置项 appendfsync 的三个可选值。

1. Always(同步写回)：每个写命令执行完，立马同步地将日志写回磁盘；

2. Everysec(每秒写回)：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

3. No(操作系统控制的写回)：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

但是针对于刚才提出的 写阻塞，数据丢失 这2个问题，并没有完美地解决。

分别看下这3种策略

“同步写回”可以做到基本不丢数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能；

虽然“操作系统控制的写回”在写完缓冲区后，就可以继续执行后续的命令，但是落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了；

“每秒写回”采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了对系统性能的影响，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失。所以，这只能算是，在避免影响主线程性能和避免数据丢失两者间取了个折中。

总结：

现在可以根据我们的需要来确定，使用哪种方式来记录日志了。

那随着server运行的时间越长，AOF文件就会越大～。。。

这时候就需要AOF rewrite了。

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

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

重写的过程总结为“一个拷贝，两处日志”。“一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。

此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。

然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

“两处日志”又是什么呢？因为主线程未阻塞，仍然可以处理新来的操作。

此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。

而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。

在这次重刷redis的过程中，不知道大家有没有 发现这样一个问题：

AOF重写 和 RDB是不是有类似的作用？

Redis也有配置在AOF重写的时候如果配置成rdb方式，就直接用rdb了。

// aof.c
if (server.aof_use_rdb_preamble) {
    int error;
    if (rdbSaveRio(&aof,&error,RDB_SAVE_AOF_PREAMBLE,NULL) == C_ERR) {
        errno = error;
        goto werr;
    }
} else {
    if (rewriteAppendOnlyFileRio(&aof) == C_ERR) goto werr;
}

那么如何来触发AOF呢？

有2个配置项

auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb

1. 是指比上一次的AOF大小增加了100%

2. 大于指定的64M。

当我第一次看到这块的时候，我以为任意一个满足就会进行。后来一想觉得第二条满足了 岂不是会一直满足吗？

误以为第二条是比上一次的大64M 再次执行。

后来看了代码才知道 这2条要同时达成。

/* Trigger an AOF rewrite if needed. */
if (server.aof_state == AOF_ON &&
    server.rdb_child_pid == -1 &&
    server.aof_child_pid == -1 &&
    server.aof_rewrite_perc &&
    server.aof_current_size > server.aof_rewrite_min_size)
{
    long long base = server.aof_rewrite_base_size ?
        server.aof_rewrite_base_size : 1;
    long long growth = (server.aof_current_size*100/base) - 100;
    if (growth >= server.aof_rewrite_perc) {
        serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);
        rewriteAppendOnlyFileBackground();
    }
}

现在分享了aof，这个方法的好处是 每次执行只需要记录操作命令，需要持久化的数量可控。一般来说都是使用每秒一次的折中方案。

一件事情总是有正反两面性，因为记录的执行命令，而不是实际数据，所以当故障发生的时候，需要一条一条的来执行命令，这就会导致恢复起来比较慢。

这里其实有几个小问题:

fork一个子进程来做aof rewrite有什么潜在风险?

fork子进程会不会阻塞主线程?

可以一起讨论一下。