AOF写后日志，避免宕机数据丢失

写前日志（WAL，Write Ahead Log）：在实际写数据之前，将修改的数据写到日志文件中，故障恢复得以保证。
比如 MySQL Innodb 存储引擎中的 redo log（重做日志）便是记录修改的数据日志，在实际修改数据前先记录修改日志再执行修改数据。

写后日志：先执行“写”指令请求，将数据写入内存，再记录日志。

1.什么是AOF写后日志？

AOF（Append Only File）写后日志，AOF 持久化就是将修改数据库状态的命令保存到 AOF 文件中，被写入的命令都是以 Redis 的命令请求协议格式保存的，Redis 的命令请求协议是纯文本格式。

假设 AOF 日志记录了 Redis 实例创建以来所有的修改指令序列，那么就可以通过一个空的 Redis 实例顺序执行所有的指令，也就是“重放”，来恢复Redis当前实例的内存数据结构的状态。

image.png

日志格式

当 Redis 接收到 “set key value” 命令将数据写入到内存之后，会按照如下格式写入 AOF 文件：

*3：表示当前指令分为三个部分，每部分都是 “$ + 数字” 开头，紧跟后面是该部分具体的命令、键、值
数字：表示这部分的命令、键、值占用的字节大小。比如 “$3” 表示这部分包含三个字节，也就是 set 指令。

image.png

写后日志的好处

写后日志避免了额外的检查开销，不需要对执行的命令进行语法检查。
如果使用写前日志的话，就需要先检查语法是否有误，否则日志记录了错误的命令，在使用日志恢复的时候就会报错。
另外，写后记录日志，避免了阻塞当前“写”指令的执行。

2.写回策略

使用 AOF 也不是万无一失的，假如 Redis 刚执行完指令，还没记录日志就宕机了，就有可能丢失这个命令的相关数据；还有， AOF 避免了当前命令的阻塞，但是可能会给下一个命令带来阻塞的风险。
AOF 日志是主线程执行的，将日志写入磁盘过程中，如果磁盘压力过大就会导致磁盘写操作很慢，导致后续的“写”指令阻塞。

发现了没？这两个问题与磁盘写回有关。
如果能合理控制“写”指令执行完后 AOF 日志写回磁盘的时机，问题就可以迎刃而解。

为了提高文件的写入效率，当用户调用 write 函数，将一些数据写入到文件时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里，等到缓冲区的空间被填满或者超过了制定的限制之后，才真正将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里的写入数据将会丢失。

为此系统提供了 fsync 和 fdatasync 两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

与之相对应 Redis 提供了 AOF 配置项 appendfsync 写回策略来控制 AOF 持久化功能的效率和安全性。

# 同步写回，写指令执行完毕立即将 aof_buf 缓冲区中的内容写到 AOF 文件
appendfsync always     

# 每秒写回，写指令执行完毕，把日志写到 aof_buf 缓冲区，每隔一秒同步到磁盘，该策略为AOF的默认策略
appendfsync everysec   

# 操作系统控制，写指令执行完毕，把日志写到 aof_buf 缓冲区，由操作系统决定何时写回磁盘
appendfsync no