Redis RDB `save` 命令与 `bgsave` 命令的区别与应用

好的，没问题！

各位观众，各位朋友，大家好！我是今天的主讲人，一位在代码堆里摸爬滚打多年的老兵。今天咱们来聊聊 Redis 的 RDB 持久化，特别是 SAVE 和 BGSAVE 这两个命令。这俩哥们儿，听起来都是保存数据，但实际工作方式可是大相径庭，用不好，轻则影响性能，重则数据丢失，所以咱们得好好掰扯掰扯。

RDB 持久化：Redis 的“后悔药”

首先，咱们得明白 RDB 持久化是干啥的。简单来说，它就是 Redis 的一个“后悔药”机制。Redis 就像一个记忆力超群，但记性不太稳定的家伙，数据都在内存里，一旦断电，啥都没了。RDB 持久化就是定期把内存里的数据快照保存到硬盘上，万一 Redis 挂了，我们可以用这个快照恢复数据。

SAVE：霸道总裁式保存

SAVE 命令，你可以把它想象成一个霸道总裁，做事雷厉风行，但有点不顾及别人感受。当你执行 SAVE 命令时，Redis 会立即停止所有客户端请求，专心致志地把数据保存到硬盘上的 RDB 文件中。

• 优点： 简单粗暴，保证数据完整性。
• 缺点： 在保存期间，Redis 无法处理任何请求，造成阻塞，严重影响性能。特别是数据量很大的时候，阻塞时间会更长。

代码示例（不推荐）：

127.0.0.1:6379> SAVE
OK
(15.35s)

看到没？执行 SAVE 命令后，Redis 返回了 OK，并且告诉你花了 15.35 秒。这 15.35 秒，你的 Redis 服务就跟死机了一样，啥也干不了。想象一下，如果你的网站正处于流量高峰期，突然来这么一下，用户肯定会骂娘。

BGSAVE：温柔体贴式保存

BGSAVE 命令，就像一个温柔体贴的暖男，做事考虑周全，不会打扰到别人。当你执行 BGSAVE 命令时，Redis 会 fork 一个子进程来执行 RDB 文件的保存，而主进程可以继续处理客户端请求。

• 优点： 不会阻塞主进程，性能影响较小。
• 缺点： 需要 fork 子进程，消耗一定的系统资源（CPU 和内存）。

代码示例：

127.0.0.1:6379> BGSAVE
Background saving started

执行 BGSAVE 命令后，Redis 返回 Background saving started，表示后台保存已经启动，主进程可以继续干活了。

SAVE vs BGSAVE：一场实力悬殊的较量

为了更直观地比较 SAVE 和 BGSAVE，咱们来列个表格：

特性	SAVE	BGSAVE
执行方式	阻塞主进程	fork 子进程
性能影响	严重影响性能	影响较小
资源消耗	较小	较大（CPU 和内存）
适用场景	数据量小，对性能要求不高的场合	大部分场景
数据一致性	理论上更高，因为保存期间不会有数据修改	可能会有数据不一致，因为主进程还在处理请求

深入理解 BGSAVE 的工作原理

BGSAVE 命令之所以能够不阻塞主进程，关键在于它使用了 fork 系统调用。fork 会创建一个与父进程（Redis 主进程）几乎完全一样的子进程，包括内存空间、文件描述符等。

1. fork 子进程： Redis 主进程接收到 BGSAVE 命令后，首先会 fork 一个子进程。
2. 子进程写入 RDB 文件： 子进程负责将内存中的数据写入到 RDB 文件中。
3. 主进程继续处理请求： 主进程继续处理客户端请求，不受影响。

写时复制 (Copy-on-Write) 技术：

fork 之后，父子进程共享内存空间。但是，为了避免子进程在写入 RDB 文件时修改数据，影响主进程的正常运行，Redis 使用了写时复制 (Copy-on-Write) 技术。

当主进程或子进程尝试修改共享的内存页时，操作系统会为该内存页创建一个新的副本，并将修改操作应用到副本上。这样，主进程和子进程就拥有了独立的内存页，互不影响。

配置 Redis 自动执行 BGSAVE

手动执行 BGSAVE 命令太麻烦了，Redis 提供了自动执行 BGSAVE 的配置选项，可以在 redis.conf 文件中进行设置。

save 900 1       # 900 秒内如果至少有 1 个 key 被修改，则执行 BGSAVE
save 300 10      # 300 秒内如果至少有 10 个 key 被修改，则执行 BGSAVE
save 60 10000    # 60 秒内如果至少有 10000 个 key 被修改，则执行 BGSAVE

这些配置选项的含义是：

• save <seconds> <changes>：如果 <seconds> 秒内至少有 <changes> 个 key 被修改，则执行 BGSAVE。

你可以根据自己的业务需求，设置合适的 save 选项。建议设置多个 save 选项，以覆盖不同的场景。

RDB 文件的命名和位置

RDB 文件的默认名称是 dump.rdb，默认位置是 Redis 的工作目录。你可以在 redis.conf 文件中修改这些配置选项。

dbfilename dump.rdb   # RDB 文件名
dir ./                # RDB 文件存放目录

RDB 文件的压缩

Redis 提供了 RDB 文件压缩功能，可以减小 RDB 文件的大小，节省磁盘空间。

rdbcompression yes   # 是否压缩 RDB 文件

建议开启 RDB 文件压缩功能，但需要注意的是，压缩和解压缩会消耗一定的 CPU 资源。

RDB 文件的校验和

Redis 提供了 RDB 文件校验和功能，可以在加载 RDB 文件时检查文件的完整性，防止数据损坏。

rdbchecksum yes    # 是否启用 RDB 文件校验和

建议开启 RDB 文件校验和功能，以提高数据的可靠性。

最佳实践：RDB 持久化的配置建议

1. 禁用 SAVE 命令： 除非你真的非常清楚自己在做什么，否则强烈建议禁用 SAVE 命令，防止误操作导致服务阻塞。可以通过 rename-command SAVE "" 在 redis.conf 文件中禁用 SAVE 命令。
2. 合理配置 save 选项： 根据业务需求，设置合适的 save 选项，平衡数据安全性和性能。
3. 开启 RDB 文件压缩和校验和： 减小 RDB 文件大小，提高数据可靠性。
4. 定期备份 RDB 文件： 将 RDB 文件备份到其他存储介质上，以防止数据丢失。
5. 监控 BGSAVE 的执行情况： 监控 BGSAVE 的执行时间、CPU 和内存消耗等指标，及时发现和解决问题。

如何监控BGSAVE执行情况？

Redis 提供了 INFO persistence 命令，可以查看 RDB 持久化的相关信息，包括上次 BGSAVE 的执行时间、状态等。

127.0.0.1:6379> INFO persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1678886400
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_appendonly_buffer_bytes:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
blocked_clients_by_type:{}

重点关注以下几个指标：

• rdb_bgsave_in_progress: 是否正在执行 BGSAVE。
• rdb_last_bgsave_status: 上次 BGSAVE 的状态 (ok 或 err)。
• rdb_last_bgsave_time_sec: 上次 BGSAVE 花费的时间 (秒)。

通过监控这些指标，你可以及时了解 BGSAVE 的执行情况，并根据实际情况进行调整。

案例分析：RDB 持久化配置优化

假设你的 Redis 服务器用于存储用户会话数据，数据量不大，但对数据安全性要求较高。你可以这样配置 RDB 持久化：

save 60 100     # 60 秒内如果至少有 100 个 key 被修改，则执行 BGSAVE
rdbcompression yes
rdbchecksum yes

这个配置的含义是：

• 每 60 秒检查一次，如果至少有 100 个 key 被修改，则执行 BGSAVE，保证数据不会丢失太久。
• 开启 RDB 文件压缩，减小 RDB 文件大小。
• 开启 RDB 文件校验和，提高数据可靠性。

同时，建议你定期备份 RDB 文件，以防止数据丢失。

RDB 持久化的局限性

虽然 RDB 持久化有很多优点，但它也有一些局限性：

• 数据丢失： 如果 Redis 在两次 BGSAVE 之间发生故障，可能会丢失部分数据。
• fork 消耗： BGSAVE 需要 fork 子进程，消耗一定的系统资源。
• 数据恢复时间： 加载 RDB 文件恢复数据需要一定的时间，特别是数据量很大的时候。

为了克服 RDB 持久化的局限性，Redis 还提供了 AOF (Append Only File) 持久化机制。AOF 持久化会将每个写命令追加到 AOF 文件中，可以提供更高的数据安全性。

RDB 和 AOF 的选择

RDB 和 AOF 是 Redis 提供的两种持久化机制，你可以根据自己的业务需求选择合适的持久化方式。

• 如果对数据安全性要求不高，但对性能要求较高，可以选择只使用 RDB 持久化。
• 如果对数据安全性要求较高，可以选择只使用 AOF 持久化。
• 如果既要保证数据安全性，又要兼顾性能，可以选择同时使用 RDB 和 AOF 持久化。

当 RDB 和 AOF 同时开启时，Redis 会优先使用 AOF 文件恢复数据。

总结

SAVE 和 BGSAVE 是 Redis RDB 持久化的两个重要命令。SAVE 命令会阻塞主进程，影响性能，不建议使用。BGSAVE 命令通过 fork 子进程来执行 RDB 文件的保存，不会阻塞主进程，是更推荐的选择。

合理配置 RDB 持久化选项，可以保证数据的安全性和性能。同时，建议你定期备份 RDB 文件，以防止数据丢失。

好了，今天的讲座就到这里。希望大家对 Redis 的 RDB 持久化有了更深入的了解。谢谢大家！