AOF持久化

一、AOF概念

RDB存储的弊端

• 存储数据量较大，效率较低——基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
• 大数据量下的IO性能较低
• 基于fork创建子进程，内存产生额外消耗
• 宕机会带来数据丢失

AOF解决思路

• 不记录数据，记录操作过程
• 对均进行记录，排除丢失数据的风险

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

二、AOF写数据三种策略

always：每次写入操作均同步到AOF文件中，数据零误差，

everysec：每秒将缓冲区中的指令同步到AOF文件中，，

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

三、AOF功能配置

配置文件.conf中配置

是否开启APF持久化功能，默认为不开启

appendonly yes|no

配置AOF写策略

appendfsync always|everysec|no

修改AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

dir

测试always写策略

后台启动后，配置的数据目录下出现appendonly.aof文件，此时文件大小还是0字节

由于我们配置的AOF存储方式是always，每次写指令AOF文件都会记录

我们启动客户端，执行2个写指令

然后我们查看AOF文件中的内容

测试everysec写策略

修改配置文件中的写策略

杀掉进程后重启redis服务器

启动客户端插入一些数据

查看appendonly.aof文件

四、AOF重写机制

如果连续执行以下指令，会造成AOF文件冗余，连续三次set同一个变量是没必要的，记住最后一次set即可；同理，连续三次incr也是没有必要的，直接求和set即可

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程，简单说就是

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高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等类型，每条指令

AOF重写方式

指令方式：手动重写

bgrewriteaof

验证手动重写指令 bgrewriteaof

修改配置文件后，重启服务

客户端连接后，连续set三次

查看一下appendonly-6379.aof

手动执行bgrewriteaof指令，重写aof文件

查看aof文件，文件重写后占用空间变小了

客户端给list1中插入三个数据，并删除变量name

查看appendonly-6379.aof

客户端输入bgrewriteaof指令，重写aof文件

查看appendonly-6379.aof

bgrewriteaof指令工作原理

配置文件方式：自动重写

auto-aof-rewrite-min-size size            # size的默认大小比较大，32M或64M，超过size触发重写
auto-aof-rewrite-percentage percentage    # 超过百分比，触发AOF重写

自动重写触发对比参数（运行指令info Persistence获取具体信息）

aof_current_size
aof_base_size

自动重写触发条件

输入info指令可以获得以下信息

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1655626139
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0

五、AOF工作流程

always：主进程执行set，子进程写AOF文件中相关信息 everysec：主进程执行set，子进程先把相关信息写入AOF缓存区（突然停电，这里面的数据就丢了），时间到1s后，写入AOF文件

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

六、AOF和RDB的区别

• 占用空间： 由于很多指令可能只是对某几个数据进行操作，所以对于同样的数据量，AOF存指令会占用更多的空间
• 存储速度： 由于RDB每次都会存储所有的数据，而AOF只是追加当前的写操作，所以RDB存储较慢，AOF存储较快
• 恢复速度： RDB恢复的时候直接导入数据即可，AOF需要执行很多指令，恢复速度较慢
• 数据安全性：
• 启动优先级：如果同时启用了AOF和RDB两种持久化方式，那么AOF的启动优先级是高于RDB的
  • 因为AOF持久化方式可以记录每一个写命令，并且可以在服务重启时重新执行这些写命令来恢复数据，从而保证了数据的完整性。而RDB持久化方式则是通过定期生成快照来保存数据的，因此在两次快照之间的数据变更如果Redis服务器宕机，则这部分数据将会丢失

基于需求选择RDB和AOF

• ：AOF持久化策略使用everysecond，每秒钟持久化一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据 。注意：由于
• 持久化方案：数据可以良好的做到阶段内无丢失（**该阶段是开发者或运维人员手工维护的**），且。注意：

综合比对

• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF，因为AOF可以用always保存所有写操作
• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB，RDB恢复数据快
• 灾难恢复选用RDB，因为RDB保存的是全数据
• 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

1、如果对数据的完整性与一致性要求比较高，可以选择aof持久化；如果想让数据恢复快一些，可以使用rdb，默认情况使用的是rdb持久化方式

2、两种持久化的方式是可以一起使用的，可以起到互补的作用。

3、如果只有aof持久化方式，是可以启动redis服务器的。如果aof是唯一的持久化方式，但是aof文件被损坏了，那么redis服务器是启动不成功的。

4、如果aof持久化是唯一的方式，那么aof文件损坏之后，服务器不能正常启动，但是可以通过命令修复aof文件。

image-20230704163821497