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损坏的报告。