一、AOF概念
RDB存储的弊端
- 存储数据量较大，效率较低——基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程，内存产生额外消耗
- 宕机会带来数据丢失
AOF解决思路
- 不记录数据，记录操作过程
- 对所有操作均进行记录，排除丢失数据的风险
AOF（append only file）持久化：不记录数据，只是以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式（优先用AOF，再使用RDB）
二、AOF写数据三种策略
always：每次写入操作均同步到AOF文件中，数据零误差，性能较低，一般不建议使用
everysec：每秒将缓冲区中的指令同步到AOF文件中，数据准确性高，性能较高，再系统突然当即的情况下最多丢失1秒内的数据，一般建议使用，同时也是默认配置
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重写机制压缩文件体积。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等类型，每条指令最多写入64个元素
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需要执行很多指令，恢复速度较慢
- 数据安全性： RDB快照频率高则丢失数据少，快照频率低则丢失数据多；AOF设置always记录所有指令，不丢数据，everysec可能丢1s数据
- 启动优先级： AOF是redis默认的持久化方式，优先级高于RDB，当数据量很大时RDB每存一次都需要消耗一定时间
基于需求选择RDB和AOF
- 对数据非常敏感，建议使用默认的AOF持久化方案，丢数据更少：AOF持久化策略使用everysecond，每秒钟持久化一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据 。注意：由于AOF文件存储体积较大，恢复速度较慢
- 数据呈现阶段有效性，建议使用RDB持久化方案：数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案。注意：利用RDB实现紧凑的数据持久化会使Redis降的很低
综合比对
- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF，因为AOF可以用always保存所有写操作
- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB，RDB恢复数据快
- 灾难恢复选用RDB，因为RDB保存的是全数据
- 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
