介绍

自Redis 7.0.0以来，Redis使用多部分AOF机制。也就是说，原始的单个AOF文件被拆分为基本文件（最多一个）和增量文件（可能有多个）。基本文件表示重写AOF时存在的数据的初始（RDB或AOF格式）快照。增量文件包含自上次创建基本AOF文件以来的增量更改。所有这些文件都放在一个单独的目录中，并由清单文件跟踪。

AOF持久化流程

1.客服端作为命令的来源，会有多个客服端以及源源不断的请求命令
2.这些redis命令到达redis sever以后并不是直接写入AOF文件，会将这些命令放到AOF缓冲区。缓存区存
在的目的就是 缓存区达到一定的量时，将写入磁盘。避免磁盘的IO操作
3.AOF缓冲区会根据AOF缓冲区 某些缓冲区策略写入磁盘上的AOF文件。
4.随着AOF 文件内容的增加，为避免文件膨胀，会根据规则将命令合并，从而压缩AOF文件。
5.当redis 重启时，将AOF文件内的命令由头到尾执行一遍。

AOF缓存区三种写回策略

appendfsync every sec  默认每一秒
1.always
同步写回，每个写命令执行完立即同步的将日志写入AOF文件。
	优点：命令最多回丢失一条，但是磁盘IO次数特别多。
2.every sec。
  每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒以后再把缓存区的
  内容写回磁盘。
3.no
操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定
何时将缓冲区数据写回磁盘。

配置项

写回时机

优点

缺点

Aways

同步写回

可靠性高数据基本不丢失

每个命令执行完后，都要IO 落盘，影响性能

Everysec

每秒写回

性能适中

宕机时丢失一秒内数据

No

操作系统控制写回

性能好

宕机时丢失数据多

AOF 日志重写

  • 随着写入操作的执行，AOF变得越来越大。例如，如果您将计数器递增100次，您最终会在数据集中使用包含最终 值的单个键，但AOF中有100个条目。重建当前状态不需要其中99个条目。
  • 重写是完全安全的。当Redis继续附加到旧文件时，会产生一个全新的文件，只需最少的操作即可创建当前数据集，一旦第二个文件准备就绪，Redis就会切换这两个文件，并开始附加到新文件。
  • 自Redis 7.0.0以来，当计划重写AOF时，Redis父进程会打开一个新的增量AOF文件以继续写入。子进程执行重写逻辑并生成一个新的基本AOF。Redis将使用临时清单文件来跟踪新生成的基本文件和增量文件。当他们准备就绪时，Redis将执行原子替换操作，以使此临时清单文件生效。为了避免在AOF重写重复失败和重试的情况下创建许多增量文件的问题，Redis引入了AOF重写限制机制，以确保失败的AOF重写以越来越慢的速度重试。

工作原理

  • 日志重写使用与已用于快照的相同写时复制技巧。这就是它的工作原理：
  • Redis >= 7.0
  1. Redis fork一个子进程，所以现在我们有一个孩子和一个家长流程。
  2. 孩子开始在临时文件中写入新的基础AOF（base.aof）。
  3. 父级打开一个新的增量AOF文件(incr.aof)以继续写入更新。如果重写失败，旧的基础和增量文件（如果有 的话）加上这个新打开的增量文件代表完整的更新数据集，所以我们是安全的。
  4. 当子文件重写完成基本文件时，父文件会收到一个信号，并使用新打开的增量文件和子文件生成的基本文件来构建临时清单，并保留它。
  • redis<=7.0
  1. Redis fork一个子进程，所以现在我们有一个孩子和一个家长流程。
  2. 孩子开始在临时文件中写入新的AOF。
  3. 父级在内存缓冲区中积累所有新更改（但同时它将新更改写入旧的仅附加文件中，因此如果重写失败，我们是安全的）记住这里写入两次。
  4. 当子程序完成重写文件时，父级会收到一个信号，并在子程序生成的文件末尾附加内存缓冲区。

AOF 重写时机

由于AOF持久化是redis不断的将写命令记录到AOF文件中，睡着时间到推移，AOF文件回越来越大
文件越大，恢复数据占用的内存就越大，恢复的时间就越长。
为了解决上述问题。redis新增了重写机制，当AOF文件的大小超过设定的峰值时，Redis就会自动
压缩AOF文件。也就是多条命令合并为一条命令。也可以手动设置

  • 自动配置 redis.conf

auto-aof-write-percentage 100（上次写后，aof容量是否超过了一倍）
auto-aof-write-min-size 64mb (重写时 AOF容量是否>64mb)
注意上述连个同时满足才会触发，同时会记录本次文件的大小，为下次触发做准备。

  • 手动执行

客户端向服务器发送指令 bgrewriteaof

AOF 与RDB的相互影响

  • Redis >= 2.4确保避免在RDB快照操作已经在进行时触发AOF重写，或在AOF重写进行时进行BGSAVE。这可以防止两个Redis后台进程同时执行重盘I/O。
  • 当快照正在进行中，并且用户明确要求使用BGREWRITEAOF进行日志重写操作时，服务器将回复确定状态代码，告知用户操作已计划，一旦快照完成，重写将开始。
  • 如果启用了AOF和RDB持久性，并且Redis重新启动，AOF文件将用于重建原始数据集，因为它保证是最完整的。
  • 一般推荐RDB与AOF 混合使用
  1. 先使用RDB进行快照存储（可以理解了，base,aof既可以aof格式或rdb格式），然后使用incr.AOF记录搜有的写操作.
  2. 当重写策略满足或手动触发的时候，将最新的记录存储为新的RDB记录，其实就是base.aof
  3. 当启动服务的时候就会从base.aof 和incr.aof两部分来恢复数据，即保证了数据的完整性有提高了恢复性能。

RDB 切换AOF

  • 备份您最新的dump.rdb文件。
  • 将此备份转移到安全的地方。
  • 发出以下两个命令：
  • redis-cli config set appendonly yes
  • redis-cli config set save “”

正确的AOF文件备份

如果您在仅启用AOF持久性的情况下运行Redis实例，您仍然可以执行备份。自Redis 7.0.0以来，AOF文件被拆分为多个文件，这些文件驻留在由appenddirname配置确定的单个目录中。在正常运行期间，您只需复制/tar此目录中的文件即可实现备份。但是，如果在重写期间完成此操作，您最终可能会获得无效的备份。要解决这个问题，您必须在备份期间禁用AOF重写：

  1. 关闭自动重写
    CONFIG SET auto-aof-rewrite-percentage 0
    在此期间，请确保您不要手动开始重写（使用BGREWRITEAOF）。
  2. 检查当前没有正在进行的重写，使用
    INFO persistence
    验证aof_rewrite_in_progress为0。如果是1，那么您需要等待重写完成。
  3. 现在，您可以安全地复制appenddirname目录中的文件。
  4. 完成后重新启用重写：
    CONFIG SET auto-aof-rewrite-percentage
  • 注意
    RDB 更适合用来数据库的备份

优势

  1. 使用AOF 数据更安全，有如果使用 everysec,写入性能 很高，只会丢失1se的数据
  2. AOF日志是一个仅附加日志,即使日志以写了一半命令，也可以redis-check-aof工具修复
  3. 当AOF变得很大时，redis能够在后台自动重写AOF.重写完全是安全的。
  4. AOF 以易于理解和解析的格式包含所有操作一个接一个的日志。您甚至可以轻松导出 AOF 文件。例如，即使您使用 FLUSHALL 命令意外刷新了所有内容，只要在此期间没有重写日志，您仍然可以通过停止服务器、删除最新命令（FLUSHALL)并重新启动 Redis 来保存数据集。
    综合以上：更好的保证数据不丢失，性能高，可做紧急恢复。

劣势

  • AOF的文件一般同一数据集的RDB文件
  • AOF可能会比RDB慢，具体取决使用那种策略，默认的fsync everysec已经非常高了。如果fsync no那么效率和RDB 基本一样。
  • 数据恢复比RDB慢，因为要重新执行写入命令。RDB文件默认采用压缩的方式持久化，AOF存储的是执行指令，所以RDB在数据恢复的时候性能比AOF要好。

其他

  • 纯缓存模式，极致的追求性能
    禁用RDB save""
    但是我们仍然可以用命令 save,bgsave 生成rdb文件
    禁用AOF appendonly no
    但是我们仍然可以使用命令 bgrewriteaof生成aof文件