AOF 持久化(appedn-only log file)
原理:记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。AOF文件中的命令全部命令以redis协议的格式来保存,新命令会被追加到文件的尾部。优点就是可以最大程度保证数据不丢,但缺点也显而易见,那就是日志记录量级比较大。
AOF文件的生成过程具体包括 命令追加,文件写入,文件同步
命令追加 :Redis 在执行完一个写命令后,都会将执行的写命令追回到 Redis 内部的缓冲区的末尾
文件写入 :接下来,缓冲区的写命令会被写入到 AOF 文件
文件同步 :对于操作系统来说,调用write
函数并不会立刻将数据写入到硬盘,为了将数据真正写入硬盘,还需要调用fsync
函数,调用fsync
函数即是文件同步的过程。只有经过文件同步过程,AOF 文件才在硬盘中真正保存了 Redis 的写命令
配置文件中相关参数配置
1 2 3 4 5 |
vim /data/6379/redis.conf # 指定aof文件 appendfilename "appendonly.aof" appendonly yes appendfsync everysec |
appenfsync选项 | 同步频率 |
---|---|
always | 每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能 |
everysec | 每秒执行一次同步,显式地将多个写命令同步到硬盘 |
no | 让操作系统来决定应该何时进行同步 |
重写AOF文件
AOF文件随着时间不断的写入,会逐渐堆积的越来越大,那么自然而然地恢复就越来越慢。redis为了解决该问题也提供了相应的措施,即重写AOF文件,用户可以向redis发送bgrewriteaof
,这个命令会移除aof文件中冗余命令来重写AOF文件。它工作原理和快照持久化命令 BGSAVE 的工作原理类似,Redis 会创建一个子进程来负责对 AOF 文件进行重写。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK 127.0.0.1:6379> set name xadmin OK # 第一次查看该文件,AOF会记录每个重复操作, [root@db01 ~]# tail -n30 /data/6379/appendonly.aof ..... # 开始重写AOF文件 127.0.0.1:6379> BGREWRITEAOF Background append only file rewriting started # 此时再查看发现只保留了最新的K/V [root@db01 ~]# tail -n30 /data/6379/appendonly.aof |
倘若AOF文件已经很大 ,那么重写必然导致性能的下降,因此redis提供以下参数来配置重写
auto-aof-rewrite-percentage
当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写
auto-aof-rewrite-min-size
当 AOF 文件需要达到多大体积时才进行 AOF 重写
AOF优缺点
AOF优点:提供了多种同步频率,及时使用默认的,redis最多也就丢失1秒的数据而已。AOF文件可读性较强,如若不小心将flushall
可以在AOF未重写时将AOF文件中的此命令去除后再重启来恢复数据
AOF缺点:也就是比RDB文件大,而且由于每秒的同步也较RDB性能消耗高