Redis基础篇（三）持久化：AOF日志

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

AOF重写

AOF会记录每个写命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至对操作系统造成影响，而且AOF文件越大，数据恢复也越慢。

为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写功能来对AOF文件进行“瘦身”。Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。

简单来说，AOF重写就是把旧AOF日志文件的多条命令，在重写后变成新日志文件的一条命令。

AOF重写会阻塞吗？AOF重写是由后台线程bgrewriteaof来完成的。

AOF重写过程

用一句话总结：一个拷贝，两处日志。一个拷贝指一份内存拷贝，两处日志分别是一处正在使用的AOF日志，另一处是新的AOF重写日志。

下图是AOF重写过程：

拓展

关于AOF重写过程的潜在阻塞风险

前面提到AOF重写不会阻塞，指的是在AOF重写过程不会阻塞主线程，因为是通过后台bgrewriteaof线程来执行的。

但是在fork子进程的时候，fork这个瞬间一定是会阻塞主线程的。

fork采用的是操作系统提供的写时复制（Copy On Write）机制，避免一次性拷贝造成的阻塞。但fork子进程需要拷贝进程必要的数据结构，其中有一项是拷贝内存页表（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量的CPU资源，在拷贝完成之前，整个进程是会阻塞的。

拷贝内存页完成后，子进程与父进程指向相同的内存地址空间，也就是说此时虽然产生了子进程，但是并没有申请与父进程相同的内存大小。

那什么时候父子进程才会真正内存分离呢？在写发生时，才真正拷贝内存的数据，这个过程中，父进程也可能会产生阻塞风险。

因为内存分配是以页为单位进行分配的，默认4K，如果父进程此时操作的是一个bigkey，重新申请大块内存耗时会变长，可能会产生阻塞风险。

另外，如果操作系统开启了内存大页机制（Huge Page，页面大小2M），那么父进程申请内存时阻塞的概率将会大大提高，所以在Redis机器上需要关闭Huge Page机制。

为什么AOF重写不复用原AOF日志

有两方面原因：

父子进程写同一个文件会产生竞争问题，影响父进程的性能。
如果AOF重写过程中失败了，相当于污染了原本的AOF文件，无法做恢复数据使用。

AOF重写需要手动触发吗？

可以设置自动触发，通过配置这两个参数auto-aof-rewrite-min-size和auto-aof-rewrite-percentage：

auto-aof-rewrite-min-size：表示运行AOF重写时文件的最小大小，默认为64MB
auto-aof-rewrite-percentage：当前AOF文件大小和上一次重写后AOF文件大小的差值，再除以上一次重写后AOF文件大小

当AOF文件大小同时超出上面两个配置项，会触发AOF重写。

参考资料