Redis 持久化：AOF vs RDB，怎么选？

Redis 的持久化机制主要有两种：RDB (Redis DataBase) 和 AOF (Append Only File)。它们各有优缺点，选择哪种持久化方式取决于你的具体应用场景和需求。

第一，我们分别了解一下 RDB 和 AOF 的工作原理：

1. RDB (Redis DataBase) – 快照持久化

工作原理: RDB 会在指定的时间间隔内，将 Redis 在内存中的数据库快照（snapshot）以二进制文件的形式保存到磁盘上。你可以配置 Redis 在满足特定条件时自动触发 RDB 快照，例如：每隔 X 秒，并且至少有 Y 个键被修改。每隔 Z 秒。
优点:性能高: RDB 持久化是通过 fork() 子进程来完成的，主进程可以继续处理客户端请求，几乎不会阻塞主进程。恢复速度快: RDB 文件是数据库的完整快照，恢复时只需要加载 RDB 文件到内存即可，速度超级快，尤其对于大型数据集。文件紧凑: RDB 文件是二进制压缩格式，文件体积相对较小，更节省磁盘空间和网络传输带宽（用于备份）。
缺点:数据丢失风险: RDB 是定时快照，如果在两次快照之间 Redis 发生故障，那么这段时间内的数据将会丢失。数据丢失的量取决于快照的频率。实时性差: RDB 不是实时持久化，数据安全性相对较低。fork() 开销: 虽然 fork() 操作一般很快，但在数据量超级大的情况下，fork() 过程依旧可能消耗必定的时间和内存，导致短暂的性能抖动。

2. AOF (Append Only File) – 日志持久化

工作原理: AOF 会将 Redis 服务器接收到的每个写命令（包括 SET, HSET, SADD 等）追加（append）到 AOF 文件的末尾。Redis 重启时，会重新执行 AOF 文件中的命令来恢复数据。
优点:数据安全性高: AOF 可以配置不同的 fsync 策略，例如每秒 fsync 或每次写入命令都 fsync，可以最大程度地减少数据丢失的风险。即使 Redis 崩溃，最多也只会丢失 fsync 策略间隔内的数据。实时性好: AOF 是实时或接近实时的持久化，数据安全性更高。文件可读性好: AOF 文件是文本格式，记录的是 Redis 命令，可读性较好，方便进行数据分析或手动修复。日志重写 (AOF Rewrite): AOF 文件会随着时间推移变得越来越大，Redis 提供了 AOF 重写机制，可以在不影响数据完整性的前提下，创建一个新的 AOF 文件，只包含重建当前数据集所需的最小命令集合，减小 AOF 文件体积。
缺点:性能相对较低: AOF 需要记录每个写命令，并且根据 fsync 策略可能需要频繁进行磁盘 I/O 操作，性能相比 RDB 略低，尤其是在高并发写操作场景下。恢复速度较慢: AOF 恢复数据需要重新执行 AOF 文件中的所有命令，如果 AOF 文件很大，恢复时间会比较长。文件体积较大: AOF 文件一般比 RDB 文件大，由于记录的是所有写命令。

RDB vs AOF 对比表格:

如何选择 RDB 和 AOF？

选择 RDB 还是 AOF，或者两者都用，需要根据你的具体需求来权衡：

1. 数据安全性 (Data Safety) 优先:

选择 AOF: 如果你的应用对数据安全性要求超级高，绝对不能容忍数据丢失，那么 强烈提议选择 AOF 持久化。可以将 appendfsync 配置为 always 或 everysec，以最大程度地保证数据安全。
思考 AOF + RDB 组合: 为了兼顾数据安全性和快速恢复，可以 同时启用 AOF 和 RDB。Redis 启动时，会优先使用 AOF 文件进行数据恢复，由于 AOF 文件一般包含更完整的数据。RDB 可以作为一种备份手段，或者在 AOF 文件损坏时作为备用恢复方案。

2. 性能 (Performance) 优先:

选择 RDB: 如果你的应用对性能要求超级高，并且可以容忍必定程度的数据丢失（例如缓存场景），那么 可以选择 RDB 持久化。RDB 的性能开销更小，对 Redis 主进程的影响也更小。
谨慎使用 AOF 的 always 策略: 如果选择 AOF，并且性能敏感，要谨慎使用 appendfsync always 策略，由于它会严重影响性能。可以思考 appendfsync everysec 策略，在数据安全性和性能之间取得平衡。

3. 混合场景:

同时启用 RDB 和 AOF: 对于大多数应用场景，推荐同时启用 RDB 和 AOF 持久化。AOF 保证数据安全性: 使用 AOF 记录所有写操作，最大程度地减少数据丢失风险。RDB 提供快速恢复和备份: 使用 RDB 定期生成快照，用于快速恢复和备份，同时 RDB 文件也更紧凑，方便传输和存储。

总结:

最终的选择应该基于你的具体业务需求、数据重大程度、性能要求以及容忍数据丢失的程度来综合思考。 提议在生产环境中进行充分的测试和评估，选择最适合你的持久化方案。

配置提议:

appendonly yes (启用 AOF)
appendfilename “appendonly.aof” (AOF 文件名)
appendfsync everysec (fsync 策略，可选 always, everysec, no)always: 每次写入命令都 fsync，最安全，性能最差。everysec: 每秒 fsync 一次，数据安全性和性能折中，推荐。no: 不主动 fsync，由操作系统决定何时 fsync，性能最好，数据最不安全。
no-appendfsync-on-rewrite no (在 AOF 重写期间是否禁用 fsync，提议no，保证数据安全)
auto-aof-rewrite-percentage 100 (AOF 文件增长百分比达到多少时触发重写)
auto-aof-rewrite-min-size 64mb (AOF 文件最小多大时触发重写)
aof-rewrite-incremental-fsync yes (AOF 重写期间是否使用增量 fsync，提高性能)
aof-use-rdb-preamble yes (AOF 重写后是否使用 RDB 格式作为前缀，提高恢复速度)