Redis的AOF持久化

前言

上篇文章讲到了Redis为啥要有持久化机制以及Redis的RDB持久化机制 RDB持久化，本文来讲解另一种持久化AOF

AOF持久化是以一种日志追加的方式，将每次Redis的写成功命令记录到AOF日志。

首先是先执行Redis命令才会记录日志，与数据库的日志记录方式不一样，这样的好处是能够保证Aof日志都是写成功的命令，省去了命令检查这一步。

Aof机制配置

# 开机AOf机制 yes
appendonly yes
# 存储文件名
appendfilename "appendonly.aof"
1
2
3
4

落盘策略

日志最后肯定是得落盘的，如果写一个命令就落盘一次那势必会对redis的性能有极大的影响，如果磁盘io比较繁忙，那么写入磁盘的速度也会降低，从而影响整个命令的响应时间。Redis给我们提供了三种策略。

always

上面提到的问题就是这种配置,每次有新命令追加到AOF文件时就执行一次刷盘，非常慢，但是也非常安全。 除非Redis命令执行成功后在落盘时刻发生宕机，才会丢失一条命令。但其实这个时候客户端是不会收到写成功信息，逻辑上来说也不算丢失。

appendfsync always
1

everysec 默认配置

每秒刷盘一次，足够快，如果发生故障时只会丢失1秒钟的数据。Redis写命令成功后并不会立刻刷盘，而是写入Aof日志缓冲区直接操作内存速度自然也是非常快。Redis的后台会有一个子线程专门来刷盘。

appendfsync everysec
1

no

与everysec是一样的，Redis命令执行成功后不会去刷盘，而是写入日志缓冲区，不同的是它没有一个后台线程去刷盘，刷盘动作交给操作系统来处理。安全性更低一些，丢失多少数据由操作系统刷盘频率决定。

appendfsync no
1

数据格式

Aof文件记录的是Redis的Resp协议格式数据，在Redis2.0之后， 该协议成为了与Redis服务器通讯的标准方式。后面自己写一个Redis客户端时会讲解Resp协议

首先我们执行两条命令，看Aof文件信息。

127.0.0.1:7000> set name wendell
OK
127.0.0.1:7000> set lock lock EX 10
OK
1
2
3
4

Aof文件内容如下

*3
$3
set
$4
name
$7
wendell
*3
$3
set
$4
lock
$4
lock
*3
$9
PEXPIREAT
$4
lock
$13
1669543835117
*2
$3
DEL
$4
lock
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

解析

* 代表该命令有多少个参数，显然 set name wendell 是由三个参数组成，所以是 *3
$ 代表该参数由几个字符组成 set 有三个字符所以是 $3 name为$4 wendell为 $7
1
2

值得注意的是上面执行的 set lock lock EX 10 其实是两个命令，由 set lock lock与 PEXPIREAT lock 1669543835117组成，这里注意过期时间为真正过期时间那一刻的时间戳，而不是原始的指令。

重写机制

Aof以日志追加方式来持久化，那么随着运行时间越来越久，日志文件也会越来越大，对后面刷盘的压力也会越来越大，这个时候Aof提出了重写机制。

比如 incr count 我执行了一百次，那么其实日志文件只要记录 set count 100 就行了。这样可以大大减小文件的大写

演示

下面来演示一下，为了看到效果先修改配置文件关掉一个配置，后面再讲解该配置。

aof‐use‐rdb‐preamble no
1

将count新增到50

...
127.0.0.1:7000> INCR count
(integer) 49
127.0.0.1:7000> INCR count
(integer) 50
1
2
3
4
5

观察aof文件大小

[redis@master data]$ ls -l appendonly.aof
-rw-r--r-- 1 redis redis 1273 Nov 27 18:39 appendonly.aof
1
2

使用 bgrewriteaof 手动重写,后面会讲解重写触发机制

127.0.0.1:7000> bgrewriteaof
Background append only file rewriting started
1
2

再次观察aof文件大写发现变小了很多由 1273变成了55

[redis@master data]$ ls -l appendonly.aof
-rw-rw-r-- 1 redis redis 55 Nov 27 18:40 appendonly.aof
1
2

查看aof 发现记录的内容变为了 set count 50

*3
$3
SET
$5
count
$2
50
1
2
3
4
5
6
7

触发机制

上面例子我们是手动触发的，与bgsave一样，都是fork出一个子线程来重写。

aof也提供了配置，通过配置描述达到一定条件触发重写。

#默认配置项
auto-aof-rewrite-percentage 100 # aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-min-size 64mb # aof文件至少要达到64M才会自动重写,文件太小重写其实没有啥意义
1
2
3

混合持久化

上面我们演示的时候关掉了一个配置 aof‐use‐rdb‐preamble,他是redis 4.0之后才有的，5.x之后就默认开启了。

我们redis重启的时候很少会用Rdb来恢复数据，因为会丢失很多内容。通常是使用Aof日志去恢复，但是Aof的速度相比于Rdb差太多，如果是一个大型的Redis集群，恢复数据过程就相当缓慢，为了解决这一问题，Redis 4.0之后带来了一个新的持久化选项——混合持久化。

4.x的时候默认配置是关闭的，5.x默认开启。

使用了混合持久化之后，Aof文件就不单纯的是resp协议的数据格式了，而是在重写这一刻会先来一次Rdb快照写入新的Aof日志，后面进来的写命令还是以resp协议的数据格式写入新的Aof日志，重写完成后新的Aof文件覆盖原来的Aof文件。直到下一次重写，记录的又是一个全新的rdb快照。

以这样的数据格式记录，那么下次Redis重启时会快速加载rdb内容，然后执行resp协议数据格式内容。这样整个重启过程速度就大幅度提升了。

演示混合持久化

下面演示一下效果，打开 aof‐use‐rdb‐preamble配置

aof‐use‐rdb‐preamble yes
1

重启Redis 执行 bgrewriteaof 重写，再次写入 set name juan,查看Aof文件内容。

内容由文件头与RDB格式的二进制数据段和 AOF格式的文本数据段共同组成

REDIS0009ú      redis-ver^E5.0.3ú
redis-bitsÀ@ú^EctimeÂ"E<83>cú^Hused-memÂÐ^C^M^@ú^Laof-preambleÀ^Aþ^@û^A^@^@^EcountÀ2ÿÊÎ<8e>JV^[»V*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$4
juan           
1
2
3
4
5
6
7
8
9
10
11
12
13

AOF持久化就介绍到这里，后面讲解Redis的集群架构

---

欢迎关注，学习不迷路！