AOF 与 RDB 持久化性能权衡对比

Redis 持久化是在可容忍的数据丢失量与服务器能承受的磁盘工作负载之间进行权衡。然而，当启用持久化（允许将数据保存到磁盘以便重启后恢复）时，开发者必须选择一种机制。Redis 的两种主要持久化方法是快照（RDB）和追加文件（AOF）。理解每种方法的性能影响、持久性特征和配置权衡，对于调整 Redis 以满足特定应用在速度与数据安全性之间的需求至关重要。

RDB 快照紧凑且加载速度快。AOF 更频繁地记录写入操作，通常能提供更好的恢复点，但会消耗更多磁盘 I/O。

理解 Redis 持久化

Redis 将其整个数据集存储在易失性内存中。持久化机制是将这些数据移动到磁盘上，以便 Redis 在重启后重新加载数据集，确保在服务中断或重启时数据的可用性。RDB 和 AOF 通过根本不同的方法实现这一目标，从而产生不同的性能特征。

1. Redis 数据库（RDB）快照

RDB 在指定时间间隔创建整个数据集的紧凑时间点快照，并将其保存到二进制文件（dump.rdb）中。

RDB 的工作原理及其性能影响

RDB 持久化主要依赖于 BGSAVE 命令（后台保存）。当触发保存时：

分叉： Redis 将主进程分叉出一个子进程。
快照： 子进程将整个数据集写入磁盘上的 RDB 文件。
主线程基本不受影响： 主 Redis 线程在写入操作期间继续处理客户端请求，不会被阻塞，因为子进程处理磁盘 I/O。

性能考虑：

写入延迟： 通常，RDB 在保存操作期间对写入延迟的影响最小，因为工作被卸载。主要的性能成本是分叉时所需的 CPU 峰值和初始 I/O 突发，以及大文件写入时。
恢复时间： RDB 在重启时加载非常快，因为它是一个单一、优化的文件，从而最小化恢复延迟。
持久性权衡： 如果 Redis 在计划保存之间崩溃（例如，每 5 分钟），则自上次保存以来的所有写入都会丢失。这使得 RDB 的持久性不如 AOF。

配置 RDB 保存

RDB 保存使用 redis.conf 文件中的 save 指令配置，指定时间间隔和更改次数：

save 900 1     # 如果 900 秒（15 分钟）内至少 1 个键被更改，则保存
save 300 10    # 如果 300 秒（5 分钟）内至少 10 个键被更改，则保存
save 60 10000  # 如果 60 秒（1 分钟）内至少 10000 个键被更改，则保存

2. 追加文件（AOF）持久化

AOF 将 Redis 服务器接收到的每个写入操作记录到追加日志文件中。当 Redis 重启时，它会按顺序重放这些命令以重建数据集。

AOF 的工作原理及其性能影响

与 RDB 不同，AOF 专注于事务日志记录。其性能特征在很大程度上取决于 fsync 策略，该策略决定了 Redis 强制操作系统将缓冲数据写入物理磁盘的频率。

AOF Fsync 策略：

策略	`appendfsync` 设置	持久性	性能影响
每秒	`everysec`	正常操作下良好；崩溃可能丢失约一秒的已确认写入	良好的平衡；常见的生产选择。
不同步	`no`	差（依赖操作系统缓冲区）	最快；操作系统崩溃时数据丢失风险最大。
始终	`always`	最强的 AOF 持久性策略	最慢；每次写入时磁盘同步导致延迟显著增加。

性能考虑：

写入延迟： 使用 appendfsync always 时，每个写入命令都会产生磁盘同步的延迟，与 RDB 或内存操作相比，显著减慢操作速度。使用 everysec 通过批量处理 fsync 来显著缓解此问题。
恢复时间： AOF 文件可能变得很大，重放数百万条命令可能比加载紧凑的 RDB 文件花费更长时间，导致更高的恢复延迟。
文件大小： AOF 文件通常比 RDB 文件大得多，因为它们存储命令（例如，SET key value）而不是数据结构的最终状态。

启用和配置 AOF

AOF 默认禁用，通过设置 appendonly yes 在 redis.conf 中启用。关键设置是 appendfsync：

appendonly yes
appendfilename "appendonly.aof"
# 持久性与速度权衡的推荐设置
appendfsync everysec

性能权衡分析：AOF 与 RDB

选择 RDB 或 AOF 需要优先考虑原始操作速度（延迟）或保证的数据恢复。

延迟和吞吐量

RDB（原始速度最佳）： 由于写入由后台进程处理，主 Redis 线程在保存期间几乎不直接受到 I/O 影响。这通常导致更低的整体写入延迟，除非系统在 BGSAVE 分叉发生时负载过重。
AOF（always 模式）： 此配置最慢，因为磁盘延迟直接引入到每个客户端写入命令中，导致更高的 p99 延迟。
AOF（everysec 模式）： 对于大多数操作，提供接近 RDB 的性能，因为 fsync 操作被缓冲且频率较低。

持久性和数据丢失风险

AOF（持久性最佳）： 提供最高的持久性，尤其是使用 appendfsync always 时。即使使用 everysec，数据丢失也限制在一秒内。
RDB（持久性最差）： 数据丢失可能跨越几分钟或几小时，具体取决于保存计划。

恢复时间

RDB（快速恢复）： 由于优化的紧凑二进制格式，重启时间更快。
AOF（较慢恢复）： 重放大型命令日志可能比加载快照花费更长时间，从而增加重启期间的停机时间。

最佳实践：同时使用两种持久化方法

对于要求高性能和强持久性保证的环境，推荐的方法是同时启用 RDB 和 AOF 持久化。

当两者都启用时，Redis 在启动时使用 AOF 文件进行重放，以实现最大数据一致性。它继续定期生成 RDB 快照。

为什么同时使用两者？

更好的恢复选择： 当两者都启用时，Redis 通常首先加载 AOF，因为它通常更完整。保留 RDB 为备份和灾难恢复提供了额外的回退工件。
操作灵活性： RDB 紧凑且易于归档，而 AOF 缩小了数据丢失窗口。它们共同覆盖不同的故障模式。

同时使用两者的配置片段：

# 1. 启用 RDB
save 900 1

# 2. 启用 AOF 并使用 'everysec' 同步
appendonly yes
appendfsync everysec

管理 AOF 文件大小（重写）

AOF 的一个显著操作问题是文件大小增长。随着时间的推移，AOF 文件可能变得巨大，因为它记录了每次修改，即使是覆盖先前值的修改。为了解决这个问题，Redis 提供了 AOF 重写。

AOF 重写生成一个新的、优化的 AOF 文件，其中仅包含重建数据集当前状态所需的最小命令集。当当前 AOF 文件的大小增长到超过基础大小的某个倍数时，此过程会自动触发。

auto-aof-rewrite-percentage 100  # 当 AOF 文件比基础大小大 100% 时重写
auto-aof-rewrite-min-size 64mb    # 除非文件至少为 64MB，否则不重写

重写警告： 与 RDB 保存一样，AOF 重写涉及分叉进程。如果您的系统内存受限，这种临时加倍的内存使用（活动实例加上正在重写的副本）可能导致不稳定或交换。

总结

当快速重启、紧凑备份和低写入开销比丢失最近写入更重要时，使用 RDB。当您需要更紧密的恢复窗口而不同步每次写入时，使用带有 appendfsync everysec 的 AOF。对于许多生产系统，同时启用两者可提供持久性、备份便利性和恢复选项的实用组合。