Redis持久化之AOF
Redis持久化之AOF
简单点说就是把我们所有的命令都记录下来，每一秒中修改一次。
当文件存储超过64mb时重新开启文件
appendonly no是否开启AOF，默认是关闭的，重启生效。
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仍然能够提供有关最大延迟的更多保证。
RDB一样快。即使在巨大的写负载的情况下，RDB仍然能够提供有关最大延迟的更多保证。 - 过去，我们在特定命令中遇到过罕见的错误（例如，其中有一个涉及阻止命令，例如BRPOPLPUSH），导致产生的AOF在重载时无法重现完全相同的数据集。这些错误很少见，我们在测试套件中进行了测试，自动创建了随机的复杂数据集，然后重新加载它们以检查一切是否正常。但是，对于RDB持久性来说，这类错误几乎是不可能的。为了更清楚地说明这一点：Redis AOF通过增量更新现有状态来工作，就像MySQL或MongoDB一样，而RDB快照一次又一次地创建所有内容，从概念上讲更健壮。但是-1）应当注意，每次Redis重写AOF时，都会从数据集中包含的实际数据开始重新创建AOF，与始终附加AOF文件（或重写为读取旧AOF而不是读取内存中的数据）相比，提高了对错误的抵抗力。2）我们从未收到过来自用户的关于真实环境中检测到的AOF损坏的报告。