背景:RDB不足之处
1.耗时,耗性能
生成快照文件耗时,load快照文件耗时
Fork子进程网络开销
写文件磁盘I/O开销2.不可控,丢失数据
会丢失最后一次快照最后操作的数据。
一、工作流程
Redis写操作命令 ——> aof缓冲区 ——> aof文件
注意,aof缓冲区的数据同步到磁盘的频率d由aof策略决定
二、AOF三种策略
1.Always 总是
每条指令都即时写入
不会丢失数据,磁盘I/O开销
2.Every second每秒
系统默认策略
每分钟写入一次
可能丢失一秒数据
3.No系统自动
不可控
3、AOF重写
随着时间得推移,aof文件日益变大。会降低磁盘性能,降低数据恢复速度。
目的:1.减少磁盘占用;2.加快恢复速度。
重写操作
方式一,客户端手动发送指令bgrewriteof
服务端fork子进程,子进程对内存中的数据进行回塑然后写入现有的aof文件。
方式二,通过配置文件触发
文件增长率
auto-aof-rewrite-percentage 100
最小文件尺寸
auto-aof-rewrite-min-size 64mb
四、AOF实验
1.redis写操作
27.0.0.1:6379> set hello world
OK
127.0.0.1:6379> set hello php
OK
127.0.0.1:6379> set hello java
OK
127.0.0.1:6379> set hello jack
OK
127.0.0.1:6379> set zhang san
OK
127.0.0.1:6379> set li si
OK
127.0.0.1:6379> set li xiaolong
OK
上述操作多次覆写hello,li两个key。
2.查看aof日志文件
$ sudo cat -b /var/lib/redis/appendonly.aof
1 REDIS0009� redis-ver5.0.3�
� 2 redis-bits�@�ctime��]used-mem�غ
aof-preamble��$e���q �*2
3 $6
4 SELECT
5 $1
6 0
7 *3
8 $3
9 set
10 $5
11 hello
12 $5
13 world
14 *3
15 $3
16 set
17 $5
18 hello
19 $3
20 php
21 *3
22 $3
23 set
24 $5
25 hello
26 $4
27 java
28 *3
29 $3
30 set
31 $5
32 hello
33 $4
34 jack
35 *3
36 $3
37 set
38 $5
39 zhang
40 $3
41 san
42 *3
43 $3
44 set
45 $2
46 li
47 $2
48 si
49 *3
50 $3
51 set
52 $2
53 li
54 $8
55 xiaolong
3.重写aof
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
4.查看重写后的aof日志文件
whqlkj@whqlkj:~$ sudo cat -b /var/lib/redis/appendonly.aof
1 REDIS0009� redis-ver5.0.3�
� 2 redis-bits�@�ctime����]used-mem�ػ
aof-preamble���zhangsanlxiaolonghellojack��XȰ-���
五、RDB与AOF对比
对比环节 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
数据恢复速度 | 快 | 慢 |
文件大小 | 小(rdb二进制压缩文件) | 大(重写后的日志记录文件) |
数据安全 | rdb丢失数据(可能会丢失最后一次save/bgsave快照之后操作的数据) | aof根据策略决定(详见3种同步策略) |
操作重量级 | 重(rdb快照) | 轻(aof追加日志) |
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。