redis数据结构-12（配置 RDB 快照：保存间隔和压缩）
配置 RDB 快照：保存间隔和压缩
Redis 持久性对于确保在服务器重启或发生故障时数据不会丢失至关重要。虽然 Redis 以其内存中数据存储而闻名，但它提供了将数据持久化到磁盘的机制。本章节重点介绍其中一种机制：Redis 数据库 （RDB） 快照。我们将探讨如何配置 RDB 快照，特别是关注保存间隔和压缩，以实现数据持久性和性能之间的适当平衡。
了解 RDB 快照
RDB 快照涉及将整个 Redis 数据集保存到二进制文件中的磁盘。此文件通常名为 dump.rdb，表示 Redis 数据的时间点快照。RDB 是一种紧凑的单文件表示形式，使其适用于备份和灾难恢复。
RDB 快照的工作原理
当指示 Redis 创建 RDB 快照时，它会执行以下步骤：
- **分 叉：**Redis 使用
fork（）系统调用创建子进程。这是一个关键步骤，因为子进程处理磁盘 I/O，允许主 Redis 进程继续为客户端请求提供服务。 - 数据转储： 子进程遍历内存中的 Redis 数据集，并将其写入磁盘上的临时文件。
- 文件替换： 数据转储完成后，子进程将旧的
dump.rdb文件（如果存在）替换为新文件。 - 进程终止： 然后，子进程将退出，从而释放系统资源。
RDB 快照的优势
- **压 实 度：**RDB 文件通常比 AOF 文件小（我们将在下一课中讨论），这使得它们能够有效地进行存储和传输。
- **性能：**RDB 快照的创建速度相对较快，尤其是与重写 AOF 文件相比。
- **灾难恢复：**RDB 文件非常适合备份整个 Redis 数据集并在发生故障时进行还原。
RDB 快照的缺点
- 数据丢失可能性： 由于 RDB 快照是时间点备份，因此，如果服务器在下一个快照之前崩溃，则在最后一个快照之后写入 Redis 的任何数据都将丢失。可能的数据丢失量取决于配置的存储间隔。
- 分叉开销：
fork（）作可能是资源密集型的，尤其是在具有大型 Redis 数据集的系统上。当子进程处理 I/O 时，主进程在分叉过程中会短暂阻塞。
配置保存间隔
保存间隔决定了 Redis 自动创建 RDB 快照的频率。您可以使用 save 指令在 redis.conf 文件中配置这些间隔。
save 指令
save 指令采用两个参数：
- 秒： 自上次成功保存以来必须经过的秒数。
- 变化： 在指定秒数内必须发生的密钥更改（写入）的最小次数。
语法如下：
save
您可以配置多个 save 指令来定义不同的 save 策略。如果满足_任何_配置的保存条件，Redis 将触发快照。
保存间隔配置示例
以下是一些常见的保存配置及其含义：
save 900 1：如果在 900 秒（15 分钟）内至少更改了 1 个密钥，则保存数据库。save 300 10：如果在 300 秒（5 分钟）内至少更改了 10 个键，则保存数据库。save 60 10000：如果在 60 秒（1 分钟）内更改了至少 10000 个键，请保存数据库。
示例场景：
假设您有以下保存配置：
save 600 100
save 60 1000
在这种情况下 _，如果满足_以下任一条件，Redis 将创建 RDB 快照：
- 在 600 秒 （10 分钟） 内至少修改了 100 个密钥。
- 在 60 秒 （1 分钟） 内至少修改了 1000 个密钥。
禁用自动快照：
要完全禁用自动 RDB 快照，您可以注释掉 redis.conf 文件中的所有 save 指令：
# save 900 1
# save 300 10
# save 60 10000
或者，您可以将 save 指令设置为空字符串：
save ""
手动快照：
即使禁用了自动快照，您仍然可以通过 redis-cli 使用 SAVE 或 BGSAVE 命令手动触发 RDB 快照。SAVE 命令会阻止 Redis 服务器，直到快照完成，而 BGSAVE 会在后台执行快照（使用分叉机制）。
选择正确的保存间隔
选择合适的保存间隔是在数据持久性和性能之间进行权衡。
- 更频繁的快照： 减少数据丢失的可能性，但由于更频繁的分叉和磁盘 I/O 而会增加服务器上的负载。
- 不太频繁的快照： 减少服务器上的负载，但增加数据丢失的可能性。
选择 save intervals 时，请考虑以下因素：
- 数据敏感性： 避免数据丢失有多重要？如果要存储高度敏感的数据，则可能需要更频繁的快照。
- 写入卷： 您的数据写入 Redis 的频率如何？如果您的写入量很大，则可能需要更频繁的快照来捕获更改。
- 服务器资源： 您的服务器可以处理多少 CPU 和磁盘 I/O？如果您的服务器受资源限制，则可能需要选择频率较低的快照。
真实世界的例子：
- 电子商务产品目录： 一家电子商务公司使用 Redis 缓存产品目录数据。数据丢失是不可取的，但不是灾难性的，因为可以从主数据库重建目录。他们将
save 3600 1000配置为在至少更新了 1000 个产品时每小时创建一个快照。 - 实时分析： 实时分析平台使用 Redis 来存储聚合指标。数据丢失是可以接受的，因为指标会不断更新。他们将
save 60 10000配置为在至少更新了 10,000 个指标时每分钟创建一个快照。 - 假设的社交媒体应用程序： 社交媒体应用程序使用 Redis 存储用户会话数据。丢失会话数据会给用户带来不便，但并不严重。他们可能会选择不太频繁的快照间隔，例如
save 7200 100，以最大程度地减少对服务器性能的影响。
配置 RDB 压缩
Redis 可以压缩 RDB 快照以减小它们在磁盘上的大小。这可以节省存储空间并减少传输备份所需的时间。
rdbcompression 指令
redis.conf 中的 rdbcompression 指令控制是否压缩 RDB 快照。它接受一个布尔值：
yes：启用压缩（默认）。no：关闭压缩。
rdbcompression yes
压缩的工作原理
启用压缩后，Redis 使用 LZF 算法在将 RDB 数据写入磁盘之前对其进行压缩。LZF 是一种快速、无损的压缩算法，非常适合压缩内存中的数据。
压缩的权衡
- 优势：
- 减少了磁盘空间使用。
- 更快的备份和还原时间（由于文件大小较小）。
- 弊：
- 快照创建和还原期间的 CPU 使用率增加。
何时启用或禁用压缩
- 启用压缩：
- 您的磁盘空间有限。
- 您希望减少备份和还原时间。
- 您的服务器有足够的 CPU 资源。
- 禁用压缩：
- 您的服务器受 CPU 限制。
- 磁盘空间不是主要问题。
- 您希望将快照创建对服务器性能的影响降至最低。
真实世界的例子：
- 大型数据集，有限的存储： 一家拥有大型 Redis 数据集和有限存储空间的公司启用 RDB 压缩以减少磁盘使用量。它们在快照创建期间监控 CPU 使用率，以确保它不会影响服务器性能。
- CPU 受限的服务器： 拥有 CPU 受限型 Redis 服务器的公司会禁用 RDB 压缩，以最大程度地减少快照创建对服务器性能的影响。它们具有充足的磁盘空间，并且优先考虑性能而不是存储效率。
- 假设的游戏公司： 一家游戏公司使用 Redis 来存储游戏状态数据。它们支持 RDB 压缩以减小备份的大小，这些备份经常传输到异地存储以进行灾难恢复。他们仔细监控 CPU 使用率，以确保压缩不会影响游戏服务器性能。