背景: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追加日志)