背景：RDB不足之处 1.耗时，耗性能 生成快照文件耗时，load快照文件耗时 Fork子进程网络开销 写文件磁盘I/O开销
2.不可控，丢失数据 会丢失最后一次快照最后操作的数据。
一、工作流程 Redis写操作命令 ——> aof缓冲区 ——> aof文件
注意，aof缓冲区的数据同步到磁盘的频率d由aof策略决定
二、AOF三种策略
1.Always 总是
每条指令都即时写入 不会丢失数据，磁盘I/O开销
2.Every second每秒
系统默认策略 每分钟写入一次 可能丢失一秒数据
系统自动
不可控
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追加日志) |
