redis的AOF

redis 提供了两种持久化方式—— RDB(Redis DataBase) 和 AOF(Append Only File) ，可以将 Redis 在内存中的数据库状态保存到磁盘里。
RDB快照并不是很可靠。如果服务器突然宕机了，最新的数据就会丢失。除了 RDB 持久化功能之外，Redis 还提供了 AOF(Append Only File) 持久化功能。

AOF (Append Only File) 持久化默认是关闭的，将 redis.conf 中将 appendonly no，修改为 appendonly yes 来开启AOF 持久化功能，服务器开始了 AOF 持久化功能，服务器会优先使用 AOF 文件来还原数据库状态

AOF 后台重写，其实是BGREWRITEAOF 命令的执行，AOF重写的工作原理：

随着AOF记录数据的变化过程，越来越大，需要重写“瘦身”，Redis可以在 AOF体积变得过大时，自动地在后台(Fork子进程)对 AOF进行重写。重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。

子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存， 该缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外， 还会追加到这个缓存中。

当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号， 父进程在接到完成信号之后， 会调用一个信号处理函数， 并完成以下工作:

将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。

对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

在整个 AOF 后台重写过程中， 只有最后的写入缓存和改名操作会造成主进程阻塞， 在其他时候， AOF 后台重写都不会对主进程造成阻塞， AOF 重写对性能造成的影响降到了最低。