企业官网建设流程全解析

一、引言：Redis 为什么需要持久化

Redis 最突出的特点之一就是把数据存放在内存中，因此它拥有极高的读写性能。但内存数据有一个无法回避的问题：进程一旦退出、服务器宕机或者机房断电，内存里的数据就会全部消失。对于单纯的缓存场景，数据丢失后还可以从数据库重新加载；但如果 Redis 承担了计数器、分布式锁、消息队列、排行榜、会话存储或某些关键业务数据的职责，数据丢失就可能造成严重的业务影响。

为了解决这个问题，Redis 提供了持久化机制，也就是把内存中的数据不断同步到磁盘，以便在重启后能够恢复。Redis 的持久化主要有两种方式：一种是快照式持久化 RDB，另一种是追加写日志式持久化 AOF。本文重点讨论 AOF，即 Append Only File，追加写文件。

AOF 的核心思想并不复杂：把 Redis 执行过的每一条写命令，按照 Redis 协议追加记录到日志文件中。当 Redis 重启时，只需要重新执行日志中的命令，就能重建内存中的数据。与 RDB 相比，AOF 通常具有更高的数据完整性、更小的丢失窗口，因此在对数据安全要求较高的业务中，AOF 是更常见的选择。

本文以 Redis 7.0 为基准，从 AOF 的基础原理讲起，逐步覆盖工作流程、全部核心配置、AOF 重写、加载与恢复、故障排查，以及 Redis 7.0 引入的多文件 AOF 和 manifest 清单等新特性，最后给出生产环境下的最佳实践。希望通过系统性的梳理，帮助读者真正理解 AOF，而不是停留在简单背配置的层面。

二、Redis 持久化全景：RDB 与 AOF 各自的位置

学习 AOF 之前，有必要先把它放到 Redis 持久化体系的整体框架中理解。只有弄清楚 RDB 和 AOF 分别解决什么问题，才能明白为什么 Redis 要同时提供两种机制，以及它们在数据安全、恢复速度、磁盘开销方面的不同取舍。

2.1 RDB 快照：定期保存某一时刻的数据镜像

RDB 的全称是 Redis DataBase，也就是 Redis 数据库快照。它的做法是：在某个时间点，把 Redis 内存中的全部数据序列化并写入一个二进制文件，默认文件名为dump.rdb。RDB 的触发方式包括配置项save自动触发，以及SAVE、BGSAVE命令手动触发。

RDB 最大的优点是文件紧凑、体积较小，因此恢复速度非常快，适合用于数据备份、异地容灾和快速启动恢复。它的主要缺点是快照之间存在数据丢失窗口。例如每 5 分钟生成一次快照，如果在第 4 分钟发生宕机，这 4 分钟内的写入就会全部丢失。可以说，RDB 是在性能和安全性之间做了一种偏向性能的取舍。

2.2 AOF 日志：记录每一条写命令

AOF 的思路与 RDB 完全不同。它不保存某个时刻的数据快照，而是持续追加记录 Redis 执行过的每一条写命令。可以把 AOF 理解为一个可回放的命令日志。由于 AOF 采用追加写，Redis 可以通过appendfsync控制刷盘时机。默认的everysec策略可以实现最多丢失约 1 秒数据，安全性明显高于一般配置下的 RDB。

AOF 的缺点是文件体积通常比 RDB 大，并且随着写入持续增长。如果命令频繁，AOF 还会产生持续的磁盘写入开销。为了解决文件膨胀问题，Redis 提供了 AOF 重写机制，核心命令是BGREWRITEAOF，后文会重点展开。

2.3 RDB 与 AOF 的对比

下面通过表格对比两者的核心差异：

生产环境中，Redis 允许同时开启 RDB 和 AOF。当两者同时开启时，Redis 重启后会优先加载 AOF 文件，因为 AOF 往往保存了更完整的数据。这一点非常重要：一旦开启 AOF，它就会成为数据恢复的主要依据。

三、AOF 的核心原理：一条命令如何落到磁盘

AOF 的思想虽然简单，但它的内部执行链路包含多个环节。理解这条链路，是进一步理解appendfsync、AOF 重写以及故障恢复的基础。

3.1 命令追加阶段

当客户端发送一条写命令，例如SET name zhangsan，Redis 会先在内存中执行这条命令并修改数据结构。执行成功后，Redis 会把这条命令按照 Redis 协议格式追加到内存中的 AOF 缓冲区。这个过程发生在主线程中，但只是把命令复制到内存缓冲区，还没有真正写入文件，因此速度很快，对主线程的影响很小。

需要注意的是，AOF 只记录写命令，读命令如GET、HGET、LRANGE不会被记录。同时，INCR、LPUSH、SADD、ZADD等命令会按实际执行的原样追加，而不是记录命令对内存造成的最终结果。因此，同一个键被反复修改时，AOF 中就会出现多条针对该键的命令，这正是 AOF 文件会不断膨胀的原因之一。

3.2 写入与刷盘阶段

命令进入 AOF 缓冲区后，Redis 需要通过操作系统write系统调用，把它写入操作系统维护的文件缓冲区。但这里有一个关键点：write通常只是把数据从用户态缓冲区复制到内核态页缓存，并不保证数据已经真正落到物理磁盘。要让数据实际持久化，还需要调用fsync。

Redis 通过appendfsync配置项决定fsync的调用时机。简单来说有三种选择：

• always：每次写入后立即执行fsync，数据最安全，性能最低。
• everysec：每秒执行一次fsync，在性能和安全之间取得平衡，是 Redis 的默认值。
• no：不主动调用fsync，把刷盘时机交给操作系统，性能最高，安全性最差。

三种策略的细节和适用场景将在第 4 章详细展开。

3.3 为什么 AOF 采用追加写而不是随机写

AOF 采用追加写，是因为顺序追加对磁盘非常友好。无论是机械硬盘还是 SSD，顺序写入的吞吐量都远高于随机写入。Redis 不需要像关系型数据库那样在文件中间修改记录，只需要不断向文件末尾追加内容。这种 I/O 模型能够最大程度降低寻道和写放大，从而在保障较高数据安全性的同时，尽量减少对性能的影响。

四、appendfsync 三种刷盘策略深度对比

在所有 AOF 配置中，appendfsync对性能和安全性影响最大。很多人对它的理解停留在「always 最安全、no 最快」的表面结论，但要真正选对策略，需要弄清不同策略背后的 I/O 行为。

4.1 always：每条命令都刷盘

当appendfsync设置为always时，Redis 每执行完一条写命令，都会立即调用fsync将数据刷入磁盘。这种策略下，即使发生断电或宕机，理论上最多丢失正在执行中的最后一条命令，数据完整性最好。

代价也很明显：fsync是相对昂贵的操作，会显著增加磁盘 I/O 压力。尤其在机械硬盘上，频繁fsync可能把写入吞吐量压低到每秒数百次级别，严重拖慢 Redis 性能。因此，always通常只用于写入量不大、但数据极其重要的场景，例如关键配置变更、订单状态流转等。

4.2 everysec：每秒刷盘一次

everysec是 Redis 的默认值，也是大多数生产环境推荐使用的策略。它的做法是：主线程把写命令追加到 AOF 缓冲区后，由后台机制每秒执行一次fsync。这样即使 Redis 突然宕机，最多也只会丢失最近 1 秒内的写命令。

虽然叫「每秒刷盘一次」，但 Redis 内部做了不少优化，并不是简单地在主线程里阻塞执行fsync，而是尽量把刷盘动作放到专门的线程或子进程中处理，减少对命令处理速度的影响。整体来看，everysec在数据安全性和写入性能之间取得了很好的平衡，是通用场景下的首选。

4.3 no：完全交给操作系统

当appendfsync设置为no时，Redis 只负责通过write把数据写入操作系统页缓存，不主动调用fsync。页缓存中的数据何时真正落到磁盘，完全由操作系统调度决定，通常会在若干秒之后执行。

这种策略的性能最高，因为 Redis 几乎不需要等待磁盘 I/O；但数据丢失窗口也最大，断电时可能丢失最近几秒甚至几十秒的数据。因此，no只适合对数据丢失完全不敏感、数据可以通过其他方式重建的场景，例如纯缓存加速，或者有权威数据源可以回源的业务。

三种策略总结

五、AOF 核心配置项全面解读

要正确使用 AOF，只了解appendfsync显然不够，还需要理解与 AOF 相关的一整套配置。下面按开启、写入、重写、加载恢复的顺序逐一解读。本文以 Redis 7.0 为基准，并特别标注 7.0 新增或调整的部分。

5.1 appendonly：是否开启 AOF

配置项appendonly控制是否开启 AOF 持久化，默认值是no，即不开启。要启用 AOF，需要将其设置为yes：

appendonly yes

开启后，Redis 就会开始记录所有写命令。注意，这里只是开启记录，具体刷盘策略仍然由appendfsync决定。

5.2 appendfilename：AOF 文件名

配置项appendfilename用于设置 AOF 文件的名称。在 Redis 7.0 之前，默认值是appendonly.aof。从 Redis 7.0 开始，由于引入多文件 AOF 机制，文件布局发生变化，appendfilename成为基础 AOF 文件命名的重要来源。

# Redis 7.0 之前常见配置 appendfilename "appendonly.aof"

5.3 appenddirname：AOF 文件目录

appenddirname是 Redis 7.0 新增的配置项。在 7.0 之前，AOF 相关文件通常直接放在 Redis 工作目录下，容易与其他文件混在一起。7.0 之后，Redis 会把所有 AOF 相关文件统一放入一个子目录，目录名由appenddirname控制，默认是appendonlydir。

appenddirname "appendonlydir"

也就是说，如果dir设置为/var/lib/redis，那么 7.0 的 AOF 文件会集中存放在/var/lib/redis/appendonlydir目录中。这个变化非常有利于文件管理、备份和清理。

5.4 appendfsync：刷盘策略

appendfsync已经在第 4 章详细分析，这里只补充配置写法：

appendfsync everysec

可选值只有always、everysec、no三种。

5.5 no-appendfsync-on-rewrite：重写期间是否暂停刷盘

配置项no-appendfsync-on-rewrite的默认值是no。它解决的是 AOF 重写期间，fsync与重写写入同时发生时可能产生的磁盘 I/O 争用问题。

• 取值为no时，即使正在重写，Redis 仍按appendfsync策略刷盘。数据最安全，但重写期间磁盘压力更大。
• 取值为yes时，重写期间 Redis 会暂停主 AOF 的fsync，把磁盘 I/O 资源让给重写过程，从而提升重写速度。代价是期间如果宕机，可能丢失更多数据。

no-appendfsync-on-rewrite no

对于数据安全性要求高的业务，建议保持默认值no；对于更看重性能、能接受极小丢失窗口的场景，可以考虑设置为yes。

5.6 auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size：自动重写触发条件

这两个配置项通常配合使用，决定什么时候自动触发 AOF 重写。

• auto-aof-rewrite-percentage：当前 AOF 文件大小相比上一次重写后的大小增长了多少百分比时触发重写，默认是 100，也就是增长一倍。
• auto-aof-rewrite-min-size：自动重写的最低文件大小门槛，默认是 64mb。只有 AOF 文件超过该值，并且满足增长百分比条件时，才会触发自动重写。

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

例如，上一次重写后 AOF 文件为 64MB，当文件增长到约 128MB 时，Redis 会自动触发新的重写。设置最低门槛，是为了避免文件很小时频繁触发重写。

5.7 aof-load-truncated：加载被截断的 AOF 文件

如果 Redis 在写入 AOF 时发生停机，文件末尾可能出现不完整的半截命令，这样的文件称为截断文件。配置项aof-load-truncated控制 Redis 启动加载 AOF 时遇到截断如何处理。

• 默认值yes：Redis 尽量加载完整部分，忽略末尾截断命令，并打印日志提示文件被截断。
• 设置为no：Redis 拒绝启动，要求管理员先通过redis-check-aof --fix修复文件。

aof-load-truncated yes

在数据很重要的场景下，更保守的做法是设置为no，让管理员先介入检查，避免 Redis 在文件已经损坏的情况下静默启动。

5.8 aof-use-rdb-preamble：是否使用 RDB 前导

配置项aof-use-rdb-preamble默认值是yes。它的含义是：执行 AOF 重写时，不再把全部数据转换成命令写入新 AOF 文件，而是在新文件开头先写入一小段 RDB 快照，后面再追加重写之后产生的增量 AOF 命令。

这种「RDB 前导加 AOF 增量」的混合格式可以显著提升重写后文件的加载速度，因为 RDB 快照的加载效率远高于逐条命令回放。该配置自 Redis 5.0 引入，目前已经是稳定且推荐保持开启的选项。

aof-use-rdb-preamble yes

5.9 aof-timestamp-enabled：是否记录 AOF 时间戳

配置项aof-timestamp-enabled是较新版本引入的选项，默认值是no。开启后，Redis 会在每条 AOF 命令前写入一个时间戳，使回放时可以知道命令的执行时间。

该特性主要面向数据审计、时间点恢复等高级场景。对普通用户来说，开启会略微增加文件体积，因此默认保持关闭即可。

aof-timestamp-enabled no

六、AOF Rewrite：为什么要重写，如何重写

随着 Redis 持续运行，AOF 文件会不断变长，尤其是高频更新的键会产生大量历史命令。例如一个计数器键被INCR一百万次，AOF 里就会记录一百万条INCR命令，但最终状态可能只需要一条SET命令即可表达。这样不仅浪费磁盘空间，还会拖慢 Redis 重启时的恢复速度。

为此，Redis 提供了 AOF 重写机制，命令是BGREWRITEAOF。重写的本质是：Redis 根据当前内存中的数据状态，重新生成一个体积更小的 AOF 文件，用来替换原来臃肿的 AOF 文件。

6.1 重写的触发方式

AOF 重写有两种触发方式：

• 自动触发：由auto-aof-rewrite-percentage和auto-aof-rewrite-min-size决定，满足条件时自动启动。
• 手动触发：通过BGREWRITEAOF命令手动执行。

redis-cli BGREWRITEAOF

手动触发常用于运维场景，例如预知业务高峰即将到来，提前做一次重写把 AOF 文件瘦身，减少高峰期的磁盘压力。

6.2 重写过程：为什么不会阻塞正常写入

AOF 重写不会阻塞主线程执行。Redis 利用写时复制思想实现后台重写，过程大致如下：

1. Redis 通过fork创建一个子进程。
2. 子进程根据 fork 时刻的内存数据快照，生成一个新的、紧凑的 AOF 文件。
3. 子进程写新文件期间，主线程继续处理新写命令，并把这些新命令同时追加到原 AOF 文件和一个重写缓冲区。
4. 子进程完成快照数据写入后，把重写缓冲区中累积的增量命令追加到新文件末尾，然后原子性地替换旧文件。

整个过程对客户端透明，主线程不会因为BGREWRITEAOF而阻塞。但需要注意，fork操作本身有一定开销，在内存巨大、写入频繁的场景下仍可能带来短暂性能抖动。

6.3 重写对文件格式的影响

如果开启了aof-use-rdb-preamble，重写后的新 AOF 文件不再是纯命令格式，而是以 RDB 快照开头，后面跟随增量命令。判断一个 AOF 文件是否包含 RDB 前导，可以看文件开头是否是REDIS这个魔数。理解这一点，有助于运维人员正确识别文件类型，避免把混合格式 AOF 误当成损坏文件。

七、AOF 的加载与数据恢复流程

AOF 存在的最终意义，是在 Redis 重启后恢复数据。因此，理解 AOF 文件的加载流程非常重要。尤其 Redis 7.0 将 AOF 拆分成多个文件后，加载逻辑变得更加复杂。

7.1 启动时选择加载哪个持久化文件

Redis 启动时，会先检查 AOF 是否开启。如果开启并且找到了 AOF 文件，就优先加载 AOF，忽略 RDB 文件；如果 AOF 未开启，才尝试加载 RDB。这个优先级是固定的，因为 AOF 通常保存了比 RDB 更新、更完整的数据。

因此，如果生产环境同时开启 RDB 和 AOF，却只备份了 RDB 文件，那么重启时实际恢复的仍然是 AOF 数据，备份的 RDB 不会被使用。这一点在制定备份策略时需要特别小心。

7.2 加载流程概览

Redis 加载 AOF 的过程可以概括为「读取文件、逐条回放命令」。

1. 打开并读取 AOF 文件。
2. 如果文件是 RDB 前导格式，先解析并加载开头的 RDB 快照；否则从第一条 AOF 命令开始。
3. 逐条解析并执行 AOF 中的写命令，重建内存数据。
4. 加载完成后检查文件是否被截断，如果截断则按aof-load-truncated配置处理。
5. 一切正常后，Redis 进入正常服务状态。

在 Redis 7.0 中，由于 AOF 被拆成多个文件，加载前的第一步是读取 manifest 清单文件，确定哪些文件属于完整 AOF 集合，然后按顺序依次加载。关于 manifest 文件，后文第 8 章会详细说明。

7.3 恢复速度的影响因素

AOF 恢复速度主要取决于文件大小和命令数量。文件越大，需要读取的数据越多；命令越多，回放时间越长。使用aof-use-rdb-preamble yes可以大幅提升恢复速度，因为 RDB 快照的加载效率远高于逐条命令回放。

如果发现 Redis 重启恢复时间过长，通常意味着 AOF 文件已经过大，应及时执行BGREWRITEAOF瘦身，并检查自动重写配置是否合理。

7.4 截断文件的修复

如果 AOF 文件因异常停机出现截断，可以通过 Redis 自带的redis-check-aof工具修复：

redis-check-aof --fix appendonly.aof

执行修复时，工具会扫描文件，找到最后一条完整命令，并丢弃其后不完整的部分。修复完成后，Redis 通常即可正常加载。需要强调的是，--fix是以丢弃截断尾部为代价进行修复，被丢失的数据无法找回，因此修复前做好备份非常必要。

八、Redis 7.0 AOF 新特性：多文件 AOF 与 manifest 清单

Redis 7.0 对 AOF 做了一个重大架构调整：把原来的单一 AOF 文件拆分成多个文件，并引入 manifest 清单文件来管理这些文件。这一变化解决了旧版本 AOF 在重写期间的一些痛点，也带来了更好的可管理性和更强的稳定性。

8.1 旧版本 AOF 的痛点

在 Redis 7.0 之前，AOF 主体只有一个文件，例如appendonly.aof。重写时，子进程先生成临时文件，完成后再用临时文件替换旧文件。这个机制基本可靠，但在极端情况下存在风险：例如替换文件时崩溃，可能导致旧文件被破坏、新文件尚未写完，最终两个文件都无法完整加载；又例如重写过程中磁盘空间并发占用，临时文件和旧文件同时占用大量磁盘。

此外，单文件结构也让 AOF 的维护、恢复和增量备份不够灵活。Redis 7.0 的多文件 AOF 正是为了解决这些问题而设计。

8.2 多文件 AOF 的基本结构

在 Redis 7.0 中，AOF 相关文件不再是一个文件，而是统一放在appenddirname指定的目录里。目录下通常包含以下几类文件：

• 基础 AOF 文件：形如appendonly.aof.1.base.aof，保存重写后某个历史时间点的完整数据，通常使用 RDB 前导格式。
• 增量 AOF 文件：形如appendonly.aof.1.incr.aof，保存基础文件之后产生的增量写命令。
• manifest 清单文件：形如appendonly.aof.manifest，记录当前有效的 AOF 文件列表及加载顺序。

这种「基础文件加增量文件」的设计，使重写时不再需要一次性生成一个覆盖全部数据的巨大临时文件，增量数据和历史数据可以分开管理，文件替换的原子性也更容易保证。

8.3 manifest 清单文件的作用

manifest 文件是多文件 AOF 的目录。它记录了哪些 AOF 文件有效、类型是什么、加载顺序如何。Redis 启动时会先读取 manifest，再根据清单依次加载基础文件和增量文件。

从运维角度看，manifest 的出现意味着不能再只靠复制一个appendonly.aof来备份 AOF。正确做法是备份整个appendonlydir目录，或者至少同时备份 manifest 及其引用的所有文件。如果只复制增量文件而漏掉基础文件，恢复时数据就不完整；如果只备份旧的基础文件而忽略增量文件，又会丢失最近的数据。

8.4 多文件 AOF 的加载顺序

Redis 7.0 加载多文件 AOF 的顺序大致如下：

1. 读取并解析 manifest 清单。
2. 根据清单顺序，先加载基础 AOF 文件。
3. 基础文件加载完成后，按时间顺序依次加载各增量 AOF 文件。
4. 所有文件回放完成后，Redis 恢复到最后一次写入时的数据状态。

这种分文件、分阶段加载的设计，让恢复过程更清晰，也为后续实现增量备份、选择性恢复等高级能力打下基础。

8.5 Redis 7.0 其他值得关注的 AOF 调整

除了多文件 AOF，Redis 7.0 还对 AOF 做了一些实用调整：

• 新增appenddirname配置，AOF 文件统一收拢到子目录。
• AOF 文件命名规则改变，不再默认仅叫appendonly.aof，而是带序号和类型的多段命名。
• 重写机制得到优化，借助多文件结构减少替换旧文件时的风险。
• 错误检测和日志提示更完善，AOF 文件不完整或 manifest 异常时能给出更明确的信息。

从低版本升级到 7.0 的用户，最需要注意的是文件布局已经改变。原来的appendonly.aof会被迁移到新目录结构中，升级前务必做好备份，并确认工作目录路径设置正确。

九、AOF 常见故障排查

在真实生产环境中，AOF 相关故障并不少见。掌握典型问题的排查思路，能在关键时刻快速恢复服务。下面列举几类高频问题及其处理方向。

9.1 问题一：Redis 启动失败，提示 AOF 文件损坏

现象：启动日志中出现类似「Bad file format reading the append only file」「Unexpected end of file」的报错。

排查方向：先确认 AOF 文件是否完整。如果aof-load-truncated设置为no，截断文件会导致 Redis 拒绝启动。此时可以尝试使用redis-check-aof检查并修复：

redis-check-aof /path/to/appendonlydir

在 Redis 7.0 中，直接检查目录即可，工具会根据 manifest 找到所有相关文件。修复完成后再尝试启动。注意，修复通常会丢弃文件尾部不完整数据，修复前尽可能备份原始文件。

9.2 问题二：AOF 文件增长过快，磁盘空间告警

现象：磁盘使用率持续上升，AOF 文件体积异常增大。

排查方向：首先确认自动重写是否开启，检查auto-aof-rewrite-percentage和auto-aof-rewrite-min-size是否合理。可以手动执行BGREWRITEAOF触发重写，观察文件是否缩小。同时注意业务是否产生大量高频写命令，例如频繁对同一键执行INCR、LPUSH，必要时结合业务调整键设计，减少不必要写入。

9.3 问题三：Redis 性能突然下降，I/O 等待升高

现象：业务响应变慢，监控显示磁盘 I/O 很高，甚至出现fsync延迟。

排查方向：检查appendfsync当前值。如果使用always，写入量变大时很容易出现性能瓶颈，可考虑改为everysec。同时检查是否正在执行 AOF 重写，重写会带来较大磁盘 I/O。如果业务高峰与重写时间重叠，可通过调整自动重写条件，或在低峰期手动重写来缓解。

9.4 问题四：Redis 重启后数据「少了」一部分

现象：Redis 重启恢复后，发现最近一段时间的数据丢失。

排查方向：这是典型的数据丢失窗口问题。先确认appendfsync配置。使用everysec时最多丢失约 1 秒数据；使用no时丢失窗口更大。如果no-appendfsync-on-rewrite设置为yes，重写期间宕机也可能丢失更多数据。应根据业务对数据丢失的容忍度，合理调整相关配置。

十、AOF 最佳实践与性能调优

把 AOF 用对、用好，是 Redis 运维的核心课题之一。下面从配置、备份、监控和调优几个方面给出实践建议。

10.1 开启策略：混合持久化更稳妥

多数生产场景下，推荐同时开启 RDB 和 AOF，即混合持久化。RDB 用于快速恢复和异地备份，AOF 用于保障数据完整性。虽然两者同时开启时 Redis 重启会优先加载 AOF，但 RDB 仍可作为辅助备份手段，在 AOF 文件损坏或误删除时提供兜底。

10.2 推荐的基础配置

一个相对通用的 AOF 配置范例如下：

# 开启 AOF appendonly yes 每秒刷盘，兼顾性能与安全 appendfsync everysec 自动重写：文件达到 64MB 且相对上次增长一倍时触发 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 使用 RDB 前导，加速恢复 aof-use-rdb-preamble yes 启动时忽略截断的文件尾部 aof-load-truncated yes 重写期间保持正常刷盘 no-appendfsync-on-rewrite no

这组配置适合大多数普通业务。对于写入量特别大、硬盘为机械盘的环境，可适当提高auto-aof-rewrite-min-size，减少自动重写频率；对于数据极为敏感的环境，可将appendfsync调整为always，但需要评估性能损耗。

10.3 备份：整目录备份而不是单文件

这是 Redis 7.0 多文件 AOF 时代的重要变化。由于 AOF 不再是单一文件，备份时必须备份整个 AOF 目录，例如整个appendonlydir，同时带上 manifest 文件。如果自定义了appenddirname，备份脚本也要相应调整。只备份某个基础文件或增量文件，会导致恢复时数据不完整。

有条件的话，还可以结合 RDB 快照做定期异地备份，并在备份完成后做一次BGREWRITEAOF，让 AOF 文件保持可控体积。

10.4 监控与巡检

建议对以下指标保持关注：

• 当前 AOF 文件大小及增长趋势。
• 最近一次 AOF 重写时间、重写前后的文件大小变化。
• fsync延迟和磁盘 I/O 使用率。
• Redis 日志中是否有 AOF 相关报错或告警。
• 磁盘剩余空间，避免 AOF 占满磁盘导致写入失败。

可以在低峰期定期查看INFO persistence命令输出：

redis-cli INFO persistence

重点关注aof_enabled、aof_current_size、aof_last_rewrite_time_sec、aof_last_bgrewrite_status等字段，以便第一时间发现异常。

10.5 性能调优的几个要点

• 尽量使用 SSD：AOF 是顺序追加写，SSD 能显著提升fsync性能，尤其在always策略下。
• 控制写入频率：高频更新的业务尽量避免对同一键反复执行大量写操作，可在业务层做批量写入或合并更新。
• 合理安排重写时机：避免自动重写与业务高峰重叠，必要时通过定时任务在低峰期手动触发。
• 关注 fork 开销：AOF 重写需要 fork 子进程，内存越大、写入越频繁，fork 瞬间越容易延迟，必要时使用大页内存等优化手段。
• 评估 no-appendfsync-on-rewrite：重写期间磁盘压力过大时，可在接受少量丢失风险的前提下设为yes，以安全性换稳定性。

十一、总结

AOF 是 Redis 保障数据安全的核心机制之一。它通过追加写命令的方式记录每一条写操作，并在重启时通过命令回放恢复数据。相比 RDB 快照，AOF 的数据完整度更高，配合everysec刷盘策略，通常可以将数据丢失窗口控制在 1 秒以内。

要把 AOF 用好，需要重点掌握以下几条线：

• 写入链路：命令先进入内存缓冲区，再通过write写入系统页缓存，最后由fsync刷到磁盘，其中appendfsync决定刷盘时机。
• 配置体系：从开启 AOF、设置文件名和目录，到刷盘策略、自动重写条件、截断文件处理、RDB 前导格式，每一处配置都直接影响数据安全和性能。
• 重写机制：AOF 重写通过 fork 子进程生成紧凑的新文件，避免文件无限膨胀，并且不会阻塞主线程。
• 恢复流程：Redis 启动时优先加载 AOF，7.0 版本通过 manifest 清单管理多个 AOF 文件，按顺序完成基础文件和增量文件的回放。
• 7.0 新特性：多文件 AOF、appenddirname目录收拢、manifest 清单文件，让 AOF 的部署、备份和恢复更加清晰可靠。

在实际落地时，建议以「混合持久化、整目录备份、定期重写、关键指标监控」作为基线方案，并根据业务对数据安全和性能的具体要求，灵活调整appendfsync及相关参数。只有真正理解 AOF 背后的每一步，遇到问题时才能快速定位、从容应对。