9 Redis 持久化AOF

文章目录

1 AOF（append only file）
- 1.1 AOF是什么
- 1.2 AOF 持久化流程
- 1.3 AOF 默认不开启
- 1.4 AOF 和RDB同时开启听谁的
- 1.5 AOF启动修复恢复
- 1.6 AOF 同步频率
- 1.7 Rewrite压缩
- 1.8 优势
- 1.9 劣势
2 小总结（which one）

1 AOF（append only file）

1.1 AOF是什么

以日志的形式来记录每个写操作（增量保存），将redis 执行过的所有写指令记录下来（读操作不记录），只允许追加文件但不可以改写文件，reids 启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

1.2 AOF 持久化流程

客户端的请求写命令会被append追加到aof 缓冲区内；

aof 缓冲区根据aof持久化策略（always，everysec，no）将操作sync同步到磁盘的aof文件中；

aof文件大小超过重写策略或手动重写时，会对aof文件rewrite重写，压缩aof文件容量

redis 服务重启时，会重新load加载aof文件中的写操作达到数据恢复的目的；

1.3 AOF 默认不开启

可以在redis.conf中配置文件名称，默认为appendonly.aof
AOF文件的保存路径，同RDB路径一致

appendonly no# The name of the append only file (default: "appendonly.aof")appendfilename "appendonly.aof"

1.4 AOF 和RDB同时开启听谁的

AOF 和RDB同时开启，redis 会默认取AOF的数据（数据不会丢失）

1.5 AOF启动修复恢复

aof的备份机制和性能虽然和rdb不同，但是备份和恢复的操作同rdb一样，都是拷贝备份文件，需要恢复时再拷贝到redis工作目录，启动系统即加载

正常恢复
修改默认的appendonly no 改为yes
将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）

恢复
重启reids然后重新加载

异常恢复
修改默认的appendonly no 改为yes
如果遇到aof文件损坏，通过/usr/loacal/bin/redis-check-aof --fix appendonly.aof 进行恢复
备份被写坏的aof文件
恢复：重启redis，然后重新加载

# redis-check-aof --fix appendonly.aof

1.6 AOF 同步频率

始终同步，每次redis的写入都会立刻记入日志，性能较差但数据完整性较好

# appendfsync always

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失

appendfsync everysec

redis不主动同步，把同步时机交给操作系统

# appendfsync no

1.7 Rewrite压缩

aof采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

重写原理
aof文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），reids4.0版本后的重写，是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换原来的流水账操作

no-appendfsync-on-rewrite no

触发机制
redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是有一定的负担，因此设定redis要满足一定条件才会进行重写

auto-aof-rewrite-percentage 设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的两倍时触发）

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

重写流程
bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

主进程fork出子进程执行重写操作，保证主进程不会阻塞

子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf
缓冲区和aof_rewrite_buf重写缓冲区保证原aof文件完整以及新aof文件生成期间的新的数据修改动作不会丢失

子进程写完新的aof文件后，向主进程发信号，父进程更新统计信息，
主进程把aof_rewrite_buf中的数据写入到新的aof文件

使用新的aof文件覆盖旧的aof文件，完成aof重写

1.8 优势

备份机制更稳健，丢失数据概率更低

可读的日志文本，通过操作aof文件，可以处理误操作

1.9 劣势

比起RDB占用更多的磁盘空间
恢复备份速度慢
每次读写同步的话，有一定的性能压力
存在个别bug，造成不会恢复

2 小总结（which one）

官方推荐两个都启用
如果对数据不敏感，可以单独选用RDB
不建议单独用aof，因为可能会出现bug
如果只是做纯内存缓存，可以都不用