redis系列(四)：AOF持久化

RDB是存储了当前时间节点的数据库全量快照。
AOF持久化是通过保存redis所执行的所有命令来记录数据的。

select.png

就比如这个图。是把每一行命令都写在文件里。恢复的时候，再一行一行执行。（个人感觉比较像mysql的redolog）。

写入过程

AOF持久化的实现分为三个步骤：

• 追加（append）
• 文件写入
• 文件同步（sync）

追加

不可能是一条命令执行完，就直接写到文件中。这样频繁读写文件，性能不就完了。
所以，AOF有一层缓存，aof_buf。先写到aof_buf中。再通过某种策略将aof_buf刷到物理文件中。

写入与同步

写入与同步其实是一个事

在现代os中，为了提高文件的写入操作，当用户调用到write函数将数据写入文件时，os先将数据写入到一个内存缓冲区里，正常是等到缓冲区满了或是规定时间到了，才真正地将缓冲区里的数据写入磁盘，这时才是持久化完成。
类似你用记事本写东西一样，写完之后你会Ctrl+v（保存），但是在没执行Ctrl+v的时候你也能看到自己写的，这时因为保存在内存缓冲区里了，然后你保存了，这才保存到磁盘了，所以我们可以把你写东西当做是对aof文件的写入，你执行Ctrl+v才是同步到磁盘操作。
这样虽然大大提高了效率，但是很不安全，在你写了好多字时，卡，忽然电脑停机了，写的东西全没了

将aof_buf刷到物理文件的策略都有什么呢？

同步策略	行为
always	写完aof_buf，就直接写入并同步AOF文件
everysec	每秒异步同步一次。默认策略
no	不同步

追加aof_buf的时机

在每次redis执行命令的时候。执行完命令，写入aof_buf。再策略刷脏页。

加载AOF文件的时机

在redis启动的时候，如果redis开启了AOF，则加载AOF文件。redis，AOF开关默认是关闭的。

AOF重写

栗子：当这么执行redis命令的时候

> rpush list "A" "B" // ["A", "B"]

> rpush list "C"     // ["A", "B", "C"]

> rpush list "D" "E" // ["A", "B", "C", "D", "E"]

> lpop list         // ["B", "C", "D", "E"]

> lpop list         // ["C", "D", "E"]

> rpush list "F" "G" // ["C", "D", "E", "F", "G", ]

那么aof_buf中保存了6条命令。对于实际情况，可能操作的更加频繁，针对于一个key，aof_buf中记录的数据太多了。

这时候就要触发AOF重写了。
当触发AOF重写时。直接去数据库中取list的值，然后用一条

rpush list "C" "D" "E" "F" "G" 
// ["C", "D", "E", "F", "G", ]

来代替之前的6条。
重点：压缩的AOF文件，不是去老的AOF文件中读出来的，而是从redis数据库中读出来的。

AOF重写是，fork出子进程来执行的，不会阻塞主进程。

重写的触发条件

• 手动执行 BGREWRITEAOF 命令
• 开启AOF后会有三个配置

  auto-aof-rewrite-min-size 64MB   // 当文件小于64M时不进行重写
  auto-aof-rewrite-min-percenrage 100  // 当文件比上次重写后的文件大100%时进行重写

重写的过程

• 从主进程中fork出子进程，并拿到fork时的AOF文件数据写到一个临时AOF文件中
• 在重写过程中，redis收到的命令会同时写到AOF缓冲区和重写缓冲区中，这样保证重写不丢失重写过程中的命令
• 重写完成后通知主进程，主进程会将AOF缓冲区中的数据追加到子进程生成的文件中
• redis会原子的将旧文件替换为新文件，并开始将数据写入到新的aof文件上

关于重写机制需要注意以下几点：

• 执行重写时如果发现有进程正在执行重写，那么直接返回。如果有进程正在执行BGSAVE，那么会等BGSAVE执行完成后再执行重写。
• Redis执行重写时会fork一个进程进行，其开销和RDB一样
• 重写过程不影响原有的AOF过程，write，save操作都不影响
• 重写过程中有几种时刻会阻塞主进程： 在fork子进程时，将重写缓冲区的数据写到磁盘上时，使用新AOF文件替换旧文件时

AOF 和 RDB 如何抉择

• 不要仅仅使用RDB，因为那样会导致你丢失更多的数据。RDB备份的频率相对没有那么频繁。(RDB会丢失更多的数据)

• 也不要仅仅使用AOF，第一：通过AOF做冷备，没有RDB做冷备恢复的速度快。第二：RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF复杂的备份和恢复机制bug。（AOF的数据恢复速度没有RDB来的快，RDB备份机制方便快捷）

• 综合使用AOF和RDB两种持久化机制，使用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB做不同程度的冷备，当AOF备份文件丢失或损坏不可用时，可以使用RDB快照文件快速的恢复数据。