Redis持久化-AOF方式
1、RDB存储的弊端
2、AOF
2.1、AOF的概念
2.2、AOF写数据的过程
- 服务器接收到指令后,服务器并没有马上记录,将这些命令放到AOF写命令刷新缓冲区;
- 这些指令是为了最终审查各行AOF存储文件使用;
- 到了一定阶段,将这些命令全部同步到AOF文件中即可。
存在的问题: 我们一次写多少条数据,多久写一次?
2.3、AOF写数据三种策略(appendfsync)
always(每次)
- 每次写入操作均同步到AOF文件中,数据零误差,性能较低,不建议使用。
everysec(每秒)
- 每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能较高,建议使用,也是默认控制在系统突然宕机的情况下丢失1秒内的数据。
no(系统控制)
- 由操作系统控制每次同步到AOF文件的周期,整体过程不可控,不建议使用。
2.4、AOF功能开启
配置:
appendonly yes|no
作用: 是否开启AOF持久化功能,默认为不开启状态
配置:
appendfsync always|everysec|no
作用: AOF写数据策略。
启动redis服务,去data目录看下,现在有什么样的效果:
appendonly.aof就是我们AOF持久化存储文件,现在文件大小还是0。
我们写一个数据:
继续添加文件:
always就是每次执行一个指令,改变数据时,就会记录一下!
执行一个get指令,看看有没有变化:
发现文件大小没有变化!(因为没有改变数据)
查看一下AOF文件的内容:
剩下的everysec和no两种方式只需修改配置文件,然后重新启动服务器即可!
2.5、AOF相关配置
2.6、AOF写数据遇到的问题
如果连续执行如下指令该如何处理:
存在的问题: 只有最后一个命令才会形成最终的数据,造成冗余
是可以优化的,这种优化叫做 AOF重写!
2.7、AOF重写
2.7.1、AOF重写
- 随着命令不断写入AOF,文件会越来越大,且里面也会记录一些无效的操作,以及前面提到的后面操作覆盖前面的这种操作;(为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。)
- 我们需要将这些操作重新整理下,就叫做AOF的重写;
- 简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。
2.7.2、AOF重写作用
AOF重写作用:
- 降低磁盘占用量,提高磁盘利用率;
- 提高持久化效率,降低持久化写时间,提高IO性能;
- 降低数据恢复用时,提高数据恢复效率。
2.7.3、AOF重写规则
- 进程内已超时的数据不再写入文件
- 忽略无效指令,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令 (get,多条set指令)
如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个元素
2.7.4、AOF重写方式
手动重写:
bgrewriteaof
自动重写:
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
启动redis的服务:
AOF文件已经出来了,文件大小为0。
客户端开始操作:
接下来手动进行重写:
表示后台已经开始重写了!
此时AOF的文件大小已经变小了,只有55了。
查看AOF文件的内容:
只剩下了set name 345
,已经优化了!
再接着操作:
查看AOF文件内容:
很多重复的操作都存储了!
我们再手动开启AOF重写的操作:
直接查看AOF文件内容:
-
name指令已经被优化掉了,因为是del操作,是无效的操作!
-
lpush三个字符也被优化成rpush操作!
2.7.5、AOF手动重写 —— bgrewriteaof指令工作原理
2.8、AOF自动重写方式
客户端输入info指令就会出现这些参数:(这是我们读出来的系统运行的数据效果)
我们配置时,是在conf文件中配置的!
2.9、AOF重写流程
2.9.1、无重新写的流程
2.9.2、有重新写的流程
2.10、RDB与AOF区别
2.10.1、RDB VS AOF
2.10.2、RDB与AOF的选择
2.11、持久化应用场景
删掉的表示不需要持久化!