了解 Redis 持久性选项：RDB 和 AOF
Redis 提供了多个持久性选项，以确保数据持久性并防止在服务器发生故障或重启时丢失数据。了解这些选项对于为您的特定使用案例选择正确的策略、平衡性能和数据安全至关重要。本章节将深入探讨 Redis 中的两种主要持久性机制：Redis 数据库 （RDB） 快照和仅附加文件 （AOF）。我们将探讨它们的工作原理、优点和缺点以及如何配置它们。
了解 RDB 快照
RDB（Redis 数据库）持久性按指定的时间间隔执行数据集的时间点快照。这些快照表示 Redis 数据库在特定时刻的整个状态。
RDB 的工作原理
当指示 Redis 创建 RDB 快照时，它会执行以下步骤：
- **分 叉：**Redis 使用
fork（）系统调用创建子进程。此子进程是父进程（Redis 服务器）的精确副本。 - 数据转储： 然后，子进程遍历内存中的整个数据集，并将其写入磁盘上的临时文件。
- 文件压缩（可选）： 默认情况下，Redis 使用 LZF 压缩来压缩 RDB 文件以减小其大小。这可以进行配置。
- 原子替换： 子进程完成 RDB 文件的写入后，它会以原子方式将旧的 RDB 文件（如果存在）替换为新的 RDB 文件。这可确保 RDB 文件始终处于一致状态。
- 子进程终止： 然后，子进程将退出，从而释放系统资源。
在整个过程中，父进程继续为客户端请求提供服务，从而最大限度地减少停机时间。但是，fork（） 作可能会占用大量资源，尤其是对于大型数据集，因为它暂时需要双倍的内存。
配置 RDB 快照
您可以使用 redis.conf 文件中的 save 指令配置 RDB 快照。save 指令采用两个参数：秒数和在这些秒内必须发生的更改数才能触发快照。
例如：
save 900 1 # Save the DB if at least 1 key changed in 900 seconds
save 300 10 # Save the DB if at least 10 keys changed in 300 seconds
save 60 10000 # Save the DB if at least 10000 keys changed in 60 seconds
redis.conf 中的这些行定义了三个不同的保存点。如果满足_这些条件中的任何一个_ ，Redis 将触发 RDB 快照。您可以通过注释掉所有保存行来完全禁用 RDB 快照。
您还可以使用 redis-cli 中的 SAVE 或 BGSAVE 命令手动触发 RDB 快照。
SAVE：此命令执行同步保存，阻止 Redis 服务器，直到快照完成。通常不建议将其用于生产环境。BGSAVE：此命令使用上述相同的分叉机制执行异步保存。它允许 Redis 服务器在创建快照时继续为客户端请求提供服务。
RDB 的优势
- **压 实 度：**RDB 文件非常紧凑，非常适合用于备份和灾难恢复。
- **性能：**RDB 快照的创建（尤其是压缩）和还原速度相对较快。
- **灾难恢复：**RDB 非常适合灾难恢复，因为单个文件代表整个数据集。
- **数据可移植性：**RDB 文件易于移植，可以传输到其他服务器或存档以进行长期存储。
RDB 的缺点
- **数据丢失可能性：**RDB 快照是时间点备份，因此在快照之间写入的任何数据在服务器发生故障时都将丢失。可能的数据丢失量取决于配置的存储间隔。
- 分叉开销：
fork（）作可能会占用大量资源，尤其是对于大型数据集，这可能会导致暂时的性能下降。
RDB 配置选项
除了 save 指令之外，redis.conf 中其他与 RDB 相关的配置选项还包括：
stop-writes-on-bgsave-error：如果设置为yes（默认值），则当BGSAVE命令失败时，Redis 将停止接受写入作。这可以防止在出现磁盘错误或磁盘空间不足时损坏数据。rdbcompression：如果设置为yes（默认值），Redis 将使用 LZF 压缩 RDB 文件。将其设置为no可以提高 CPU 性能，但会导致 RDB 文件变大。rdbchecksum：如果设置为yes（默认值），Redis 将在 RDB 文件中包含一个校验和，以检测数据损坏。将其设置为no可以提高性能，但会降低数据完整性。dbfilename：指定 RDB 文件的名称（默认值：dump.rdb）。dir：指定 RDB 文件的存储目录（默认：Redis 工作目录）。
了解 AOF（仅追加文件）
AOF（仅附加文件）持久性为 RDB 快照提供了更持久的替代方案。AOF 不会定期拍摄快照，而是记录服务器收到的每个写入作。
AOF 的工作原理
启用 AOF 后，Redis 会将每个写入作（例如 SET、HSET、``LPUSH） 附加到 AOF 文件中。此文件实质上包含对数据库执行的所有写入作的完整历史记录。
- 命令附加： 每次执行写入作时，Redis 都会将相应的命令附加到 AOF 文件中。该命令以 Redis 协议格式编写。
- **文件同步：**AOF 文件会定期同步到磁盘，以保证数据的持久性。此同步的频率是可配置的。
- AOF 重写： 随着时间的推移，AOF 文件可能会变得非常大，因为它包含所有写入作的历史记录。为了减小文件大小，Redis 可以执行 AOF 重写。AOF 重写会创建一个新的、更小的 AOF 文件，其中包含重新创建当前数据集所需的最少命令集。这与 RDB 快照的工作方式类似，但结果仍然是 AOF 文件。
配置 AOF
AOF 在 redis.conf 文件中配置。关键配置选项包括：
appendonly：设置为yes以启用 AOF 持久化。设置为no可禁用它（默认）。appendfilename：指定 AOF 文件的名称（默认：appendonly.aof）。appendfsync：指定 Redis 应将 AOF 文件同步到磁盘的频率。它可以具有以下值之一：always：在每次写入作后同步。这提供了最高级别的数据持久性，但也提供了最低的性能。everysec：每秒同步一次。这是数据持久性和性能之间的良好平衡（推荐）。no：让作系统决定何时同步。这提供了最佳性能，但数据持久性级别最低。
AOF 重写配置
使用以下选项配置 AOF 重写：
auto-aof-rewrite-percentage：指定在触发重写之前 AOF 文件必须增长的百分比。例如，值100表示 AOF 文件的大小必须翻倍才能触发重写。auto-aof-rewrite-min-size：指定触发重写之前 AOF 文件的最小大小。这可以防止重写非常小的 AOF 文件。
您还可以使用 redis-cli 中的 BGREWRITEAOF 命令手动触发 AOF 重写。
AOF 的优势
- **高数据持久性：**AOF 提供比 RDB 更高的数据持久性，尤其是在使用
appendfsync always或appendfsync everysec时。 - 减少数据丢失： 如果服务器发生故障，AOF 可确保将数据丢失降至最低，因为只有最后几个尚未同步到磁盘的命令会丢失。
- **人类可读格式：**AOF 文件采用人类可读格式（Redis 协议），因此可以更轻松地在需要时手动调试和恢复数据。
AOF 的缺点
- **较大的文件大小：**AOF 文件通常比 RDB 文件大，因为它们包含所有写入作的历史记录。
- **性能开销：**AOF 可能会带来性能开销，尤其是在
始终使用 appendfsync时。 - **重写开销：**AOF 重写可能是资源密集型的，尽管它是在后台执行的。
RDB 与 AOF：比较
| 特征 | RDB | AOF |
|---|---|---|
| 数据持久性 | 较低 （可能丢失数据） | 更高（最小数据丢失） |
| 文件大小 | 较小 | 较大 |
| 性能 | 更快 | 更慢（尤其是 always） |
| 恢复时间 | 更快 | 较慢（需要重放命令） |
| 配置 | save 指令 | appendonly， appendfsync 指令 |
| 使用案例 | 备份、灾难恢复、缓存 | 需要高数据持久性的应用程序 |
选择正确的持久性选项
RDB 和 AOF 之间的选择取决于您的具体要求：
- RDB： 如果您需要快速备份和恢复，并且可以容忍一些数据丢失，请使用 RDB。它适用于数据丢失不严重的缓存方案。
- 主干： 如果您需要高数据持久性并且无法承受丢失数据，请使用 AOF。它适用于数据完整性至关重要的应用程序，例如金融系统或存储关键用户信息的数据库。
- 混合方法： 您还可以同时使用 RDB 和 AOF。在这种情况下，Redis 将使用 AOF 来恢复数据，因为它提供了最完整的数据集。RDB 仍可用于非关键情况下的备份和更快的恢复。
实例
示例 1：为缓存服务器配置 RDB
假设您使用 Redis 作为网站的缓存服务器。数据丢失是可以接受的，因为可以从主数据库中检索数据。在这种情况下，您可以配置具有相对不频繁的保存间隔的 RDB：
save 600 100 # Save if at least 100 keys changed in 600 seconds
save 300 1000 # Save if at least 1000 keys changed in 300 seconds
save 60 10000 # Save if at least 10000 keys changed in 60 seconds
此配置为缓存服务器提供了性能和数据持久性之间的良好平衡。
示例 2：为会话存储配置 AOF
假设您使用 Redis 作为电子商务网站的会话存储。数据丢失是不可接受的，因为它可能导致用户丢失购物车或被注销。在这种情况下，您应该每 sece 使用 appendfsync 配置 AOF：
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
此配置可确保每秒将每个会话更改写入磁盘，从而最大限度地降低数据丢失的风险。
示例 3：同时使用 RDB 和 AOF
对于假设的财务应用程序，您可以同时使用 RDB 和 AOF。每 squad 使用 appendfsync 的 AOF 可确保将事务记录的数据丢失降至最低。RDB 快照每天在非高峰时段拍摄，为灾难恢复和报告目的提供方便的备份。如果服务器发生故障，Redis 将使用 AOF 文件进行恢复。如果 AOF 文件已损坏或不可用，则可以将每日 RDB 快照用作回退，从而承认自上次快照以来可能会丢失数据。
