[Redis][持久化][下][AOF]详细讲解

AOF_3">1.AOF

1.是什么？

AOF(Append Only File)持久化：以独⽴⽇志的⽅式记录每次写命令，重启时再重新执⾏AOF⽂件中的命令达到恢复数据的⽬的
- 当开启AOF的时候，RDB就不生效了
AOF 的主要作⽤是解决了数据持久化的实时性
⽬前已经是Redis持久化的主流⽅式，理解掌握好AOF 持久化机制对我们兼顾数据安全性和性能⾮常有帮助

AOF_13">2.使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启
AOF⽂件名通过appendfilename配置(默认是appendonly.aof)设置
保存⽬录同RDB持久化⽅式⼀致，通过dir配置指定
AOF 的⼯作流程操作：命令写⼊(append)、⽂件同步(sync)、⽂件重写(rewrite)、重启加载(load)
- 所有的写入命令会追加到aof_buf(缓冲区)中
- AOF缓冲区根据对应的策略向硬盘做同步操作
- 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
- 当Redis服务器启动时，可以加载AOF文件进行数据恢复

3.命令写入

AOF命令写⼊的内容直接是⽂本协议格式
- 例如：set hello world这条命令，在AOF缓冲区会追加如下⽂本：
```
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
```
此处遵守Redis格式协议，Redis选择⽂本协议可能的原因：⽂本协议具备较好的兼容性；实现简单；具备可读性
AOF过程中为什么需要aof_buf这个缓冲区？
- Redis使⽤单线程响应命令，如果每次写AOF⽂件都直接同步硬盘，性能从内存的读写变成IO读写，必然会下降
- 先写⼊缓冲区可以有效减少IO次数，同时，Redis还可以提供多种缓冲区同步策略，让⽤⼾根据⾃⼰的需求做出合理的平衡
AOF既要写内存，又要写硬盘，速度还能和之前一样快了么？
- 实际上，没有影响
- AOF机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区，积累一波之后，再统一写入硬盘
- 硬盘上读写数据，顺序读写的速度是比较快的(虽然还是比内存要慢得多)，随机访问则速度是比较慢的
  - AOF每次把新的数据写入到原有文件的末尾，属于顺序写入
把数据写入到缓冲区里，本质还是在内存中，万一某个时间，突然进程挂了或者主机掉点了，会怎样？缓冲区中的数据是不是就丢了？
- 是的，缓冲区中没来得及写入硬盘的数据是会丢的
- 取舍 -> 缓冲区的刷新策略

4.文件同步

Redis提供了多种AOF缓冲区同步⽂件策略，由参数appendfsync控制

可配置值	说明
`always`	命令写⼊`aof_buf`后调⽤`fsync`同步，完成后返回
`everysec`	命令写⼊`aof_buf`后只执⾏`write`操作，不进⾏ `fsync`。每秒由同步线程进⾏`fsync`
no	命令写⼊`aof_buf`后只执⾏`write`操作，由OS控制`fsync`频率

系统调用write和fsync说明：
- write操作会触发延迟写(delayed write)机制
  - Linux在内核提供⻚缓冲区⽤来提高硬盘IO性能
  - write操作在写⼊系统缓冲区后⽴即返回
  - 同步硬盘操作依赖于系统调度机制
    - 例如：缓冲区⻚空间写满或达到特定时间周期。同步⽂件之前，如果此时系统故障宕机，缓冲区内数据将丢失
- Fsync针对单个⽂件操作，做强制硬盘同步，fsync将阻塞直到数据写⼊到硬盘
- 配置为always时，每次写⼊都要同步AOF⽂件，性能很差，在⼀般的SATA硬盘上，只能⽀持⼤约⼏百TPS写⼊
  - 除⾮是⾮常重要的数据，否则不建议配置
- 配置为no时，由于操作系统同步策略不可控，虽然提⾼了性能，但数据丢失⻛险⼤增
  - 除⾮数据重要程度很低，⼀般不建议配置
- 配置为everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能,理论上最多丢失1 秒的数据

5.重写机制

随着命令不断写⼊AOF，⽂件会越来越⼤，为了解决这个问题，Redis引⼊AOF重写机制压缩⽂件体积
AOF⽂件重写是把Redis进程内的数据转化为写命令同步到新的AOF⽂件
重写后的AOF为什么可以变小？
- 进程内已超时的数据不再写⼊⽂件
- 旧的AOF中的⽆效命令，例如del、hdel、srem等重写后将会删除，只需要保留数据的最终版本
- 多条写操作合并为⼀条，例如lpush list a、lpush list b、lpush list可以合并为lpush list a b c
- 重写的时候，不关心AOF文件中原来都有啥，只是关心内存中最终的数据状态
  - 子进程只需要把内存中当前的数据，获取出来，以AOF的格式写入到一个新的AOF文件中即可
  - 内存中的数据的状态，就已经相当于是把AOF文件结果整理后的模样了
较⼩的AOF⽂件⼀⽅⾯降低了硬盘空间占⽤，⼀⽅⾯可以提升启动Redis时数据恢复的速度
AOF重写过程可以手动触发和自动触发
- 手动触发：调用bgrewriteaof命令
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定⾃动触发时机
  - auto-aof-rewrite-min-size：表⽰触发重写时AOF的最⼩⽂件⼤⼩，默认为64MB
  - auto-aof-rewrite-percentage：代表当前AOF占⽤⼤⼩相⽐较上次重写时增加的⽐例
当触发AOF重写时，运行流程：
- 执行AOF重写请求：
  - 如果当前进程正在执⾏AOF重写，请求不执⾏
  - 如果当前进程正在执⾏bgsave操作，重写命令延迟到bgsave完成之后再执⾏
- 父进程执行fork创建子进程
- 重写：
  - 主进程 fork之后，继续响应其他命令，所有修改操作写⼊AOF缓冲区并根据appendfsync策略同步到硬盘，保证旧AOF⽂件机制正确
  - ⼦进程只有fork之前的所有内存信息，⽗进程中需要将fork之后这段时间的修改操作写⼊AOF重写缓冲区(aof_rewrite_buf)中，专门放fock之后收到的数据
  - 子进程把AOF数据写完之后，会通过信号通知一下父进程，父进程再把aof_rewrite_buf缓冲区中的内容也写入到新的AOF文件里，此时就可以用新的AOF文件替代旧的AOF文件了
父进程是否有必要继续写一个即将消亡的旧的AOF文件？还有意义么？
- 考虑到极端情况，如果重新过程中，服务器挂了，子进程内存的数据就会丢失，新的AOF文件内容还不完整
- 所以如果父进程不坚持写就得AOF文件，重启就没办法保证数据的完整性了

6.启动时数据恢复

当Redis启动时，会根据RDB和AOF文件的内容，进行数据恢复

7.混合持久化

情景：AOF本来是按照文本的方式来写入文件的，但是文本的方式写入文件，后续加载的成功是比较高的
Redis引入了"混合持久化"，结合了RDB和AOF的特点
- 开启：配置文件中aof-use-rdb-preamble yes4
流程：
- 按照AOF的方式，每一个请求/操作，都录入文件
- 在触发AOF重写之后，就会把当前内存的状态按照RDB的二进制格式写入到新的AOF文件中
- 后续再进行操作，仍然是按照AOF文本的方式追加到文件后面