Redis持久化技术AOF要点与详细解答（2）

[toc]

# 写在文章开头

本文将针对redis持久化技术aof运维向问题进行深入的剖析，希望对你有帮助。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

为方便与读者交流，现已创建读者群。关注上方公众号获取我的联系方式，添加时备注加群即可加入。

# 详解AOF基础知识点

# AOF技术简介

AOF（Append-Only File）用于将Redis服务器收到的写操作追加到日志文件，通过该机制可以保证服务器重启后依然可以依靠日志文件恢复数据。它的工作过程大抵分为以下几步：

收到客户端的写入命令(例如SET、DEL等)之后，它会将命令写入AOF缓冲区。
redis服务器会定期或者在特定条件下，将AOF缓冲区的数据以追加的方式写到日志文件末尾，这种写入的操作可以是同步的，也可以是异步的，具体看我们配置的刷盘机制。
若日志文件超过配置文件的大小(由配置参数 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 决定)，则会触发AOF重写(AOF Rewrite)，重写时会启动一个后台进程，分析日志中的指令并精简化写入新的AOF文件中。
新的AOF文件和旧的AOF文件进行原子替换，后续的写指令都会写到这个新的AOF文件中。

# AOF持久化技术的优缺点

优势：

客户端操作的指令可能会出错，采用写后再日志的形式可以避免很多没必要的日志记录，节约磁盘空间
写日志需要进行磁盘IO，可能会产生阻塞，所以采用先写入再日志，可以避免写时阻塞。

劣势:

有可能在写操作之后，日志记录之前服务器出现宕机，可能会造成数据丢失
当主线程磁盘压力过大，导致写入磁盘慢，进而造成后续操作阻塞。

# AOF核心配置参数

appendonly :若将该参数设置为yes，则开启aof持久化机制，此时redis持久化机制就以aof为主，而非rdb

# 设置为yes开启aof
appendonly yes

1
2

如下示例所示，我们将该参数配置为yes后重启redis服务端，使用客户端完成如下操作

# 设置三个key
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK

1
2
3
4
5
6
7

此时我们查看aof文件，大小增加了：


[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof
/usr/sbin/appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof
/usr/sbin/appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof
-rw-r--r-- 1 root root 110 Aug 26 00:09 appendonly.aof

1
2
3
4
5
6
7
8

然后我们再次使用客户端写入文件，可以看到大小又增加了，由此得出我们AOF配置生效了。


# 再次查看aof文件大小，变为139，说明aof配置生效
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof
-rw-r--r-- 1 root root 139 Aug 26 00:10 appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]#

1
2
3
4
5

appendfilename ，该参数决定aof持久化文件的名字，这个就不多赘述了。如下所示，这条配置就意味着aof文件名是appendonly

appendfilename "appendonly.aof"

dir ：该参数决定aof文件持久化位置，默认为redis-server的位置。

dir ./

appendfsync(重点) : 在介绍appendfsync，我们必须介绍一下操作系统提供的两个函数:

  1. write:write操作会触发操作系统延迟写机制，这种机制下数据一写到缓存区就直接返回，至于什么时候进行刷盘由操作系统决定，要么缓存空间满了刷，要么就是定时任务时间到了。
  2. fsync:该调用会强制将缓存写入磁盘中，所以使用这个函数进行文件写入时，可能存在阻塞问题。

了解了上述两个函数之后，我们再来聊聊这个参数值:

1. `always`:该选项会使得命令一旦写入aof_buf后，就会调用操作系统的fsync将指令写到aof物理文件中，完成操作后线程返回
2. `everysec`:该选项会在命令写入`aof_buf`后调用操作系统的`wirte`，完成write后线程返回。`fsync`会由专门的线程每秒调用一次
3. `no`:该选项会在命令写入`aof_buf`后调用操作系统的`write`，完成`write`后线程返回，不调用`fsync`，同步操作由操作系统执行，最长周期为`30s`。

1
2
3

所以配置时，我们建议采用默认的写入策略everysec，他不会像always造成线程阻塞亦或者像no一样不可控。

 appendfsync everysec

no-appendfsync-on-rewrite:redis为了保证持久化aof文件时调用fsync时不会出现长时间的卡顿，增加了该参数，若设置为yes，在redis调用fsync期间出现的写入指令不会将其放到页缓存(page cache)中，避免阻塞，但是存在数据丢失的风险:

no-appendfsync-on-rewrite yes

auto-aof-rewrite-percentage和auto-aof-rewrite-min-size(重点)：这两个参数决定redis何时进行重写，如下所示，这两个参数分别为100和64mb，意味当本次aof文件超过64+64*100%就触发redis自动重写。


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

1
2
3
4

aof-load-truncated：若设置为yes时在redis加载aof文件出错后会发送日志通知用户，反之则不做任何处理也不会启动redis，用户可以使用redis-check-aof指令完成数据修复。这个参数笔者会在后文演示。

aof-load-truncated yes

aof-rewrite-incremental-fsync：开启该参数后，子进程在进行aof重写时，每32m就会将数据写到的新的aof文件中，从而避免单刷造成的线程阻塞。

aof-rewrite-incremental-fsync yes

aof-use-rdb-preamble：redis 4.0之后支持同时开启rdb和aof，具体后文会详述

# rdb+aof两种机制结合使用
aof-use-rdb-preamble yes

1
2

# AOF断电后恢复的过程是什么

我们在之前的aof文件重命名，模拟断电后数据丢失，大体的执行步骤为：

将aof文件备份
重启redis，模拟断电后数据丢失

对应执行指令如下：

[root@xxxx sbin]# mv appendonly.aof appendonly.aof.bak


# 重启redis服务端，打开客户端查看数据都丢失了
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> keys *
(empty array)

1
2
3
4
5
6
7
8
9

然后将备份文件还原，重启redis：

# 将aof文件还原，并重启redis
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof.bak appendonly.aof
mv: overwrite ‘appendonly.aof’? y
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf

1
2
3
4

可以看到，数据已经回来了：

# 再次使用redis查看，丢失的数据都回来了
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> keys *
1) "k4"
2) "k3"
3) "k2"
4) "k1"
127.0.0.1:6379>

1
2
3
4
5
6
7
8
9
10

# 详解AOF持久化技术进阶知识点

# AOF重写机制如何压缩文件体积

详情可参考笔者这篇来聊聊Redis持久化AOF管道通信的设计：https://mp.weixin.qq.com/s/kYhvRvGDrngHiUsKqWv2mA (opens new window)

# AOF重写时是否会阻塞线程

答案是会的，但阻塞大部分情况是发生在重写时fork子进程时，因为fork函数会copy一份几乎相同的进程并分配：

系统资源
原有进程内存堆栈数据

并且这个fork操作是以创建一个子进程级别的资源与父进程并行运行，所以其创建开销相较于线程会更大一些，对应我们也给出aof重写的核心函数即位于aof.c的rewriteAppendOnlyFileBackground印证这一点：

int rewriteAppendOnlyFileBackground(void) {
     //......
    if ((childpid = fork()) == 0) {//fork子进程进行aof重写
        char tmpfile[256];

        //......
        //生成一个tmp文件
        snprintf(tmpfile,256,"temp-rewriteaof-bg-%d.aof", (int) getpid());
        if (rewriteAppendOnlyFile(tmpfile) == REDIS_OK) {//重写aof
             //......
            exitFromChild(0);
        } else {
            exitFromChild(1);
        }
    } else {
        //......
    }
    return REDIS_OK; /* unreached */
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

需要补充的是，上面提到日志重写期间数据都会被写到AOF缓冲区中，在高并发场景下也可能导致内存被打满出现频繁内存置换等情况间接导致我们的redis进程阻塞，此时就可能出现读写性能下降的情况：

# Redis重启后加载日志文件的顺序

执行顺序为:

先看看有没有AOF，若有则先加载AOF，然后执行步骤2。
查看是否有RDB文件，若有再加载RDB文件。

# Redis恢复数据期间文件校验是怎么做

在日志写入期间要是服务器宕机了，那么这个日志文件可能就用不了了，而解决方案也很可能简单，redis给我提供一个命令进行fix。

例子如下，我们首先需要将一个日志文件损坏:

# 追加一个错误数据到aof文件末行并杀死redis 模拟服务器宕机
[root@xxxxxx sbin]# vim appendonly.aof


# 再次启动redis，操作数据时发现登录失败
[root@xxx sbin]# redis-server /root/redis/redis.conf
[root@xxxx sbin]# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>

1
2
3
4
5
6
7
8
9

然后使用日志文件进行修复

#  使用 redis-check-aof --fix aof文件 修复文件
[root@xxxxsbin]# redis-check-aof --fix appendonly.aof
0x              8b: Expected prefix '*', got: 's'
AOF analyzed: size=151, ok_up_to=139, ok_up_to_line=34, diff=12
This will shrink the AOF from 151 bytes, with 12 bytes, to 139 bytes
# 这里选择y
Continue? [y/N]: y
Successfully truncated AOF

1
2
3
4
5
6
7
8
9

可以看到，经过fix修复后的日志文件部分数据已经恢复了

# 重启redis，使用客户端连接发现启动成功且数据都还在
[root@xxxxsbin]# redis-server /root/redis/redis.conf
[root@x sbin]# redis-cli

127.0.0.1:6379> keys *
1) "k4"
2) "k3"
3) "k2"
4) "k1"