redis之持久化AOF

Eugene03

已于 2023-04-25 10:55:19 修改

阅读量175

点赞数

分类专栏： redis 文章标签： redis 数据库缓存

于 2022-10-15 22:58:02 首次发布

本文链接：https://blog.csdn.net/eugene03/article/details/127341875

版权

redis 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

redis之持久化AOF

AOF概念

不记录数据，只是以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式（优先用AOF，再使用RDB）

在这里插入图片描述

AOF写数据的三种策略

always：每次写入操作均同步到AOF文件中，数据零误差，性能较低，一般不建议使用

everysec：每秒将缓冲区中的指令同步到AOF文件中，数据准确性高，性能较高，再系统突然当即的情况下最多丢失1秒内的数据，一般建议使用，同时也是默认配置

no：由操作系统每次同步到AOF文件的周期，整体过程不可控

AOF 功能开启

在redis.conf配置文件中配置
 配置
 	appendonly yes|no
 作用
 	是否开启AOF持久化功能，默认为不开启状态
 配置
 	appendfsync always|everysec|no
作用
	AOF写数据策略
修改AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
	appendfilename filename
AOF持久化文件保存路径，与RDB持久化文件保持一致即可
	dir

AOF重写机制

如果连续执行以下指令，会造成AOF文件冗余，连续三次set同一个变量是没必要的，记住最后一次set即可；同理，连续三次incr也是没有必要的，直接求和set即可
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程，简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录

AOF重写作用

降低磁盘占用量，提高磁盘利用率
提高持久化效率，降低持久化写时间，提高IO性能
提高持久化效率，降低持久化写时间，提高IO性能

AOF重写规则

进程内已超时的数据不再写入文件，即不写无效数据
忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
对同一数据的多条写命令合并为一条命令：如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

手动重写
	bgrewriteaof
自动重写（配置）
	auto-aof-rewrite-min-size size            # size的默认大小比较大，32M或64M，超过size	触发重写
	auto-aof-rewrite-percentage percentage    # 超过百分比，触发AOF重写

AOF工作原理

在这里插入图片描述

配置everysec重写方式：根据配置文件，后台进程执行bgrewriteaof，先给用户返回提示信息。然后用左边子进程写入aof缓存区的数据重写临时aof文件，最终会讲临时aof文件的内容更新到真正的aof文件，然后临时的aof文件就被删除了

AOF和RDB区别

在这里插入图片描述

占用空间：由于很多指令可能只是对某几个数据进行操作，所以对于同样的数据量，AOF存指令会占用更多的空间
存储速度：由于RDB每次都会存储所有的数据，而AOF只是追加当前的写操作，所以RDB存储较慢，AOF存储较快
恢复速度： RDB恢复的时候直接导入数据即可，AOF需要执行很多指令，恢复速度较慢
数据安全性： RDB快照频率高则丢失数据少，快照频率低则丢失数据多；
AOF设置always记录所有指令，不丢数据，everysec可能丢1s数据
启动优先级： AOF是redis默认的持久化方式，优先级高于RDB，当数据量很大时RDB每存一次都需要消耗一定时间

基于需求选择RDB和AOF

对数据非常敏感，建议使用默认的AOF持久化方案，丢数据更少：AOF持久化策略使用everysecond，每秒钟持久化一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据
注意：由于AOF文件存储体积较大，恢复速度较慢
数据呈现阶段有效性，建议使用RDB持久化方案：数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案。注意：利用RDB实现紧凑的数据持久化会使Redis降的很低

综合比对