Redis持久化（二）--AOF

最新推荐文章于 2024-04-23 16:46:59 发布

diandian2u

最新推荐文章于 2024-04-23 16:46:59 发布

阅读量585

点赞数

分类专栏： Redis 持久化中间件文章标签： redis 数据库服务器

本文链接：https://blog.csdn.net/liumeina_study/article/details/130579542

版权

Redis 同时被 3 个专栏收录

12 篇文章 0 订阅

订阅专栏

中间件

5 篇文章 0 订阅

订阅专栏

持久化

2 篇文章 0 订阅

订阅专栏

AOF

AOF(append only file)是Redis的另一种持久化方式。Redis默认情况下是不开启的。

开启AOF持久化后，Redis 将所有对数据库进行过写入的命令(及其参数)(RESP)记录到 AOF 文件，以此达到记录数据库状态的目的，

当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。

AOF会记录过程，RDB只管结果

对于redis客户端执行错误的语句，是不计入aof文件的。

AOF持久化实现

配置 redis.conf

# 可以通过修改redis.conf配置文件中的appendonly参数开启 
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。 

dir ./
# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改 
appendfilename appendonly.aof

AOF持久化机制

每当有一个修改数据库的命令被执行时，服务器就将命令写入到 appendonly.aof 文件中，该文件存储了服务器执行过的所有修改命令，因此，只要服务器重新执行一次 .aof 文件，就可以实现还原数据的目的，这个过程被形象地称之为“命令重演”。

同步命令到 AOF 文件的整个过程可以分为三个阶段: 命令传播 -->缓存追加-->文件写入和保存

redis客户端将协议文本发送给服务器，服务器将协议文本转换成Redis字符串对象（StringObject），传播到aof程序-->aof程序根据命令转换回协议文本，追加到aof_buf缓冲区末尾-->write写入aof临时文件内存中-->save，将aof临时文件写入磁盘。

命令传播

当一个 Redis 客户端需要执行命令时，它通过网络连接，将协议文本发送给 Redis 服务器。服务器接到请求之后，会根据协议文本的内容，选择适当的命令函数，并将各个参数从字符串文本转换为 Redis 字符串对象( StringObject )。每当命令函数成功执行之后，命令参数都会被传播到 AOF 程序。

缓存追加

当命令被传播到 AOF 程序之后，程序会根据命令以及命令的参数，将命令从字符串对象转换回原来的协议文本。协议文本生成之后，它会被追加到 redis.h/redisServer 结构的 aof_buf 缓冲区的末尾。

redisServer 结构维持着 Redis 服务器的状态， aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本(RESP)。

文件写入和保存

每当服务器常规任务函数被执行、或者事件处理器被执行时， aof.c/flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作:

WRITE:根据条件，将 aof_buf 中的缓存写入到 AOF 文件，此时数据并没有写入硬盘，而是拷贝到了内核缓冲区page cache,等待内核将数据写入硬盘。

SAVE:根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件写入到磁盘中。

AOF保存模式

Redis 目前支持三种 AOF 保存模式，它们分别是:

AOF_FSYNC_NO :不保存。

AOF_FSYNC_EVERYSEC :每一秒钟保存一次。(默认)

AOF_FSYNC_ALWAYS :每执行一个命令保存一次。(不推荐)

对应redis.conf 中的appendfsync属性

不保存

在这种模式下，每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行，但 SAVE会被略过。

在这种模式下， SAVE 只会在以下任意一种情况中被执行:

Redis 被关闭
AOF 功能被关闭
系统的写缓存被刷新(可能是缓存已经被写满，或者定期保存操作被执行)

这三种情况下的 WRITE 操作都会引起 Redis 主进程阻塞。

每一秒钟保存一次(推荐)

在这种模式中，SAVE 原则上每隔一秒钟就会执行一次，因为 SAVE 操作是由后台子线程(fork)调用的，所以它不会引起服务器主进程阻塞。

每执行一个命令保存一次

在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。另外，因为 SAVE 是由 Redis 主进程执行的，所以在 SAVE 执行期间，主进程会被阻塞，不能接受命令请求。

AOF 保存模式对性能和安全性的影响对于三种 AOF 保存模式，它们对服务器主进程的阻塞情况如下:

AOF重写、触发方式、混合持久化

AOF记录数据的变化过程，越来越大，需要重写“瘦身”

Redis可以在 AOF体积变得过大时，自动地在后台(Fork子进程)对 AOF进行重写。重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。所谓的“重写”其实是一个有歧义的词语，实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取，它针对的是数据库中键的当前值。

举例如下:

set s1 11
set s1 22
set s1 33 ------- > set s1 33

没有优化的:
set s1 11
set s1 22
set s1 33

优化后: set s1 33

lpush list1 1 2 3
lpush list1 4 5 6
优化后
lpush list1 1 2 3 4 5 6

Redis 不希望 AOF 重写造成服务器无法处理请求，所以 Redis 决定将 AOF 重写程序放到(后台)子进程里执行，这样处理的最大好处是:

1、子进程进行 AOF 重写期间，主进程可以继续处理命令请求。

2、子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。

不过，使用子进程也有一个问题需要解决: 因为子进程在进行 AOF 重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存，这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的 AOF 文件之外，还会追加到这个缓存中。

重写过程分析(整个重写操作是绝对安全的):

当子进程在执行 AOF 重写时，主进程需要执行以下三个工作:

处理命令请求。
将写命令追加到现有的 AOF 文件中。
将写命令追加到 AOF 重写缓存中。

现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。 当子进程完成 AOF 重写之后，它会向父进程发送一个完成信号，父进程在接到完成信号之后，会调用一个信号处理函数，并完成以下工作:

将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。

对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

在整个 AOF 后台重写过程中，只有最后的写入缓存和改名操作会造成主进程阻塞，在其他时候， AOF 后台重写都不会对主进程造成阻塞，这将 AOF 重写对性能造成的影响降到了最低。

以上就是 AOF 后台重写，也即是 BGREWRITEAOF 命令(AOF重写)的工作原理。

触发方式

1、配置触发

在redis.conf中配置

# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过， 以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化 
auto-aof-rewrite-min-size 64mb

2、执行bgrewriteaof命令