在互联网大厂后端开发领域，Redis 凭借其高性能、高并发的特点，成为了众多项目中不可或缺的数据存储工具。无论是缓存热点数据，还是处理实时计数器，Redis 都能轻松应对。然而，Redis 作为内存数据库，一旦服务器断电、重启等情况发生，内存中的数据就会丢失。为了保证数据的安全性和可靠性，数据持久化就显得尤为重要。而 RDB（Redis Database）作为 Redis 提供的两种持久化方式之一，在很多场景下都发挥着关键作用。

RDB 究竟是什么？

RDB 持久化是把当前进程数据生成快照保存到磁盘上的过程 ，它将数据库在某一时刻的状态以二进制文件的形式进行全量备份到磁盘，记录的是某一时刻的全量数据，这就好比给数据库拍了一张照片，把当时的所有数据都定格保存下来，这个快照文件就称为 RDB 文件。

RDB 的触发机制

RDB 的触发机制分为手动触发和自动触发这两大类别。

手动触发

save 命令：此命令会阻塞当前 Redis 服务器，直至 RDB 过程完全结束。在高并发的线上环境中，倘若 Redis 内存数据量庞大，save 命令的执行会造成长时间的阻塞，导致 Redis 无法及时处理客户端的请求，极大地影响用户体验，因此在生产环境中一般不建议使用。例如，当 Redis 服务器处理大量的实时交易数据缓存时，若执行 save 命令，可能会使得新的交易请求无法及时响应，造成交易延迟甚至失败。

bgsave 命令：当客户端发送 bgsave 命令后，Redis 会调用 fork 函数创建一个子进程。该子进程专门负责将数据写入临时文件，完成写入操作后，再用临时文件原子替换上次持久化好的文件。在此期间，父进程（即主进程）能够继续处理客户端的命令请求，不会被阻塞。不过，需要注意的是，主进程其实会短暂阻塞在 fork () 过程中，只是在通常情况下，该指令的执行速度相对较快，对整体性能的影响较为有限。比如在一个电商秒杀场景中，大量用户同时请求 Redis 缓存中的商品库存数据，此时若使用 bgsave 命令进行 RDB 持久化，主进程仍可高效处理这些高并发请求，而子进程在后台完成数据持久化工作，互不干扰。

自动触发

存在以下几种自动触发 bgsave 命令生成 rdb 文件的情况：

save m n 配置触发：在 redis.conf 配置文件中，可以设置 save m n 参数，其含义是在 m 秒内，若数据库发生了至少 n 次修改操作，就会自动触发 bgsave 操作。例如，常见的默认配置有 “save 900 1”，这表示如果在 900 秒内，数据库中有至少 1 条数据发生了修改，就会自动执行 bgsave 来生成 RDB 文件；“save 300 10” 意味着 300 秒内若有至少 10 次数据修改，也会触发；还有 “save 60 10000”，即 60 秒内出现至少 10000 次数据修改时触发。这种配置方式能够根据业务数据的变化频率，灵活地进行 RDB 持久化操作，在数据变动达到一定程度时，及时保存数据状态。

主从复制触发：在 Redis 的主从复制架构中，当从节点需要从主节点进行全量复制时，会触发主节点执行 bgsave 操作。主节点生成当前时刻的快照，并将其发送给从节点，以完成从节点的数据初始化。例如，在一个分布式系统中，新增了一个从节点来分担读压力，此时主节点就会自动触发 bgsave，将自身的数据状态快照传递给新的从节点，确保从节点与主节点的数据一致性。

debug reload 命令触发：当执行 debug reload 命令重新加载 Redis 时，也会触发 bgsave 操作，以便重新加载配置的同时，保存当前的数据状态。这在运维人员对 Redis 进行配置调整并希望保留当前数据状态时非常有用。

shutdown 命令触发：在默认情况下，当执行 shutdown 命令关闭 Redis 服务且未开启 AOF 持久化时，也会触发 bgsave 操作，将内存中的数据保存到磁盘，防止数据丢失。

RDB 的执行过程

当执行 bgsave 时，其具体执行流程如下：

1、主进程首先会检查当前是否已有正在执行的子进程。若存在正在执行的子进程（例如之前的 bgsave 操作尚未完成，或者正在进行 AOF 重写等其他子进程操作），那么主进程直接返回，不再重复创建子进程，避免资源浪费和可能的冲突。

2、若当前没有正在执行的子进程，主进程则调用 fork 函数创建一个新的子进程。这个 fork 过程会短暂阻塞主进程，在阻塞期间，主进程无法处理客户端请求，但由于 fork 操作通常执行速度较快，对性能的影响一般较小。一旦 fork 完成，主进程即可恢复正常，继续处理客户端的命令请求。

3、新创建的子进程负责执行数据持久化工作。子进程首先将数据写入一个临时的 rdb 文件中。在写入过程中，子进程会按照特定的格式，将 Redis 内存中的数据结构，如键值对、哈希表、列表等，依次转换为二进制形式写入临时文件。当所有数据都成功写入临时 rdb 文件后，子进程会执行原子替换操作，用这个新生成的临时 rdb 文件替换掉旧的 rdb 文件。原子替换操作能够确保在文件替换过程中，不会出现数据不一致或文件损坏的情况，保证了 RDB 文件的完整性。

4、子进程完成数据写入和文件替换后，会发送一个信号给主进程，通知主进程 RDB 持久化操作已经完成。主进程接收到该信号后，会更新相关的统计信息，例如在 info Persitence 下的 rdb_* 相关选项，记录本次 RDB 操作的完成时间、文件大小等信息，方便运维人员进行监控和管理。

写时复制（COW）技术

在 RDB 执行过程中，写时复制（Copy - on - Write，COW）技术发挥着至关重要的作用。其核心原理如下：

Redis 主进程 fork 生成的子进程可以共享主进程的所有内存数据。在 fork 操作完成后的初始阶段，父子进程共享同一块内存空间，并不会立刻对内存进行拷贝，而是将真正的内存拷贝动作推迟到实际需要修改数据的时候。

假设在 RDB 快照期间，主进程和 bgsave 子进程同时访问内存数据。如果主进程只是读取内存数据，那么这与 bgsave 子进程的操作并不冲突，因为读取操作不会改变内存数据的状态，父子进程可以安全地共享该内存数据。

但如果主进程要修改 Redis 内存中的某个数据（例如数据 C），此时操作系统内核会发挥关键作用。操作系统内核会将被修改的内存数据复制一份，这个复制出来的数据是修改之前的原始数据。复制完成后，未被修改的内存数据依然由父子两个进程共享，而被主进程修改的内存空间则归属于主进程，被复制出来的原始数据归属于子进程。、

这样一来，主进程就能够在 RDB 快照发生的过程中，毫无顾虑地接受并处理数据写入的请求，而子进程也仍然能够基于复制时的数据状态，对某一时刻的内存数据做完整的快照，既保证了数据的一致性，又提高了系统在快照期间的并发处理能力。例如，在一个实时数据分析系统中，Redis 缓存着大量的实时数据，在进行 RDB 快照时，主进程可能会不断接收新的数据分析结果并写入 Redis，而借助写时复制技术，子进程可以不受干扰地对当前数据状态进行快照保存，确保数据的完整性和准确性。

RDB 文件特点

RDB 文件具有一些显著的特点：

（一）二进制文件且体积小

RDB 文件采用二进制格式存储数据，这种格式相较于文本格式，能够更紧凑地表示数据，从而大大减小了文件的体积。同时，RDB 文件默认使用 LZF 算法进行压缩，进一步压缩了文件大小。较小的文件体积使得 RDB 文件在备份和传输过程中更加高效，占用更少的网络带宽和磁盘空间。例如，在进行数据异地备份时，较小的 RDB 文件能够更快地传输到远程服务器，减少备份时间和成本。

（二）恢复速度快

在恢复数据时，加载 RDB 文件到内存的速度相对 AOF 方式更快。这是因为 RDB 文件记录的是某一时刻的全量数据，在加载时，Redis 可以直接按照二进制格式快速将数据读入内存，重建数据结构。而 AOF 文件记录的是一系列的写命令，在恢复时需要逐条执行这些命令来重建数据，相对而言耗时更长。所以在一些对数据恢复速度要求极高的场景，如电商大促前的服务器数据恢复、游戏服务器重启后的快速数据加载等，RDB 的恢复速度优势就显得尤为重要。

总结

总结一下，RDB 的优点很明显，文件体积小，便于传输和备份，数据恢复速度快。但它也有缺点，RDB 是间隔性的全量持久化，两次持久化之间如果发生故障，会丢失这期间的数据；而且 bgsave 执行期间，如果数据修改频繁，fork 出来的子进程内存占用会很大。所以，大家在实际项目中，要根据业务场景，合理选择 RDB 持久化方式，也可以结合 AOF，取长补短。欢迎大家在评论区分享自己在 Redis 数据持久化方面的实践经验和遇到的问题，咱们一起探讨！