注:这里只说AOF工作原理,AOF其他功能请查阅官方文档
AOF(仅追加文件): AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作,重建原始数据集。命令的记录格式与 Redis 协议本身相同。
官方原话: AOF优势 使用 AOF Redis 更加持久:您可以拥有不同的 fsync 策略:完全没有 fsync,每秒 fsync 一次,每次查询时 fsync。使用每秒 fsync 的默认策略,写入性能仍然很高。fsync 是使用后台线程执行的,当没有 fsync 正在进行时,主线程将努力执行写入,因此您只能丢失一秒钟的写入。
AOF 日志是仅追加日志,因此在断电时不会有寻道或损坏问题。即使由于某种原因(磁盘已满或其他原因)日志以半写命令结束,redis-check-aof 工具也可以轻松修复它。
Redis 能够在 AOF 变得太大时在后台自动重写它。重写是完全安全的,因为当 Redis 继续追加到旧文件时,会使用创建当前数据集所需的最少操作集生成一个全新的文件,一旦第二个文件准备就绪,Redis 就会切换两者并开始追加到新文件。
AOF 以易于理解和解析的格式包含所有操作一个接一个的日志。您甚至可以轻松导出 AOF 文件。例如,即使您使用 `FLUSHALL` 命令意外刷新了所有内容,只要在此期间没有重写日志,您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存数据集。
AOF 文件通常大于同一数据集的等效 RDB 文件。
AOF 可能比 RDB 慢,具体取决于确切的 fsync 策略。一般来说,将 fsync 设置为每秒性能仍然非常高,并且在禁用 fsync 的情况下,即使在高负载下,它应该与 RDB一样快。尽管如此,RDB仍然能够提供更多关于最大延迟的保证,即使在巨大的写入负载的情况下也是如此。
而且在Redis Version < 7.0 如果在重写期间对数据库进行了写入,则 AOF 可能会使用大量内存(这些写入缓存在内存中并在最后写入新的 AOF)。重写期间到达的所有写入命令将写入磁盘两次。Redis 可以在重写结束时冻结写入并将这些写入命令同步到新的 AOF 文件。(注:这个问题在Redis > 7.0得到了解决)
1-> 开启一个Fork子进程
2-> 子进程创建了一个新的临时AOF文件,读取内存这个中数据快照,写入重构数据库状态指令
3->父进程将所有新增更改命令写入到内存缓冲区中(同时,它将新增更改命令写入旧的AOF文件中,仅追加文件)
4-> 子进程写入完毕,通知父进程进行下一步处理
5-> 父进程收到子进程信号,将缓存中的命令追加到临时AOF文件
6-> 父进程修改临时AOF文件名称为正式AOF文件
7-> 父进程将后续新的更改命令追加到正式AOF文件

1-> 父线程开启Frok子进程
2-> 子进程执行重写逻辑并生成新的基本AOF文件
3-> 当子进程重写时,父进程会打开一个新的增量 AOF 文件以继续写入
4-> 当子进程写入完毕后,通知父进程
5-> 父进程收到信号,读取增量AOF和基本AOF文件生成文件清单
6-> 父进程读取文件清单,重写基础AOF文件,并对其进行原子交换,确保重写成功
7-> 父进程清理旧的基本文件和任何未使用的增量文件

在redis.conf启动AOF之后,可以在Redis的默认工作目录看到一个appenddir目录,其中存放了增量AOF、基础AOF、文件清单。
基础AOF文件中存放了每次增量AOF和临时AOF生成文件清单后重写的AOF数据
文件清单中存储了base.rdb和incr.aof的名字

在Redis7.0之前,Redis启动时会去优先读appendonly.aof文件(在AOF和RDB同时存在的时候)来重构数据库状态
在Redis7.0之后,Redis启动时会去优先读appendonly.aof.1.base.rdb文件(在AOF和RDB同时存在的时候)来重构数据库状态

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。