Redis 持久化之 AOF
1. AOF 是什么？
- 以日志的形式来记录每个写操作， 将 redis 执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2. AOF 保存的是 appendonly.aof 文件
3. 配置位置
配置位置默认就是在哪个目录下启动的 redis 服务，就会在哪里进行创建，可以看我之前写过的文章【大厂面试】Redis 中的 redis.conf 配置文件详解
4. AOF启动 / 修复 / 恢复
- 正常恢复
启动：设置 yes，修改默认的 appendonly no, 改为 yes
将有数据的 aof 文件复制一份保存到对应目录 config get dir
恢复：重启 redis 然后重新加载 - 异常恢复
启动：设置 yes，修改默认的 appendonly no, 改为 yes
备份被写坏的 AOF 文件
修复：Redis-check-aof --fix aof文件名称 进行修复
恢复：重启 redis 然后重新加载即可
5. Rewrite
是什么
AOF 采用文件追加方式，文件会越来越大为了避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof
重写原理
AOF文件持续增长而过大时，会 fork 出一条新进程来将文件重写(也就是先写临时文件最后在 rename)，遍历新进程的内存中数据，每条记录有一条的 Set 语句，重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
触发机制
Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发
6. 优势
- 每秒同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较一致
- 每次修改同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，会有数据丢失
- 不同步：appendfsync no 从不同步
7. 劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof 运行效率要慢于 rdb，每秒同步策略效率较好，不同步效率和 rdb 相同。
8. 小总结
优势：
- AOF 文件是一个只进行追加的日志文件
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
- AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析也很轻松
劣势： - 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积
- 根据所使用的 fsync 策略，AOF 的速度可能慢于 RDB
