选择最佳的Redis持久化策略：RDB与AOF

Redis将数据存储在内存中，因此在依赖它存储任何不易重建的数据之前，你需要一个持久化策略。在RDB和AOF之间做出选择会影响你可能丢失的数据量、Redis重启的速度以及工作负载产生的磁盘I/O量。

当定期快照足够时，使用RDB。当需要更严格的持久性时，使用AOF。当你需要实用的持久性以及更简单的备份时，可以同时使用两者，但仍需使用真实数据集测试恢复过程。

理解Redis持久化

Redis中的持久化是指将内存中的数据集保存到磁盘的能力，以便在服务器重启或崩溃后重新加载。如果没有持久化，服务器停止或崩溃时，Redis中存储的所有数据都会丢失。Redis提供了两种不同的方法来实现这一点：

RDB（Redis数据库）：数据集的时间点快照。
AOF（仅追加文件）：服务器执行的每个写操作的日志。

这两种方法各有特点，适用于不同的场景。

Redis数据库（RDB）

RDB持久化在指定的时间间隔内对Redis数据集执行时间点快照。当触发RDB保存操作时，Redis会fork一个子进程。然后，子进程将整个数据集写入一个临时的RDB文件。文件写入完成后，旧的RDB文件会被新的文件替换。

RDB的工作原理

Fork：Redis服务器fork出一个新的子进程。
快照：子进程开始将整个数据集写入一个临时的RDB文件。
完成：子进程完成写入后，用新的临时文件替换旧的RDB文件。
清理：子进程退出。

这个过程确保Redis在拍摄快照时可以继续处理客户端请求，因为父进程仍然保持响应。

RDB的优点

紧凑的备份：RDB文件是二进制压缩的，提供了Redis数据集的非常紧凑的表示。这使得它们非常适合备份和灾难恢复。
快速重启：加载RDB文件比重放AOF文件快得多，特别是对于大型数据集，因为它涉及加载单个预格式化的二进制文件。
最小的磁盘I/O：RDB仅在配置的时间间隔内保存，这意味着Redis在不保存时执行最小的磁盘I/O。这可以在正常操作期间带来更高的性能。
易于传输：作为一个单一的紧凑文件，RDB备份易于传输到远程数据中心进行灾难恢复或归档。

RDB的缺点

潜在的数据丢失：主要缺点是可能丢失数据。如果Redis在保存点之间崩溃，自上次成功RDB保存以来写入的所有数据都将丢失。
Fork期间的性能峰值：对于非常大的数据集，初始的fork()操作可能很慢，并会短暂阻塞Redis服务器，尤其是在内存使用率高的情况下。
非实时持久化：RDB不适用于实时数据持久化。它最适合于丢失几分钟数据可以接受的场景。

RDB配置

RDB持久化默认在redis.conf中使用save指令启用。你可以指定多个save规则：

# 每900秒（15分钟）保存一次数据库，如果至少有1个键发生变化
save 900 1

# 每300秒（5分钟）保存一次数据库，如果至少有10个键发生变化
save 300 10

# 每60秒保存一次数据库，如果至少有10000个键发生变化
save 60 10000

# 禁用RDB持久化（注释掉所有save指令，或显式设置如下）
# save ""

你也可以在redis-cli中使用SAVE（阻塞）或BGSAVE（非阻塞）命令手动触发RDB保存。

仅追加文件（AOF）

AOF持久化记录Redis服务器接收到的每个写操作。AOF不是定期保存整个数据集，而是记录修改数据集的命令。当Redis重启时，它会重新执行AOF文件中的这些命令来重建原始数据集。

AOF的工作原理

命令日志记录：Redis执行的每个写命令都会追加到AOF文件中。
fsync策略：Redis有各种fsync策略来控制AOF缓冲区同步到磁盘的频率：
- appendfsync always：每个命令后同步。这提供了最佳的持久性，但也是最慢的。
- appendfsync everysec：每秒同步一次。这是持久性和性能之间的良好平衡（默认且推荐）。
- appendfsync no：依赖操作系统将AOF缓冲区刷新到磁盘。提供最佳性能，但持久性最差。
AOF重写：随着时间的推移，由于冗余命令（例如，多次更新同一个键），AOF文件可能会变得非常大。AOF重写通过创建一个新的、更小的AOF文件来优化AOF文件，该文件仅包含重建当前数据集所需的必要命令。这个过程类似于RDB的fork机制。

AOF的优点

更好的持久性：使用appendfsync always或everysec，AOF提供比定期RDB快照更强的持久性。使用everysec，Redis通常将丢失限制在约一秒钟的已确认写入，但操作系统或磁盘故障仍可能影响持久性。
更少的数据丢失：在崩溃的情况下，根据你的fsync策略，你丢失的数据显著减少，甚至可能没有丢失。
可检查的格式：AOF存储Redis协议命令，因此与RDB文件相比，可以更容易地使用Redis工具进行检查和修复。

AOF的缺点

更大的文件大小：对于相同的数据集，AOF文件通常比RDB文件大得多，因为它们存储的是命令而不是紧凑的数据。
恢复速度较慢：在启动时重放大型AOF文件可能比加载RDB文件慢，因为Redis需要执行每个命令。
性能影响：根据fsync策略，AOF可能会引入更多的磁盘I/O，可能影响写入性能。appendfsync always尤其影响大。
AOF重写开销：虽然AOF重写有助于管理文件大小，但重写过程本身会消耗CPU和I/O资源，并且如果数据集非常大，可能会暂时阻塞Redis，类似于RDB的fork。

AOF配置

要启用AOF，你需要在redis.conf中设置appendonly yes：

# 启用AOF持久化
appendonly yes

# 仅追加文件的名称（默认："appendonly.aof"）
appendfilename "appendonly.aof"

# appendfsync选项：always, everysec, no
appendfsync everysec

# 当AOF文件大小是基础大小的两倍且至少为64MB时，自动重写AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB与AOF：对比概述

特性	RDB（Redis数据库备份）	AOF（仅追加文件）
机制	时间点快照（二进制文件）	以Redis协议格式记录的写操作日志
数据丢失	保存点之间可能丢失	使用`everysec`通常约一秒；使用`always`最严格
性能	正常操作期间写入性能更高，`fork()`时可能阻塞	使用强`fsync`时写入较慢，I/O更一致
文件大小	非常紧凑的二进制文件	通常更大，随操作增长
恢复时间	大型数据集更快	大型数据集较慢（重放命令）
备份便利性	单一紧凑文件；易于备份/灾难恢复	文件较大，不重写可能更难管理
可读性	不可读	比RDB更易检查
Redis默认	是（使用`save`指令）	否（默认`appendonly no`）

混合方法：同时使用RDB和AOF

Redis可以同时使用RDB快照和AOF。当启用AOF时，Redis使用AOF进行启动恢复，因为它通常是最新的。现代Redis还可以在启用了aof-use-rdb-preamble yes的重写AOF文件中使用RDB前缀，这可以加速重写和重启。

更快的重写：混合AOF中的RDB部分为重写过程提供了更快的初始快照。
更快的重启（可能）：当Redis重启时，它首先加载AOF文件的RDB部分，这更快，然后重放后续的AOF命令。
更好的持久性：仍然受益于AOF的最小数据丢失。

在假设启用混合AOF之前，请检查你的Redis版本和配置。

选择正确的持久化策略

理想的持久化策略取决于你的应用程序对数据持久性、性能和恢复时间的具体要求。

1. 何时仅使用RDB

主要用例：缓存/非关键数据：如果Redis主要用作缓存，崩溃时丢失一些数据可以接受，或者你的数据可以轻松地从其他来源重建。
高性能要求：当写入性能至关重要且偶尔的数据丢失可以容忍时。
灾难恢复备份：RDB文件非常适合创建用于长期归档或灾难恢复的定期快照。你可以使用cron执行BGSAVE，然后将.rdb文件移动到异地。
内存效率：如果你在磁盘空间上受到严重限制。

2. 何时仅使用AOF

主要用例：绝对持久性：当每个写操作都至关重要，并且丢失几秒钟的数据都不可接受时（例如，金融交易、关键用户数据）。在这种情况下，可以考虑appendfsync always，尽管会有显著的性能成本。
调试/审计：AOF的人类可读性有助于理解数据变化。

3. 何时同时使用RDB和AOF（推荐用于大多数关键应用程序）

平衡的持久性和恢复：这通常是生产系统的推荐方法，其中数据持久性很重要，但你也希望高效的重启和备份。
健壮性：提供额外的保护层。如果一种持久化方法损坏，你仍然可能使用另一种方法恢复。
混合AOF：在支持并启用的地方利用RDB前缀AOF格式。

实用技巧和最佳实践

监控磁盘使用情况：RDB和AOF都可能消耗大量磁盘空间。监控你的磁盘使用情况，确保不会耗尽空间，尤其是在AOF重写或RDB保存之前。
fsync策略：对于AOF，appendfsync everysec是最常见且推荐的选择，在持久性和性能之间提供了良好的平衡。对于关键数据，避免使用appendfsync no。
AOF重写：仔细配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，以确保AOF文件定期优化，而不会过度消耗资源。
分离磁盘/位置：如果可能，将持久化文件（AOF和RDB）存储在与操作系统和应用程序日志不同的磁盘或分区上，以防止I/O争用。
外部备份：无论你的持久化策略如何，定期将RDB和AOF文件备份到异地位置（例如，S3、Google Cloud Storage），以实现强大的灾难恢复。
测试恢复：定期使用你选择的持久化策略测试恢复过程，以确保数据可以成功恢复。

要点

根据恢复要求选择持久化方式，而不是习惯。仅用于缓存的Redis通常可以使用RDB或不进行持久化。用于会话、队列或应用程序状态的Redis通常需要AOF、经过测试的备份以及证明数据能足够快恢复的重启演练。