概述
这篇讲的时AOF优化:
4.0 redis 引入了混合AOF (也就是前面一段二进制快照数据，后面一段AOF 日志)，优化的是AOF文件大，数据恢复速度慢的问题.
5.0 以后默认开启混合AOF
7.0 redis 加入MPAOF，这里优化的是AOF/混合AOF 备份过程中有新指令要追加写，新指令会被追加到主进程aof_rewrite_buf 和 通过管道将新指令发送给备份子进程的双双拷贝问题。
混合AOF
混合AOF 是什么？
混合AOF 不是同时开启RDB + AOF
混合AOF 是结合了RDB和AOF 二者优点的折中选择，就是AOF文件前半部分是RDB二进制数据快照，后半部分是混合AOF备份过程中新来的追加指令.
如何开启混合AOF？
在redis.conf AOF 配置段中设置字段 aof-use-rdb-preamble 为yes 即可
# Redis can create append-only base files in either RDB or AOF formats. Using
# the RDB format is always faster and more efficient, and disabling it is only
# supported for backward compatibility purposes.
aof-use-rdb-preamble yes混合AOF改进了什么？
这里先分析 RDB 和 AOF 优缺点再说改进，因为混合AOF 更像是 RDB 和 AOF 二者的折中方案:
RDB优缺点
优点:
文件体积小
文件载入恢复快
缺点:
文件不支持追加，再备份的时候，如果有新数据增删改，不会加入备份
海量数据场景下备份，如果中间有数据增删改，主进程就会需要去操作对应数据，这时候linux 就会进行cow 行为（拷贝当前进程的数据到新开的物理映射空间并修改页表指向），这个动作是耗费系统资源的(CPU、内存 ...)
备份过程中或者未到备份触发时刻，如果宕机，数据会丢
AOF优缺点
优点:
日志形式的备份文件，每执行一条指令就追加写一条指令到AOF文件中，数据一致性高（丢的数据不多）
允许备份期间追加新指令到AOF文件中
缺点:
文件大
命令重放，恢复慢
改进了什么?
二者折中，改进了AOF 文件体积大的问题
改进了RDB备份期间不能追加写
改进了AOF 数据恢复慢
混合AOF基本工作原理？
步骤见下:
主进程检查有无AOF进程正在备份，有返回，无创建AOF进程
获取全部数据，将加上混合AOF 文件头信息的二进制数据写入到新创建好的混合AOF 文件中；示例见下
将后续追加进来的指令冲aof_rewrite_buf 中写入内核，根据配置文件配置刷盘
将新文件替换旧文件
混合AOF 恢复数据流程
看图
MPAOF
MPAOF 是什么？
一个将混合AOF RDB 和 操作日志分离，解决AOF 日志重写时如果有新命令追加，需要同时写入新旧两个AOF 文件，不合理占用I/O 资源的问题的解决方案，这个方案再7.0 上引入.
如何开启MPAOF？
配置方式和原 混合AOF 配置方式选项一样 (直接再原混合AOF上优化的)
MPAOF改进了什么？
又偷了下大佬的图
MPAOF基本工作原理？
看图
文件说明:
.base 文件：MPAOF 流程开始后，dump出的数据镜像文件,只存储二进制数格式镜像数据.
.incr 文件：重写AOF 文件过程中新追加过来的命令会追加写到改文件中
.manifest 文件: 清单文件，记录当前最新版本的.base、.incr 文件时那个，方便恢复时根据清单文件直接载入
MPAOF数据备份大致流程流程:
1.fork 出来的进程只重写.base 数据二进制镜像文件
2.如果有新命令需要追加，由主进程写入到aof_buf，再刷盘
3.更新清单文件，标志整个MPAOF 重写完成.
4.MPAOF 备份完成后，不会马上删除旧文件，而是将文件后缀加入.history 表示时旧 MPAOF 文件,稍后就才会被后台异步删除