Redis（二十六）-持久化操作之AOF

Posted 2022-07-29 码农飞哥

您好，我是码农飞哥，感谢您阅读本文，欢迎一键三连哦。
💪🏻 1. Python基础专栏，基础知识一网打尽，9.9元买不了吃亏，买不了上当。 Python从入门到精通
❤️ 2. Python爬虫专栏，系统性的学习爬虫的知识点。9.9元买不了吃亏，买不了上当 。python爬虫入门进阶
❤️ 3. Ceph实战，从原理到实战应有尽有。 Ceph实战
❤️ 4. Java高并发编程入门，打卡学习Java高并发。 Java高并发编程入门
😁 5. 社区逛一逛，周周有福利，周周有惊喜。码农飞哥社区，飞跃计划
全网同名【码农飞哥】欢迎关注，个人VX: wei158556

文章目录

• • 1. 简介
  • 2. AOF 持久化流程
  • 3. 开启AOF
  • 4. AOF启动/修复/恢复
  • • 4.1. 正常恢复
    • 4.2. 异常恢复
  • 5. AOF同步频率设置
  • 6. Rewrite 压缩
  • 7. AOF的优缺点
  • • 7.1 优点
    • 7.2 劣势
  • 8. 总结

1. 简介

上一篇文章我们介绍了 Redis（二十五）-持久化操作之RDB ，这篇文章接着来介绍另一种持久化的方式AOF。
AOF（Append Only File） : AOF 是以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初就会读取该文件重新构建数据，换言之，redis重启的话会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2. AOF 持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内
2. AOF缓冲区根据AOF持久化策略（always,everysec,no） 将操作sync 同步到磁盘的AOF文件中。
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量。
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
   

3. 开启AOF

AOF默认不开启，可以在redis.conf中配置文件名称，默认为appendonly.aof。AOF文件的保存路径，同RDB的路径一致。与AOF相关的配置有两个：

# appendonly 用于指定是否开启AOF，默认为no,我们可以改成yes
appendonly yes
# appendfilename 用于指定aof文件名,默认名称为：appendonly.aof，路径是启动redis-server的路径
appendfilename "appendonly.aof"

将配置 appendonly改成yes之后 ，重启redis服务器。可以在启动路径下看到 appendonly.aof 文件。

PS: AOF 和RDB同时开启，系统默认取AOF的数据（数据不会丢失）
AOF文件的格式;


可以在AOF文件中看到set命令的key以及value。

4. AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作和RBD一样，都是拷贝备份文件， 需要恢复时在拷贝到Redis工作目录下，启动Redis系统即加载。

4.1. 正常恢复

1. 修改默认的 appendonly no，改为yes。
2. 备份原来的 appendonly.aof 文件为 appendonly.aof.bak，删除最新的 appendonly.aof
3. 将appendonly.aof.bak 重命名回appendonly.aof。重启Redis服务器。
   

4.2. 异常恢复

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

5. AOF同步频率设置

1. appendfsync always
   始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性较好
2. appendfsync everysec
   每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
3. appendfsync no
   redis 不主动进行同步，把同步时机交给操作系统。

6. Rewrite 压缩

1. Rewrite压缩是什么？
   AOF 采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最下指令集，可以使用命令 bgrewriteaof
2. 重写原理，如何实现重写
   AOF文件持续增长而过长时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename）。redis 4.0 版本后的重写，是指把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

Redis 会记录上次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是会有一定的负担，因此设定Redis要满足一定的条件才会进行重写。

auto-aof-rewrite-percentage: 设置重写的基准值，文件达到100% 时开始重写（文件是原来重写后文件的2倍时触发）
auto-aof-rewrite-min-size: 设置重写的基准值，最小文件 64MB，达到这个值开始重写。
例如：文件达到70MB开始重写，降到50MB，下次就是100MB的时候开始重写。

7. AOF的优缺点

7.1 优点

1. 备份机制更稳健，丢失数据概率更低
2. 可读的日志文件，通过操作AOF文件，可以处理误操作。

7.2 劣势

1、比起RDB占用更多的磁盘空间
2. 恢复备份速度更慢
3. 每次读写都同步的话，有一定的性能压力。

8. 总结

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