AOF持久化(保存的是操作redis命令)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/JOJOY_tester/article/details/87870708

前言

AOF也就是:append only file,上一篇文章学习了rdb快照持久化保存的是redis数据,aof持久化是保存的是操作redis的命令。

 

AOF持久化的原理

理论上我们只需要保存修改redis的命令(也就是写命令)就能根据这些命令恢复我们的内存数据。AOF也就是使用这个原来备份和恢复redis。

如图:

AOF配置

为了打开 AOF 持久化的功能,我们只需要将 redis.conf 配置文件中的appendonly配置选项设置为yes即可。涉及 AOF 持久化的几个常用配置如下所示:

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

  • appendonly:是否打开 AOF 持久化功能
  • appendfilename:AOF 文件名称
  • appendfsync:同步频率,可选配置如表1所示

 

表 1:appendfsync 选项及同步频率

选项 同步频率

always 每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能

everysec 每秒执行一次同步,显式地将多个写命令同步到硬盘

no 让操作系统来决定应该何时进行同步

aof持久化配置文件例子:

appendonly yes

appendfilename "redis-63791.aof"

appendfsync always

port 63791

dir /diska/redis/

daemonize yes

logfile /data/logs/redis/redis_63791.log

pidfile /data/logs/redis/redis_63791.pid

 

# 配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写

auto-aof-rewrite-percentage 50

# 配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时,才会进行 AOF 重写

auto-aof-rewrite-min-size 10M

 

AOF 文件生成过程

AOF 文件的生成过程具体包括命令追加,文件写入,文件同步三个步骤。

Redis 打开 AOF 持久化功能后,Redis 在执行完一个写命令后,都会将执行的写命令追回到 Redis 内部的缓冲区的末尾。这个过程是命令的追加过程。

接下来,缓冲区的写命令会被写入到 AOF 文件,这一过程是文件写入过程。对于操作系统来说,调用write函数并不会立刻将数据写入到硬盘,为了将数据真正写入硬盘,还需要调用fsync函数,调用fsync函数即是文件同步的过程。只有经过文件同步过程,AOF 文件才在硬盘中真正保存了 Redis 的写命令。appendfsync 配置选项正是用来配置将写命令同步到文件的频率的,各个选项的值的含义如表 1 所示。

AOF文件

appendonly.aof以 Redis 协议格式 RESP 来保存写命令。由于 RESP 协议中包含了换行符,所以上面展示的 AOF 文件时遇到换行符时进行了换行。在 AOF 文件里面,除了用于指定数据库的 SELECT 命令是自动添加的之外,其他都是我们通过客户端发送的命令。

appendonly.aof保存的命令会在 Redis 下次重启时使用来还原 Redis 数据库。

 

AOF文件重写和压缩

aof持久化会把redis所有的写命令都保存到aof文件,使得aof文件越来越大,大大占用磁盘使用空间,也给还原redis数据很大时间。

那么怎么解决?aof是记录redis执行的写命令也就是一些重复执行的写命令都会记录到aof文件内,所以所删除重复的写入命令可以适当的缩小aof文件大小。redis提供了bgrewriteaof命令可以实现:bgrewriteaof命令和bgsave命令原理差不多,执行后都会fork一个子进程进行重写操作:

如:

执行一次 set a b后,查看aof文件大小:

-rw-r--r-- 1 root root 50 2月 21 23:11 redis-63791.aof

在执行多次set a b,在查看aof文件大小:

-rw-r--r-- 1 root root 586 2月 21 23:22 redis-63791.aof

可以看到aof文件比原来大10倍

这时执行bgrewriteaof,查看aof文件大小:

-rw-r--r-- 1 root root 50 2月 21 23:24 redis-63791.aof

结论:执行bgrewriteaof后,重复的写操作被删除了!!

同时log如下:fork一个子进程操作的

注意:当aof文件很大的时候执行bgrewriteaof会导致性能问题,为此redis也提供了对应策略:

auto-aof-rewrite-percentage 50 # 配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写

auto-aof-rewrite-min-size 20M # 配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时,才会进行 AOF 重写

这个是不是和rdb持久化中配置自动执行bgsave一个类型!!!

 

AOF 的优点

AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已。(保证数据完整性,对数据要求高的建议使用)

AOF 文件使用 Redis 命令追加的形式来构造,因此,即使 Redis 只能向 AOF 文件写入命令的片断,使用 redis-check-aof 工具也很容易修正 AOF 文件。(容易修改写入的命令)

AOF 文件的格式可读性较强,这也为使用者提供了更灵活的处理方式。例如,如果我们不小心错用了 FLUSHALL 命令,在重写还没进行时,我们可以手工将最后的 FLUSHALL 命令去掉,然后再使用 AOF 来恢复数据。

 

AOF 的缺点

对于具有相同数据的的 Redis,AOF 文件通常会比 RDF 文件体积更大。

虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时,RDB 比 AOF 具好更好的性能保证。

RDB 使用快照的形式来持久化整个 Redis 数据,而 AOF 只是将每次执行的命令追加到 AOF 文件中,因此从理论上说,RDB 比 AOF 方式更健壮。官方文档也指出,AOF 的确也存在一些 BUG,这些 BUG 在 RDB 没有存在

 

备注:

  1. https://redis.io/topics/persistence
  2. https://redis.io/topics/protocol

 

 

 

 

 

展开阅读全文

没有更多推荐了,返回首页