---

大家好，我是卷心菜。本篇主要讲解Redis持久化的AOF方式，如果您看完文章有所收获，可以三连支持博主哦~，嘻嘻。

---

文章目录

• 一、前言
• 二、AOF概念
• 三、AOF配置
• 四、AOF三种策略
• 五、AOF重写
• • 1、触发机制
  • • 1.1、手动触发
    • 1.2、自动触发
  • 2、执行流程
• 六、AOF优缺点
• 七、RDB与AOF的区别

一、前言

• 上一篇文章已经讲解了Redis实现持久化的RDB方式，抛开优点来说，RDB的存储数据量较大，效率较低、大数据量下的IO性能较低、内存产生额外消耗、宕机带来的数据丢失风险等等，那么如何解决这种问题呢？
• 思路：不写全数据，仅记录部分数据、降低区分数据是否改变的难度，改记录数据为记录操作过程、对所有操作均进行记录，排除丢失数据的风险

二、AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

三、AOF配置

• appendonly yes|no：是否开启AOF持久化功能，默认为不开启状态

• appendfsync always|everysec|no：AOF写数据策略

• appendfilename filename：AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

• dir：AOF持久化文件保存路径，与RDB持久化文件保持一致即可

四、AOF三种策略

• always(每次）
  每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
• everysec（每秒）
  每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置
  在系统突然宕机的情况下丢失1秒内的数据
• no（系统控制）
  由操作系统控制每次同步到AOF文件的周期，整体过程不可控

命令

always

everysec

no

优点

不丢失数据

每秒一次fsync丢1秒数据

不用管

缺点

IO开销较大

丢1秒数据

比可控

五、AOF重写

• 为什么要重写：随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。
• 如何重写：AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

1、触发机制

1.1、手动触发

直接调用bgrewriteaof指令

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
1
2

1.2、自动触发

根据redis.conf配置文件中的auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size
表示运行AOF重写时文件最小体积，默认为64MB
auto-aof-rewrite-percentage
代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值
1
2
3
4

2、执行流程

六、AOF优缺点

• 优点：
  AOF可以更好的保护数据不丢失
  AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
  AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

• 缺点：
  AOF方式生成的日志文件太大，需要不断AOF重写，进行瘦身，即使经过AOF重写瘦身，由于文件是文本文件，文件体积还是较大（相比于RDB的二进制文件）
  AOF重演命令式的恢复数据，速度显然比RDB要慢。

七、RDB与AOF的区别

持久化方式

RDB

AOF

占用存储空间

小

大

存储速度

慢

快

恢复速度

快

慢

数据安全性

会丢失数据

依据策略决定

资源消耗

高

低

启动优先级

低

高

---

感谢阅读，一起进步，嘻嘻~