【redis 五】Redis持久化之aof
前言
上一篇文章详细的介绍了redis RDB持久化，详细的讲述了其原理优缺点，接下来着重讲解AOF持久化。
1、官网介绍
地址：https://redis.io/topics/persistence
以下内容为有道词典翻译
AOF持久性会记录服务器接收的每个写入操作，这些操作将在服务器启动时再次播放，以重建原始数据集。使用与Redis协议本身相同的格式记录命令，并且采用仅追加方式。当日志太大时，Redis可以在后台重写日志。
如果您希望，只要您的数据在服务器运行时就一直存在，则可以完全禁用持久性。
可以在同一实例中同时合并AOF和RDB。请注意，在这种情况下，当Redis重新启动时，AOF文件将用于重建原始数据集，因为它可以保证是最完整的。
AOF的优势
使用AOF Redis更加持久：您可以使用不同的fsync策略：完全没有fsync，每秒fsync，每个查询fsync。使用默认策略fsync时，每秒的写入性能仍然很好（fsync是使用后台线程执行的，并且在没有进行fsync的情况下，主线程将尝试执行写入操作。），但是您只能损失一秒钟的写入时间。
AOF日志是仅追加的日志，因此，如果断电，则不会出现寻道或损坏问题。即使由于某种原因（磁盘已满或其他原因）以半写命令结束日志，redis-check-aof工具也可以轻松修复它。
Redis太大时，Redis可以在后台自动重写AOF。重写是完全安全的，因为Redis继续追加到旧文件时，会生成一个全新的文件，其中包含创建当前数据集所需的最少操作集，一旦准备好第二个文件，Redis会切换这两个文件并开始追加到新的那一个。
AOF以易于理解和解析的格式包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您使用FLUSHALL命令刷新了所有错误文件，如果在此期间未执行任何日志重写操作，您仍然可以保存数据集，只是停止服务器，删除最新命令并重新启动Redis。
AOF的缺点
对于同一数据集，AOF文件通常大于等效的RDB文件。
根据确切的fsync策略，AOF可能比RDB慢。通常，在将fsync设置为每秒的情况下，性能仍然很高，并且在禁用fsync的情况下，即使在高负载下也应与RDB一样快。即使在巨大的写负载的情况下，RDB仍然能够提供有关最大延迟的更多保证。
过去，我们在特定命令中遇到过罕见的错误（例如，其中有一个涉及阻止命令，例如BRPOPLPUSH），导致生成的AOF在重载时无法重现完全相同的数据集。这些错误很少见，我们在测试套件中进行了测试，自动创建了随机的复杂数据集，然后重新加载它们以检查一切是否正常。但是，RDB持久性几乎是不可能的。为了更清楚地说明这一点：Redis AOF通过增量更新现有状态来工作，就像MySQL或MongoDB一样，而RDB快照一次又一次地创建所有内容，从概念上讲更健壮。但是-1）应该注意的是，每次Redis重写AOF时，都会从数据集中包含的实际数据开始重新创建AOF，与始终附加AOF文件（或重写为读取旧AOF而不是读取内存中的数据）相比，提高了对错误的抵抗力。2）我们从未收到过有关真实环境中检测到的AOF损坏的用户报告。
2、简单理解
官网给出了一大堆的解释，其实还是很好容易理解的，下面是硅谷阳哥的导图笔记内容：
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
3、AOF启动/修复/恢复
aof保存的是appendonly.aof文件
（1）启动
配置文件中，修改默认的appendonly no，改为yes
输入命令config get dir找到appendonly存放的位置，如下图是在data下
我们打开data文件：发现了appendonly.aof
(2) 正常恢复
将有数据的aof文件复制一份保存到对应目录(config get dir)
重启redis然后重新加载
(3) 异常恢复(由于种种原因，比如网速导致的aof文件不能用报错)
备份被写坏的AOF文件
修复：redis-check-aof --fix进行修复，实际上就是将不符合aof语法规则的语句删掉
恢复：重启redis然后重新加载
4、aof重写（rewrite）
概念：
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof触发重写机制
重写原理:
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍（对应下图的100）且文件大于64M时触发,但是在生产环境中肯定比64M要大的多，比如你到一家公司后，可以看看这家公司的redis的配置文件，这块的值，就知道这家公司用Redis怎么样了
5、同时开启aof和rdb两个持久化，redis是怎么运行的
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
那么此时能不能只使用aof呢，不能，因为aof在不断的变化，不好备份，而且可能由于一些网络原因aof出错，此时rdb的存在还是很有必要的
5、aof优缺点小结
优点：
备份机制键稳，丢失数据概率低
有可读的日志文件
缺点
比rdb方式占用更多的磁盘空间
比rdb恢复备份速度慢，如下fsync(同步)参数设置
appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失（默认参数）
6、小结
（1）如果我们只用redis做缓存，那么根本不需要持久化
（2）RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
（3）AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
（4）两种持久化方式同时存在，先载入aof文件恢复数据