RDB 最大的问题，就是不能实时的持久化保存数据，在两次生成快照之间，实时的数据可能会随着重启而丢失
基本工作机制
AOF：append only file，类似于 MySQL 的 binlog，会把每个用户的每个操作，都记录到文件中。当 redis 重新启动的时候，就会读取 AOF 文件中的内容，用来恢复数据
- 当开启
AOF的时候，RDB就不生效了。（启动的时候就不再读取RDB）
AOF文件和RDB文件的位置一样
AOF是一个文本文件，每次进行的操作，都会被记录到文本文件中- 通过一些特殊的符号作为分隔符，来对命令的细节做出区分
- 可以看到，重启服务器之后，还有先前的数据
AOF 工作流程
Redis 虽然是一个单线程的服务器，但是速度很快。为什么速度快？重要原因是其只操作内存。引入 AOF 之后，又要写内存，又要写硬盘，现在还能和之前一样快吗？
顺序写入
实际上是没有影响到 Redis 处理请求的速度：
- 硬盘上读写数据，顺序读写的速度是比较快的（还是比内存要慢很多），随机访问则速度是比较慢的
AOF 是每次把新的操作写入到原有文件的末尾，属于顺序写入
内存缓冲区
AOF机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区（大大降低了写硬盘的次数），积累一波之后，再统一写入硬盘
写硬盘的时候，写入硬盘数据的多少，对于性能影响没有很大，但是写入硬盘的次数则影响很大
文件同步
如果把数据写入到缓冲区里，本质还是在内存中呀，万一这个时候，突然进程挂了，或者主机掉电了，怎么办？是不是缓冲区中的数据就丢了？
- 对的，缓冲区中没来得及写入硬盘的数据是会丢的（又想… 又想…，是不行的，鱼和熊掌不可兼得）
Redis 给出了一些选项，让程序猿根据实际情况来决定怎么取舍——缓冲区的刷新策略
- 刷新频率越高，性能影响就越大，但数据可靠性就越高
- 刷新频率越低，性能影响就越小，但数据可靠性就越低
Redis 提供了多种 AOF 缓冲区同步⽂件策略，由参数 appendfsync 控制，不同值的含义如下图：
always：频率最高，数据可靠性最高，性能最低everysec：频率较低，数据可靠性也会降低，性能会提高。每秒刷新一次（极端掉电情况，也只会损失1s的数据）（默认策略）no：频率最低，数据可靠性也是最低，性能最高
重写机制
AOF 文件持续增长，体积越来越大，会影响到下次 Redis 启动的时间，Redis 启动的时候要读取 AOF 文件的内容
上述 AOF 中的文件，有一些是冗余的
- 有一个客户端，对
Redis进行操作lpush key 111lpush key 222lpush key 333- 这些操作其实就是一个操作：
lpush key 111 222 333 set key 111del keyset key 222del key- 这四个操作，什么都不做就可以了
Redis 启动时读取 AOF 内容的时候，AOF 记录了中间的过程，但 Redis 在重启的时候只关注最终结果。因此 Redis 就存在一个机制，能够针对 AOF 文件进行整理操作，这个整理就是能够剔除其中的冗余操作，并且合并一些操作，达到给 AOF 瘦身这样的效果——重写机制
比如，你每天给自己打分，买了个小本子记录
- 早起：+2 分
- 贪睡：-2 分
- 晨跑：+5 分
- 高效 1h：+2 分
- 浪费时间：-3 分
- …
记录满一页后，记录一个总分，然后翻到下一页，继续记录。哪怕前面的内容都没了也没事，只要你记得每一页的最终总分是多少就行了
触发时机
- 手动触发：调用
bgrewriteaof命令 - 自动触发：根据
auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定⾃动触发时机。auto-aof-rewrite-min-size：表⽰触发重写时AOF的最⼩⽂件⼤⼩，默认为64MB。auto-aof-rewrite-percentage：代表当前AOF占⽤⼤⼩相⽐较上次重写时增加的⽐例。