9.Redis持久化之AOF
9.1简介
AOF (Append Only File) 以日志的形式来记录每个写操作(增量保存)，将Redis执行过的所有指令记录下来（读操作不记录），只允许追加文件但不可以改文件，Redis启动之初会读取该文件重构数据,换言之，重启的话就根据日志文件内容将写指令从前到后执行一次以完成数据的恢复工作。
9.2 AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内。
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量。
（4）Redis服务启动时，会重新load加载AOF文件中的写操作达到数据恢复的目的。
9.3 AOF默认不开启
可以在redis.conf中配置文件名称，默认为appendonly.aof
AOF文件的保存路径，同RDB的路径一致。
9.4 AOF和RDB同时开启，redis听谁的？
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）
9.5 AOF启动/修复/恢复
1.AOF的备份机制和性能虽然和RDB不同，但是恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
2.正常恢复
修改默认的appendonly no，改为 yes
将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）
恢复：重启redis然后重新加载
3.异常恢复
修改默认的appendonly no，改为 yes
如果遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复
备份被写坏的AOF文件
恢复：重启Redis，然后重新加载
9.6 重写流程
触发条件：如果Redis的 AOF 当前大小 >= base_size + base_size * 100% (默认)且当前大小>=64mb的情况下，Redis会对AOF进行重写。
（1）bgrewriteaof触发重写，判断当前有bgsave或者bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
（2）主进程fork出子进程尽心那个重写操作，保证主进程不会阻塞。
（3）子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
（4）子进程写完新的AOF文件后，向主进程发送信号，父进程更新统计信息。
主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
9.7 优点
1）备份数据更稳健，丢失数据概率更低
2）可读的aof文件，通过操作aof文件，可以处理误操作。
9.8 劣势
1）比起RDB占用更多的磁盘空间。
2）恢复备份数据速度慢
3）每次读写都同步的话，有一定的性能压力。
4）存在个别bug，造成恢复不能。
665
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
