【赵渝强老师】Redis的AOF数据持久化

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出会造成服务器中的数据库状态也会消失。所以 Redis 提供了数据持久化功能。Redis支持两种方式的持久化，一种是RDB方式；另一种是AOF（append-only-file）方式。两种持久化方式可以单独使用，也可以将这两种方式结合使用。

  视频讲解如下：

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下当重新启动时，Redis会优先使用AOF文件来还原数据集。因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。
  视频讲解如下：

一、AOF持久化机制的工作流程

Redis提供的AOF持久化机制的工作流程如下：
（1）所有的命令都会追加到AOF缓冲区中。
（2）AOF缓冲区根据对应的策略向磁盘同步操作。
（3）随着AOF文件越来越大，需要定期对AOF重写，达到压缩目的。
（4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

但在默认情况下，Redis关闭了AOF持久化的功能。这是由redis.conf中下面的参数决定的：

###### APPEND ONLY MODE ######
......
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of
# writes in a dramatic event like a server power outage, or a single
# write if something wrong with the Redis process itself happens,
# but the operating system is still running correctly.
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is
# the file with the better durability guarantees.
# Please check https://redis.io/topics/persistence for more information.
#**appendonly yes 默认值为no，改为yes启用AOF。**
# The name of the append only file (default: "appendonly.aof")
# **appendfilename "appendonly.aof" AOF默认生成的日志文件名称**
......

重启Redis服务器端，将在Redis的安装目录下自动生成文件appendonly.aof。如下所示：

[root@nosql11 redis]# pwd
/root/training/redis
[root@nosql11 redis]# ll
total 16
**-rw-r--r--. 1 root root 0 Apr 16 16:01 appendonly.aof**
drwxr-xr-x. 2 root root 134 Apr 16 09:38 bin
drwxr-xr-x. 2 root root 24 Apr 16 16:01 conf
-rw-r--r--. 1 root root 10405 Apr 16 16:01 dump.rdb
-rw-r--r--. 1 root root 3955 Apr 16 16:01 redis.log

提示：AOF持久化机制在默认情况下将每隔一秒将Redis操作写入日志，这是由下面的参数决定的：

# appendfsync always
appendfsync everysec
# appendfsync no

Redis监控AOF最直接的方法当然就是使用系统提供的info命令来做了。只需要执行下面一条命令，就能获得Redis关于AOF的状态报告。

bin/redis-cli info | grep aof_

# 输出的信-息如下：
aof_enabled:1					AOF日志是否启用
aof_rewrite_in_progress:0		表示当前是否在进行写入AOF日志操作
aof_rewrite_scheduled:0			是否有AOF操作等待执行。
aof_last_rewrite_time_sec:-1		表示上次写入AOF日志的时间戳
aof_current_rewrite_time_sec:-1	当前正在执行的AOF重写操作已经消耗的时间。
aof_last_bgrewrite_status:ok		表示上次执行AOF日志重写的状态
aof_last_write_status:ok			表示上次写入AOF日志的状态
aof_last_cow_size:0				AOF执行中父进程与子进程相比执行了多少修改
aof_current_size:0				AOF日志的当前大小
aof_base_size:0					最近一次重写后AOF日志的大小。
aof_pending_rewrite:0			是否有AOF操作在等待执行。
aof_buffer_length:0				AOF缓冲区的大小。
aof_rewrite_buffer_length:0		AOF重写缓冲区的大小。
aof_pending_bio_fsync:0			在等待执行的fsync操作的数量。
aof_delayed_fsync:0				fsync操作延迟执行的次数。

二、【实战】AOF日志的重写

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响，并且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。

为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

下面通过一个简单的示例来测试AOF日志的重写。
（1）使用Redis的提供的基准测试工具模拟产生20万个操作。

bin/redis-benchmark -n 200000

（2）观察aof日志文件的大小。

ll appendonly.aof 
-rw-r--r--. 1 root root 659 Apr 24 10:47 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 1663409 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 25115259 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 51573511 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 61600852 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 74649125 Apr 24 11:25 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 41135984 Apr 24 11:25 appendonly.aof

提示：在输出信息的最后可以看出生成的appendonly.aof文件由74649125变成了41135984，这说明发生了AOF日志的重写。而AOF日志的重写由以下参数决定：

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

三、剖析AOF持久化机制

在aof.c文件中可以找到创建RDB文件的函数flushAppendOnlyFile()，函数定义如下：

void flushAppendOnlyFile(int force) {
    //每秒刷入的时候，判断一下aof的fsync是否在bio线程里执行了
    if (server.aof_fsync == AOF_FSYNC_EVERYSEC)
    	sync_in_progress = aofFsyncInProgress();
    
    //每秒并且非强制刷入
    if (server.aof_fsync == AOF_FSYNC_EVERYSEC && !force) {
        if (sync_in_progress) {
        //刷入延期开始时间为0，表示没有任何的执行
        if (server.aof_flush_postponed_start == 0) {
            //先将刷入延期开始时间置为当前时间
            server.aof_flush_postponed_start = server.unixtime;
            return;
         }else if(server.unixtime -server.aof_flush_postponed_start<2){
            	return;
        	}
        	server.aof_delayed_fsync++;
        }
    }
    //写入到aof文件里
    nwritten = aofWrite(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));
    //写完aof后，将刷入延期开始时间置为0
    server.aof_flush_postponed_start = 0;
    //省略异常的处理
    //记录aof当前的大小
    server.aof_current_size += nwritten;
    /**
    * aof的可用buf比较小了，就清空buf
    */
    if ((sdslen(server.aof_buf)+sdsavail(server.aof_buf)) < 4000) {
    	sdsclear(server.aof_buf);
    } else {
   	 	sdsfree(server.aof_buf);
    	server.aof_buf = sdsempty();
    }
}