redis 通过aof日志恢复_redis - aof持久化介绍

AOF简介

redis持久化存储的方式有rdb序列化存储和aof(append only file)。aof就是将操作和数据以格式化指令的方式追加到操作日志的尾部，在append操作返回后，才进行实际的数据变更。AOF文件保存了历史所有的操作过程；当redis server需要数据恢复的时候，可以直接从该文件中读取日志进行重做就可以还原。

AOF配置

打开aof配置，只要在配置文件里面写入对应的参数开关，并写上对应的aof文件的位置即可。

appendonly yes

appendfilename "/data/redis/appendonly.aof"

aof写磁盘有三种方式

appendfsync always

每次都是要刷入磁盘 这样的话就是会卡io

appendfsync everysec

每秒刷一次

appendfsync no

操作系统自己刷

aof重写

aof文件是以追加的方式家路日志，随着时间的推移，这个文件就会越来越大；并且一些key已经被删除了，日志里面还记录了一些操作里面，就不必要了，记录太多也会影响启动恢复速度。这时候就可以将aof文件进行序列化操作，然后再进行aof，这样子文件就会变小。

auto-aof-rewrite-percentage 100

涨的百分比 0就是不rewrite

auto-aof-rewrite-min-size 64mb

最小开始rewrite的大小

redis 重写是启用一个新的子进程，然后在子进程里面把rdb里面的数据序列化到新的aof文件中。在子进程写rdb的过程中，使用pipe通信来把主进程新的修改接收保存。在rbd写完之后追加到aof文件中。报告写入完成，停止接受新的修改最后结束。主进程把aof文件替换。也把子进程到主进程切换过程中的写入追加到aof。aof_fd切换成新的fd。整个流程完成。

aof优点

使用 AOF Redis 会更具有可持久性(durable)：你可以有很多不同的 fsync 策略：没有 fsync，每秒 fsync，每次请求时 fsync。使用默认的每秒 fsync 策略，写性能也仍然很不错(fsync 是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。AOF 日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof 工具也可以很轻易的修复。AOF 文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易地导出一个 AOF 文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以。

aof缺点

aof的文件会比rdb文件大，恢复起来相对比较慢。AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。不过，即使在很大的写负载情况下，RDB 还是能提供能好的最大延迟保证。