AOF持久化
AOF全称append only file持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的：
AOF主要作用是解决了数据实时持久化的问题；
使用AOF
开始AOF需要设置appendonly yes，默认不开启。
AOF文件名通过appendonlyname配置，默认文件名为appendonly.aof：
AOF工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（reload）:
- 所有写入命令会追加到aof_buf缓冲区中
- AOF缓冲区根据对应的策略向硬盘做同步操作
- 随着AOF文件越来越大，需要定期对AOF文件做重写，达到压缩目的
- 当Redis服务器重启时，可以加载AOF文件进行数据恢复。
命令写入
- 采用文本协议格式具有更好的兼容性
- 开始AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免二次处理开销
- 文本协议具有可读性，方便直接修改和处理
- AOF通过追加到aof_buf缓冲区的方式，避免了直接追加到硬盘慢的问题，因为缓冲区时内存中的，相对于硬盘有更好的写入速度。另外，Redis可以提供多中缓冲区同步硬盘的策略；
文件同步
指缓存区数据同步到AOF文件的过程，有参数appendfsync控制；
- always：命令写入aof_buf后调用系统fsync操作同步到aof文件
- everysec：命令写入aof_buf后调用write操作，write完成后线程返回，fsync同步文件操作由专门线程每秒调用一次
- no：命令写入aof_buf后，调用系统write操作，不对aof文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期为最长30秒；
write操作：触发延迟写机制，Linux在内核提供页缓存区用于提高硬盘IO性能，write操作在写入系统缓冲区后直接返回，同步 硬盘草最依赖于系统调度机制；
fsync操作：针对单个文件操作，比如aof文件，做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
重写机制
AOF文件越来越大，Redis提供了重写机制压缩文件体积。
AOF文件重写是把Redis进程内的数据转化为写命令同步到AOF文件的过程；
- 进程内已经超时的数据不在写入文件
- 旧的AOF文件含有无效命令，重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令；
- 多条写命令可以合并为一个。为了防止单条命令过大导致客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64位元素为界拆分为多条。
AOF重写后占用更少的空间；
AOF重写后文件更小，被Redis加载速度更快；
AOF重写触发过程：
- 手动触发：调用bgrwriteaof命令
- 自动触发：使用auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机；
auto-aof-rewrite-min-size：表示运行aof重写时文件最小体积，默认64M
auto-aof-rewrite-percentage：代表当前aof文件空间和上一次重写后aof文件空间的比例；
AOF重写流程：
- 执行AOF重写命令
- 父进程执行fork创建子进程，开销等同于bgsave
- 主进程fork进程后，继续响应其他请求，所有写命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性；
- 由fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据；由于父进程依然响应命令，Redis使用“AOF重写缓冲区”技术保存这部分数据，防止新的AOF文件生成期间丢失这部分数据；
- 子进程根据内存快照，按照命令合并规则写入到新的AOF文件，需要控制每次写入量，防止硬盘阻塞；
- 新的AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息
- 父进程把aof重写缓冲区的数据写入到新的aof文件
- 使用新的aof文件替换老文件，完成aof重写；
重启加载
- AOF持久化开启且存在AOF文件时，优先加载aof文件
- aof关闭或者aof不存在时，加载rdb文件
- 加载aof/rdb文件成功后，redis启动成功
- aof/rdb文件存在错误时，redis启动失败并打印错误信息
文件校验
aof损坏时，使用redis-check-aof --fix命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以人工修改补全。