Redis 7.x 系列【16】持久化机制之 AOF

有道无术，术尚可求，有术无道，止于术。

本系列Redis 版本 7.2.5

源码地址：https://gitee.com/pearl-organization/study-redis-demo

文章目录

- 1. 概述
- 2. 执行原理
- - 2.1 Redis 6.x
  - - 2.1.1 直接写
    - 2.1.2 重写
  - 2.2 Redis 7.x
  - - 2.2.1 Redis 6 AOF 中的
    - 2.2.
- 2. 配置项
- - 2.1 appendonly
  - 2.2 appendfilename
  - 2.3 appenddirname
  - 2.4 appendfsync
  - 2.5 no-appendfsync-on-rewrite
  - 2.6 auto-aof-rewrite-percentage、auto-aof-rewrite-min-size
  - 2.7 aof-load-truncated
  - 2.8 aof-use-rdb-preamble
  - 2.9 aof-timestamp-enabled

1. 概述

默认情况下，Redis 使用RDB持久化，但如果进程出现问题或电源中断，可能会导致几分钟的写入数据丢失（具体取决于配置的保存点）。

Append Only File（AOF）是另一种持久化模式，它提供了更好的持久性保证。AOF 以日志的形式来记录每个写操作，Redis重启时通过读取和执行AOF文件中的命令来重建数据集。

2. 执行原理

2.1 Redis 6.x

Redis 6 及之前的版本中，生成的 AOF 只有一个，整个执行流程如下：
在这里插入图片描述

2.1.1 直接写

Redis 在执行写操作时，并不是将指令直接写入到文件中，而是先写入到缓冲区（aof_buf），然后根据相应的策略同步（ fsync ）到磁盘中，支持以下三种不同的模式（后面配置有详细介绍）：

no：操作系统自行决定
always：每次写入都会立即被刷新到磁盘
everysec：每秒只进行一次 fsync 调用

写入的 AOF 文件如下所示：

在这里插入图片描述
当 Redis 宕机重启时，可以通过读取和执行 AOF 文件中的命令来重建数据集。但是每一次写指令都会存入到 AOF 文件，可能会导致文件变得非常大，文件太大时，无论是写入还是加载都会变得特别慢。

2.1.2 重写

为了避免 AOF 文件多大问题，控制文件大小并优化性能，Redis 支持运行时触发 AOF 文件重写（rewrite），用以压缩 AOF 文件的大小。

重写机制可以通过 BGREWRITEAOF 命令手动触发，也可以自动触发，配置参数如下：

# 当 AOF 文件大小超过上次重写后 AOF 文件大小的百分比时自动触发，默认值为 100 
auto-aof-rewrite-percentage 100
# 当 AOF 文件大小超过指定值时自动触发，默认值为 64 MB
auto-aof-rewrite-min-size 64mb

当触发重写机制后， Redis 主进程会阻塞等待（微秒级）并执行 fork 创建子进程，创建完成后，会继续接收新的请求命令，并将 fork 后的写操作写入到缓冲区并刷盘。此外新操作还会写入到重写缓冲区（aof_rewrite_buf）中，以便重写完成后合并到新文件中，确保和内存数据的一致性。

重写子进程会根据当前时刻 Redis 的数据快照，将每个键值对转换为相应的写入命令，并写入到一个临时文件中（ temp-rewriteaof-bg-pid.aof）。当上述操作完成后，主进程会将重写缓冲区中的数据发送给子进程，由子进程将数据追加到临时AOF文件中。

子进程重写完成后，会发送消息给主进程，主进程负责将重写缓冲区（可能存在未发送的数据）中剩余数据继续追加到临时AOF文件，并执行原子性的重命名操作，覆盖原先的AOF文件，至此整个重写流程结束。

在子进程重写的后期阶段，主进程会将aof_rewrite_buf中累积的数据使用pipe发送给子进程，子进程会将这些数据追加到临时AOF文件中（详细原理可参考[1]）。

当主进程承接了较大的写入流量时，aof_rewrite_buf中可能会堆积非常多的数据，导致在重写期间子进程无法将aof_rewrite_buf中的数据全部消费完。此时，aof_rewrite_buf剩余的数据将在重写结束时由主进程进行处理。

当子进程完成重写操作并退出后，主进程会在backgroundRewriteDoneHandler 中处理后续的事情。首先，将重写期间aof_rewrite_buf中未消费完的数据追加到临时AOF文件中。其次，当一切准备就绪时，Redis会使用rename 操作将临时AOF文件原子的重命名为server.aof_filename，此时原来的AOF文件会被覆盖。至此，整个AOFRW流程结束。

子进程完成重写

 5.1 新⽂件写⼊后，5.2 父进程将AOF重写缓存区内临时保存的新命令追加到新AOF文件中5.3 用新的AOF文件替换旧的的AOF文

AOF 重写机制是通过 fork 出一个子进程来完成的，子进程会扫描 Redis 的数据库，并，然后。

在子进程进行 AOF 重写的过程中，主进程还会继续接收和处理客户端的请求，如果有新的写操作发生，主进程会将这些写操作追加到一个缓冲区中，并通过管道通知子进程。

子进程在完成 AOF 重写后，会将缓冲区中的写操作也追加到临时文件中，然后向主进程发送信号，通知主进程可以切换到新的 AOF 文件了。

主进程在收到子进程的信号后，会将缓冲区中的写操作再次追加到临时文件中（以防止在此期间有新的写操作发生），然后用临时文件替换旧的 AOF 文件，并关闭旧的 AOF 文件。

全部重写到临时 AOF 文件中，名称为，

全部。

AOF重写是Redis用来优化AOF文件大小和性能的过程。在AOF重写过程中，Redis会执行以下步骤：

启动AOF重写进程：Redis会启动一个后台进程来执行AOF重写操作。

生成临时文件：在AOF重写过程中，Redis会创建一个临时的AOF文件，类似于"temp-rewriteaof-bg-pid.aof"。这个临时文件会用来存储重写期间生成的新的AOF日志。

重写AOF文件：Redis会遍历当前数据集，将其中的命令操作重写到临时AOF文件中。重写的目标是优化AOF文件的结构和内容，以减少文件大小和改善读写性能。

完成重写并替换旧文件：一旦AOF重写完成，Redis会将新生成的AOF文件重命名为原始的AOF文件名（例如默认的redis.aof），以及删除旧的AOF文件。

因此，"temp-rewriteaof-bg-pid.aof"文件是Redis AOF重写过程中生成的临时文件，用于在重写期间暂存新生成的AOF数据。

该操作会将执行fork那一刻

由于重写操作为子进程后台执行，主进程在AOF重写期间依然可以正常响应用户命令。因此，为了让子进程最终也能获取重写期间主进程产生的增量变化，主进程除了会将执行的写命令写入aof_buf，还会写一份到aof_rewrite_buf中进行缓存。在子进程重写的后期阶段，主进程会将aof_rewrite_buf中累积的数据使用pipe发送给子进程，子进程会将这些数据追加到临时AOF文件中（详细原理可参考[1]）。

首先执行AOF重写请求，如果当前进程正在执⾏ AOF 重写，请求不执⾏。如果当前进程

正在执⾏ bgsave 操作，重写命令延迟到 bgsave 完成之后再执⾏
父（很快单位以微秒记）执行，创建出

重写

 3.1 当父进程fork之后，继续响应其他命令。所有修改操作写⼊ AOF 缓冲区并根据               appendfsync策略同步到硬盘，保证旧 AOF ⽂件机制正确3.2 ⼦进程只有 fork 之前的所有内存信息，⽗进程中需要将 fork 之后这段时间的修改操作写⼊ AOF 重写缓冲区中

⼦进程根据内存快照，将命令合并到新的 AOF ⽂件中（这里就是压缩后的文件）

————————————————

                        版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/x2656271356/article/details/134446175

为了控制文件大小并优化性能，Redis 提供了 AOF 重写机制。AOF 重写不改变实际数据，而是创建一个新的 AOF 文件，其中包含当前数据集的最小命令集合，可以完整地重构数据集。
AOF 重写是通过读取现有数据集并使用简化的命令来重建新的 AOF 文件来实现的，新文件可以替代旧文件，从而达到压缩和优化的目的。
1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

由用户手动触发，也可以由系统自动触发。
用户手动触发 AOF 重写机制可以通过执行 BGREWRITEAOF 命令来实现。
系统自动触发 AOF 重写机制可以通过配置文件中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数来控制。
auto-aof-rewrite-percentage 参数表示触发 AOF 重写机制，
auto-aof-rewrite-min-size 参数表示当才可能 AOF 重写机制，。

AOF 重写机制的触发方式
AOF 重写机制可以由用户手动触发，也可以由系统自动触发。
用户手动触发 AOF 重写机制可以通过执行 BGREWRITEAOF 命令来实现。
系统自动触发 AOF 重写机制可以通过配置文件中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数来控制。
auto-aof-rewrite-percentage 参数表示当当前 AOF 文件大小超过上次重写后 AOF 文件大小的百分比时，触发 AOF 重写机制，默认值为 100 。
auto-aof-rewrite-min-size 参数表示当当前 AOF 文件大小超过指定值时，才可能触发 AOF 重写机制，默认值为 64 MB 。
系统自动触发 AOF 重写机制还需要满足以下条件：
当前没有正在执行 BGSAVE 或 BGREWRITEAOF 的子进程
当前没有正在执行 SAVE 的主进程
当前没有正在进行集群切换或故障转移
AOF 重写机制可能遇到的问题
AOF 重写机制可能会遇到内存不足或者内存碎片化的问题。
内存不足是指当 fork 出子进程时，操作系统会为子进程分配和主进程相同大小的内存空间，如果主进程占用的内存过大，可能导致内存不足而 fork 失败。
内存碎片化是指当 fork 出子进程时，操作系统会使用写时复制（copy-on-write）的技术，只有当主进程修改了内存页时，才会为子进程复制一个新的内存页。但是如果主进程使用了大页（huge page）的特性，那么每次复制的内存页也会很大，可能导致内存碎片化而 fork 失败。
解决内存不足或者内存碎片化的问题的方法有以下几种：
增加物理内存或者虚拟内存
优化 Redis 的数据结构和编码，减少内存占用
关闭大页（huge page）的特性，避免复制过大的内存页

优点：

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

缺点：

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

2.2 Redis 7.x

2.2.1 Redis 6 AOF 中的

Redis 6 及之前的版本中的 AOF 机制，

1 内存开销
由图1可以看到，在AOFRW期间，主进程会将fork之后的数据变化写进aof_rewrite_buf中，aof_rewrite_buf和aof_buf中的内容绝大部分都是重复的，因此这将带来额外的内存冗余开销。

在Redis INFO中的aof_rewrite_buffer_length字段可以看到当前时刻aof_rewrite_buf占用的内存大小。如下面显示的，在高写入流量下aof_rewrite_buffer_length几乎和aof_buffer_length占用了同样大的内存空间，几乎浪费了一倍的内存。

aof_pending_rewrite:0
aof_buffer_length:35500
aof_rewrite_buffer_length:34000
aof_pending_bio_fsync:0
当aof_rewrite_buf占用的内存大小超过一定阈值时，我们将在Redis日志中看到如下信息。可以看到，aof_rewrite_buf占用了100MB的内存空间且主进程和子进程之间传输了2135MB的数据（子进程在通过pipe读取这些数据时也会有内部读buffer的内存开销）。

对于内存型数据库Redis而言，这是一笔不小的开销。

3351:M 25 Jan 2022 09:55:39.655 * Background append only file rewriting started by pid 6817
3351:M 25 Jan 2022 09:57:51.864 * AOF rewrite child asks to stop sending diffs.
6817:C 25 Jan 2022 09:57:51.864 * Parent agreed to stop sending diffs. Finalizing AOF…
6817:C 25 Jan 2022 09:57:51.864 * Concatenating 2135.60 MB of AOF diff received from parent.
3351:M 25 Jan 2022 09:57:56.545 * Background AOF buffer size: 100 MB
AOFRW带来的内存开销有可能导致Redis内存突然达到maxmemory限制，从而影响正常命令的写入，甚至会触发操作系统限制被OOM Killer杀死，导致Redis不可服务。

2 CPU开销
CPU的开销主要有三个地方，分别解释如下：

1、在AOFRW期间，主进程需要花费CPU时间向aof_rewrite_buf写数据，并使用eventloop事件循环向子进程发送aof_rewrite_buf中的数据：

/* Append data to the AOF rewrite buffer, allocating new blocks if needed. */
void aofRewriteBufferAppend(unsigned char *s, unsigned long len) {
// 此处省略其他细节…

/* Install a file event to send data to the rewrite child if there is* not one already. */
if (!server.aof_stop_sending_diff &&aeGetFileEvents(server.el,server.aof_pipe_write_data_to_child) == 0)
{aeCreateFileEvent(server.el, server.aof_pipe_write_data_to_child,AE_WRITABLE, aofChildWriteDiffData, NULL);
} // 此处省略其他细节...

}
2、在子进程执行重写操作的后期，会循环读取pipe中主进程发送来的增量数据，然后追加写入到临时AOF文件：

int rewriteAppendOnlyFile(char *filename) {
// 此处省略其他细节…

/* Read again a few times to get more data from the parent.* We can't read forever (the server may receive data from clients* faster than it is able to send data to the child), so we try to read* some more data in a loop as soon as there is a good chance more data* will come. If it looks like we are wasting time, we abort (this* happens after 20 ms without new data). */
int nodata = 0;
mstime_t start = mstime();
while(mstime()-start < 1000 && nodata < 20) {if (aeWait(server.aof_pipe_read_data_from_parent, AE_READABLE, 1) <= 0){nodata++;continue;}nodata = 0; /* Start counting from zero, we stop on N *contiguous*timeouts. */aofReadDiffFromParent();
}// 此处省略其他细节...

}
3、在子进程完成重写操作后，主进程会在backgroundRewriteDoneHandler 中进行收尾工作。其中一个任务就是将在重写期间aof_rewrite_buf中没有消费完成的数据写入临时AOF文件。如果aof_rewrite_buf中遗留的数据很多，这里也将消耗CPU时间。

void backgroundRewriteDoneHandler(int exitcode, int bysignal) {
// 此处省略其他细节…

/* Flush the differences accumulated by the parent to the rewritten AOF. */
if (aofRewriteBufferWrite(newfd) == -1) {serverLog(LL_WARNING,"Error trying to flush the parent diff to the rewritten AOF: %s", strerror(errno));close(newfd);goto cleanup;}// 此处省略其他细节...

}
AOFRW带来的CPU开销可能会造成Redis在执行命令时出现RT上的抖动，甚至造成客户端超时的问题。

3 磁盘IO开销
如前文所述，在AOFRW期间，主进程除了会将执行过的写命令写到aof_buf之外，还会写一份到aof_rewrite_buf中。aof_buf中的数据最终会被写入到当前使用的旧AOF文件中，产生磁盘IO。同时，aof_rewrite_buf中的数据也会被写入重写生成的新AOF文件中，产生磁盘IO。因此，同一份数据会产生两次磁盘IO。

4 代码复杂度
Redis使用下面所示的六个pipe进行主进程和子进程之间的数据传输和控制交互，这使得整个AOFRW逻辑变得更为复杂和难以理解。

/* AOF pipes used to communicate between parent and child during rewrite. */
int aof_pipe_write_data_to_child;
int aof_pipe_read_data_from_parent;
int aof_pipe_write_ack_to_parent;
int aof_pipe_read_ack_from_child;
int aof_pipe_write_ack_to_child;
int aof_pipe_read_ack_from_parent;

2.2.

2. 配置项

redis.conf 中 AOF 相关的配置如下：

############################## APPEND ONLY MODE ################################ By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.appendonly no# The base name of the append only file.
#
# Redis 7 and newer use a set of append-only files to persist the dataset
# and changes applied to it. There are two basic types of files in use:
#
# - Base files, which are a snapshot representing the complete state of the
#   dataset at the time the file was created. Base files can be either in
#   the form of RDB (binary serialized) or AOF (textual commands).
# - Incremental files, which contain additional commands that were applied
#   to the dataset following the previous file.
#
# In addition, manifest files are used to track the files and the order in
# which they were created and should be applied.
#
# Append-only file names are created by Redis following a specific pattern.
# The file name's prefix is based on the 'appendfilename' configuration
# parameter, followed by additional information about the sequence and type.
#
# For example, if appendfilename is set to appendonly.aof, the following file
# names could be derived:
#
# - appendonly.aof.1.base.rdb as a base file.
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
# - appendonly.aof.manifest as a manifest file.appendfilename "appendonly.aof"# For convenience, Redis stores all persistent append-only files in a dedicated
# directory. The name of the directory is determined by the appenddirname
# configuration parameter.appenddirname "appendonlydir"# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".# appendfsync always
appendfsync everysec
# appendfsync no# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync no". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.no-appendfsync-on-rewrite no# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
aof-load-truncated yes# Redis can create append-only base files in either RDB or AOF formats. Using
# the RDB format is always faster and more efficient, and disabling it is only
# supported for backward compatibility purposes.
aof-use-rdb-preamble yes# Redis supports recording timestamp annotations in the AOF to support restoring
# the data from a specific point-in-time. However, using this capability changes
# the AOF format in a way that may not be compatible with existing AOF parsers.
aof-timestamp-enabled no

2.1 appendonly

appendonly 用于控制是否启用AOF持久化。

appendonly no

被设置为 no（默认）时，Redis 不会使用 AOF 持久化机制。

2.2 appendfilename

appendfilename 用于配置 AOF 文件的基础名称。

appendfilename "appendonly.aof"

Redis 7 及更高版本使用一组仅追加文件进行AOF，文件主要有两种类型：

基础文件：是数据集在文件创建时完整状态的快照。基础文件可以是 RDB（二进制序列化）格式或 AOF（文本命令）格式。
增量文件：包含在上一个文件之后对数据集应用的其他命令。

此外，还使用清单文件来跟踪文件的创建顺序，以及它们应该被应用的顺序。

Redis 根据特定的模式创建AOF文件的名称。文件名的前缀基于appendfilename配置参数，后面跟着关于序列和类型的额外信息。

例如，如果 appendfilename被设置为appendonly.aof，那么可能会产生以下文件名：

appendonly.aof.1.base.rdb 作为基础文件。
appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof 作为增量文件。
appendonly.aof.manifest 作为清单文件。

2.3 appenddirname

appenddirname 配置AOF文件的存储目录。

appenddirname "appendonlydir"

2.4 appendfsync

appendfsync 用于配置AOF缓冲区将操作同步（sync）到磁盘的AOF文件中的策略。

# appendfsync always
appendfsync everysec
# appendfsync no

fsync() 是一个系统调用，它告诉操作系统将数据实际写入磁盘，而不是等待更多的数据进入输出缓冲区。不同的操作系统对 fsync() 的实现可能有所不同，一些系统会立即将数据写入磁盘，而另一些系统则会尽快尝试这样做。

Redis 支持三种不同的 fsync 模式：

no：不进行 fsync 调用，让操作系统自行决定何时将数据刷新到磁盘。这种方式速度最快，但可能存在数据丢失的风险。
always：每次写入 AOF 日志后都进行 fsync 调用。这是最慢但最安全的方式，因为每次写入都会立即被刷新到磁盘。
everysec：每秒只进行一次 fsync 调用。这是速度和数据安全性之间的一个折中方案。

默认值是 everysec，因为它通常是在速度和数据安全性之间最好的折中方案。你可以根据自己的需求调整这个设置。如果你能接受一些数据丢失的风险并且追求更好的性能，可以考虑使用 no 模式（但请注意，如果你能接受数据丢失，那么默认的基于快照的持久化模式可能更合适）。相反，如果你追求更高的数据安全性，即使这意味着性能会降低，可以使用 always 模式。

2.5 no-appendfsync-on-rewrite

no-appendfsync-on-rewrite 用于配置在BGSAVE或BGREWRITEAOF正在进行时，是否阻止主进程调用fsync()。

no-appendfsync-on-rewrite no

当AOF的fsync策略设置为always或everysec时，如果有一个后台保存进程（后台保存或AOF日志后台重写）正在对磁盘进行大量I/O操作，在某些Linux配置下，Redis可能会在fsync()调用上阻塞过长时间。目前这个问题没有修复方法，因为即使在不同的线程中执行fsync也会阻塞我们的同步write调用。

默认为no，不阻止主进程fsync()，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞，数据安全，但是性能降低。

当设置为yes时，在BGSAVE或BGREWRITEAOF正在进行时，主进程将不会执行fsync调用。这意味着在这段时间内，Redis的持久性与appendfsync no设置时相同，即数据不会立即同步到磁盘。在最坏的情况下，你可能会丢失最多30秒（使用默认Linux设置）的AOF日志数据。因此，如果你对延迟很敏感，可以将其设置为yes。但是，从持久性的角度来看，将其保持为no（默认值）是最安全的选择。

2.6 auto-aof-rewrite-percentage、auto-aof-rewrite-min-size

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis会fork出一条新进程来将文件重写，也是先写临时文件最后再重命名。

重写过程会创建一个新的 AOF 文件，其中只包含能够恢复当前数据状态所必需的最少命令，从而减小 AOF 文件的大小。

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

auto-aof-rewrite-percentage 用于设置一个百分比阈值，当 AOF 文件的大小相对于上一次重写后的大小增长了超过这个百分比时，Redis 就会自动触发 BGREWRITEAOF 命令来重写 AOF 文件。设置为 100（即 100%），那么当 AOF 文件的大小增长了一倍时触发重写。

auto-aof-rewrite-min-size 用于设置一个 AOF 文件重写所需的最小大小（以字节为单位）。只有当 AOF 文件的大小既超过了指定的百分比（ auto-aof-rewrite-percentage ），又超过了 auto-aof-rewrite-min-size 指定的最小大小时，Redis 才会触发 AOF 文件的重写。

2.7 aof-load-truncated

aof-load-truncated 用于配置如果 AOF 文件末尾被截断时的相关处理策略。

aof-load-truncated yes

在 Redis 启动过程中，当 AOF 数据被加载回内存时，可能会发现 AOF 文件末尾被截断。例如，在运行 Redis 的操作系统崩溃时，尤其是当 ext4 文件系统被挂载但没有使用 data=ordered 选项。然而，当 Redis 本身崩溃或中止但操作系统仍然正常工作时，这种情况不会发生。

当发生这种情况时，Redis 可以选择报错退出，或者加载尽可能多的数据（现在是默认行为）并启动，如果 AOF 文件末尾被截断。以下选项控制这种行为。

aof-load-truncated yes：会加载一个被截断的 AOF 文件，并且 Redis 服务器会开始记录日志以通知用户该事件。
aof-load-truncated no：服务器会报错并拒绝启动。当选项设置为 no 时，用户需要使用 “redis-check-aof” 工具修复 AOF 文件后再重新启动服务器。