【redis】AOF 的基本工作机制，顺序写入，文件同步，重写机制

RDB 最大的问题，就是不能实时的持久化保存数据，在两次生成快照之间，实时的数据可能会随着重启而丢失

基本工作机制

AOF：append only file，类似于 MySQL 的 binlog，会把每个用户的每个操作，都记录到文件中。当 redis 重新启动的时候，就会读取 AOF 文件中的内容，用来恢复数据

• 当开启 AOF 的时候，RDB 就不生效了。（启动的时候就不再读取 RDB）

• AOF 文件和 RDB 文件的位置一样

• AOF 是一个文本文件，每次进行的操作，都会被记录到文本文件中
• 通过一些特殊的符号作为分隔符，来对命令的细节做出区分
• 可以看到，重启服务器之后，还有先前的数据

AOF 工作流程

Redis 虽然是一个单线程的服务器，但是速度很快。为什么速度快？重要原因是其只操作内存。引入 AOF 之后，又要写内存，又要写硬盘，现在还能和之前一样快吗？

顺序写入

实际上是没有影响到 Redis 处理请求的速度：

1. 硬盘上读写数据，顺序读写的速度是比较快的（还是比内存要慢很多），随机访问则速度是比较慢的

AOF 是每次把新的操作写入到原有文件的末尾，属于顺序写入

内存缓冲区

1. AOF 机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区（大大降低了写硬盘的次数），积累一波之后，再统一写入硬盘

写硬盘的时候，写入硬盘数据的多少，对于性能影响没有很大，但是写入硬盘的次数则影响很大

文件同步

如果把数据写入到缓冲区里，本质还是在内存中呀，万一这个时候，突然进程挂了，或者主机掉电了，怎么办？是不是缓冲区中的数据就丢了？

• 对的，缓冲区中没来得及写入硬盘的数据是会丢的（又想… 又想…，是不行的，鱼和熊掌不可兼得）

Redis 给出了一些选项，让程序猿根据实际情况来决定怎么取舍——缓冲区的刷新策略

• 刷新频率越高，性能影响就越大，但数据可靠性就越高
• 刷新频率越低，性能影响就越小，但数据可靠性就越低

Redis 提供了多种 AOF 缓冲区同步⽂件策略，由参数 appendfsync 控制，不同值的含义如下图：

• always：频率最高，数据可靠性最高，性能最低
• everysec：频率较低，数据可靠性也会降低，性能会提高。每秒刷新一次（极端掉电情况，也只会损失 1s 的数据）（默认策略）
• no：频率最低，数据可靠性也是最低，性能最高

重写机制

AOF 文件持续增长，体积越来越大，会影响到下次 Redis 启动的时间，Redis 启动的时候要读取 AOF 文件的内容

上述 AOF 中的文件，有一些是冗余的

• 有一个客户端，对 Redis 进行操作
  • lpush key 111
  • lpush key 222
  • lpush key 333
  • 这些操作其实就是一个操作：lpush key 111 222 333
  • set key 111
  • del key
  • set key 222
  • del 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 占⽤⼤⼩相⽐较上次重写时增加的⽐例。