作为开发者，我们喜欢Redis的速度。但当运维同学问起"这个Redis数据能丢吗？"，或者发现测试环境重启后缓存全空时，我们才真正开始关心持久化这个问题。

Redis提供了两种主要的持久化方式：RDB（快照）和AOF（追加日志）。它们不是二选一的关系，而是需要根据业务场景精心搭配的工具。让我们抛开理论，从实际开发中的痛点出发，深入理解这两种策略。

一、RDB（快照）：定时存档的游戏策略

想象一下你在玩一个复杂的游戏。RDB就像是在特定节点（比如打完一个Boss后）手动存档。存档瞬间可能会卡一下，但之后如果游戏崩溃，你可以从这个存档点重新开始，只是会丢失存档后的进度。

1. RDB是如何工作的？

RDB的核心是创建某个时间点的数据快照。在Redis中，当触发保存条件时，它会fork出一个子进程。这个子进程拥有父进程内存数据的拷贝，然后负责将数据写入一个临时的RDB文件，写入完成后替换旧文件。

关键配置（redis.conf）：

# 保存条件：900秒内至少1个key变化，300秒内至少10个变化，60秒内至少10000个变化
save 900 1
save 300 10
save 60 10000

# 如果后台保存失败，是否停止接收写操作（一种保护机制）
stop-writes-on-bgsave-error yes

# 是否压缩RDB文件（压缩会消耗CPU，但节省磁盘空间）
rdbcompression yes

2. 开发中遇到的RDB典型问题

问题场景：内存占用翻倍？
当你执行SAVE（同步保存，会阻塞）或BGSAVE（后台保存）时，如果数据集很大（比如10GB），你会发现Redis的内存占用突然增加到近20GB。这是因为fork操作使用了写时复制（Copy-on-Write）机制。虽然子进程理论上共享内存，但只要父进程有写入操作，被修改的内存页就需要被复制，导致内存增长。

解决方案与调优：

• 避免在内存紧张时执行BGSAVE：监控系统内存，选择业务低峰期进行持久化。
• 调整保存频率：如果数据不是特别关键，可以放宽保存条件，比如只保留save 3600 1（1小时内有变化就保存），减少fork频率。
• 使用独立进程：对于超大数据集，可以考虑关闭Redis的RDB，使用外部工具（如redis-rdb-tools）定期生成快照。

3. RDB的优势与适用场景

• 优势：

  • 紧凑的单文件：非常适合用于备份和灾难恢复。你可以把某个时间点的RDB文件拉到另一个Redis实例直接恢复。
  • 最大化Redis性能：父进程除了fork瞬间有阻塞，其余时间全力处理请求，持久化由子进程完成。
  • 更快的重启恢复：恢复大数据集时，直接加载RDB比回放AOF日志要快得多。

• 适用场景：

  • 允许分钟级数据丢失的缓存场景。
  • 需要做历史数据快照用于数据分析。
  • 磁盘空间紧张的环境。

二、AOF（追加日志）：记录每一个操作的日记

如果RDB是游戏存档，那AOF就像是把你游戏中的每一个操作（"向前走三步"、"向左转"、"攻击"）都记录下来。恢复时，只需要按照记录重新执行一遍所有操作即可。

1. AOF是如何工作的？

AOF将每一个会修改数据集的写命令（如SET, HSET, SADD）追加到文件末尾。当Redis重启时，会重新执行AOF文件中的所有命令来重建数据。

关键配置：

# 开启AOF
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# 同步策略：always-每个命令都同步，everysec-每秒同步，no-由操作系统决定
appendfsync everysec

# AOF重写触发条件：当前AOF文件比上次重写后的大小增长了100%，并且至少64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

2. 开发中遇到的AOF典型问题

问题场景：AOF文件膨胀与恢复缓慢
我们有一个存储用户会话的Redis，平时只是简单的SETEX和GET。但有一天，我发现AOF文件竟然有几十个GB，而实际数据量可能只有几百MB。更糟糕的是，Redis重启后，恢复过程极其缓慢。

根源分析：
这是因为很多Redis命令是重复的。比如一个计数器键user:100:count，被INCR了1000次。在AOF文件中就会有1000条INCR命令。但实际上，恢复时我们只需要最后的结果1000。前999条命令都是冗余的。

解决方案：AOF重写（Rewrite）
Redis提供了BGREWRITEAOF命令来解决这个问题。它会创建一个新的AOF文件，这个文件包含重建当前数据集所需的最小命令集合。对于上面的计数器，新AOF文件里可能只有一条SET user:100:count 1000命令。

重写是自动触发的（根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size），也可以手动执行。这是AOF持久化性能调优的关键。

3. AOF的优势与适用场景

• 优势：

  • 更高的数据安全性：使用appendfsync always可以确保每个写命令都落盘，最多丢失一个命令（但性能极差）。通常用everysec，最多丢失1秒数据。
  • 可读性：AOF文件是纯文本格式（Redis协议），你可以用文本编辑器打开它，看到所有写操作的历史，这在调试时非常有用。
  • 容错性更好：如果AOF文件尾部损坏（比如磁盘满了），可以使用redis-check-aof工具修复，去除损坏的部分。

• 适用场景：

  • 数据非常重要，不能容忍大量数据丢失的场景，如存储了用户状态、购物车等。
  • 需要审计：可以通过分析AOF文件来了解写操作模式。

三、实战中的抉择：不是二选一，而是如何搭配

在实际项目中，我几乎从不单独使用RDB或AOF，而是采用混合模式。Redis 4.0以后引入了RDB-AOF混合持久化，这几乎是当前的最佳实践。

1. 如何配置混合持久化？

# 开启AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# 开启混合持久化（AOF重写时会使用RDB格式作为文件前半部分）
aof-use-rdb-preamble yes

2. 混合持久化如何工作？

• 正常运行时：AOF文件以普通的AOF格式（文本）记录每一个写命令。
• 执行AOF重写时：子进程会先创建一个当前数据集的RDB快照，并将其写入新的AOF文件。然后，在重写期间产生的新写命令，会以AOF格式（文本）追加到这个RDB数据后面。
• 最终的文件结构是：[RDB格式的数据快照][AOF格式的增量命令]

3. 为什么这是最佳实践？

• 兼顾了重启速度和数据安全性：恢复时，先快速加载RDB部分，然后回放增量AOF命令。这比纯AOF恢复快，又比纯RDB数据更完整。
• 避免了AOF文件无限膨胀：定期重写相当于做了"压缩"。

四、性能调优：从能用 到 好用

1. 针对RDB的调优：

• 调整save规则：根据业务容忍度。对于缓存数据，可以设置save 900 1（15分钟变化一次就存）。对于重要数据，可以设置save 60 1000（1分钟内有1000次变化就存）。
• 避免物理机内存不足：确保系统有足够的空闲内存，以防fork时因内存不足而失败。监控used_memory和系统总内存。

2. 针对AOF的调优：

• 谨慎选择appendfsync：always会严重拖慢性能（每个命令都要刷盘），除非对数据一致性有极端要求。everysec是生产环境的默认推荐值，它在性能和安全性之间取得了很好的平衡。no则性能最好，但可能丢失较多数据。
• 控制AOF重写时机：调整auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。如果写操作非常频繁，可以降低百分比（如80%），让重写更频繁一些，防止单个AOF文件过大。
• 将AOF文件放在高性能磁盘上：如果可能，使用SSD硬盘存放AOF文件，可以显著降低appendfsync everysec带来的延迟。

3. 通用调优建议：

• 监控：使用INFO persistence命令监控持久化相关指标，如rdb_last_save_time, aof_current_size, aof_rewrite_in_progress等。
• 分离持久化与数据目录：如果有条件，将持久化文件（RDB和AOF）放在与数据文件不同的磁盘上，避免I/O竞争。

总结：一张决策表帮你选择

最终，没有"银弹"配置。你需要理解业务的真实需求：能容忍丢失多少数据？恢复速度有多重要？磁盘和性能的瓶颈在哪里？通过理解和调优RDB与AOF，你才能真正驾驭Redis的持久化能力，让它不仅在运行时飞快，在数据安全上也令人安心。