Redis的数据主要保存在内存中，一旦进程退出或服务器宕机，内存数据就会消失。为了避免数据全部丢失，Redis提供了RDB和AOF两种持久化方式，其中RDB是一种基于时间点快照的持久化方案。它会把某个瞬间的完整数据集写入磁盘，生成一个紧凑的二进制文件，默认名称为dump.rdb。RDB不是实时记录每次写操作，而是按照一定条件触发，因此恢复速度通常较快，适合用作灾备和冷备份。
RDB持久化的工作流程
RDB持久化的核心是快照。当Redis触发RDB保存时，会调用操作系统提供的fork机制创建一个子进程。父进程继续处理客户端请求，子进程则负责把当前内存数据写入临时文件，写入完成后再用临时文件替换旧的dump.rdb文件。由于fork采用写时复制技术，子进程创建时并不会立即复制所有内存页，只有在父进程修改某些数据时，相关内存页才会被复制。这样既能保证快照的一致性，又不会让主进程长时间停顿。
触发RDB持久化的方式主要有三类。第一类是执行save命令，该命令由Redis主进程直接完成快照写入，期间会阻塞所有客户端请求，只适合在数据量较小或可以接受阻塞的场景下使用。第二类是执行bgsave命令，Redis会fork一个子进程异步执行快照写入，主进程只负责短暂fork，之后可以继续处理请求，这是生产环境最常用的手动触发方式。第三类是根据配置文件中save规则自动触发，例如save 900 1表示900秒内至少有1次写操作就触发一次bgsave。多个规则可以同时生效，满足任意一条就会执行快照。
此外，当Redis执行shutdown命令并且没有启用AOF持久化时，也会自动执行一次RDB保存，确保正常关闭时数据落盘。主从复制场景中，从节点第一次同步时也可能触发主节点生成RDB文件发送给从节点。理解这些触发路径可以帮助运维人员判断备份文件何时生成、是否会带来额外负载。
RDB核心配置参数详解
RDB的行为主要由redis.conf中的几个参数控制。最常用的是save规则，格式为save <seconds> <changes>，表示在指定秒数内发生指定次数的写操作就触发快照。例如：
# 900秒内至少1次写操作 save 900 1 # 300秒内至少10次写操作 save 300 10 # 60秒内至少10000次写操作 save 60 10000
如果想去掉自动保存，可以将所有save规则注释掉，或把save规则配置为空字符串，但需要谨慎评估数据丢失风险。dbfilename参数用于指定RDB文件名，默认是dump.rdb。dir参数指定RDB文件和AOF文件的存储目录，建议放在持久化磁盘上，避免使用内存文件系统。stop-writes-on-bgsave-error默认开启，表示当bgsave过程发生错误时，主进程会拒绝写入请求，这样可以让运维人员尽快发现磁盘故障；如果自动监控完善，也可以关闭该选项以避免写入被阻断。
另外，rdbcompression默认开启，Redis会使用LZF算法压缩RDB文件，降低磁盘占用，但会增加少量CPU消耗。rdbchecksum默认开启，在写入RDB文件末尾添加CRC64校验和，读取文件时进行校验，有助于发现文件损坏，代价是大约10%的性能开销。实际部署时可以根据机器性能和数据规模调整这些参数。例如数据量较大且CPU紧张时，可以保留压缩但关闭校验。
执行bgsave前可以通过info persistence查看rdb_last_bgsave_status、rdb_last_save_time等指标，判断上次快照是否成功。手动备份时不必停止Redis，直接执行bgsave，再把生成的dump.rdb复制到安全位置即可。恢复数据时，先停止Redis，将备份的dump.rdb放到dir指定的目录，再启动Redis，它会自动加载该文件。
RDB的优缺点与适用场景
RDB最大的优点是文件紧凑、恢复速度快。二进制格式比AOF的逐条命令日志更适合做全量恢复，也方便传输到异地做灾备。另一个优点是对性能影响相对可控，因为bgsave由子进程完成，主进程只在fork阶段短暂停顿。不过当内存数据量很大时，fork操作可能消耗较多内存和时间，尤其在虚拟化环境中，写时复制会带来额外内存压力。
RDB的缺点也很明显：它不是持续记录变更，而是按照触发条件生成快照，所以两次快照之间的数据更新可能丢失。如果Redis在最新一次快照后发生宕机，这部分数据无法恢复。对于数据完整性要求极高的业务，仅使用RDB往往不够，需要配合AOF或混合持久化。RDB也不适合在高频写入场景下频繁全量快照，因为每个快照都要遍历整个数据集，随着数据量增长，生成成本会明显上升。
从实际经验看，RDB更适合作为周期性冷备份、异地容灾、数据规模不大或对少量数据丢失可接受的场景。比如缓存集群、会话数据、排行榜等可以重建或允许短时间丢失的数据。如果业务涉及订单、账户余额等关键数据，则应该把AOF作为主要持久化手段，RDB作为辅助备份。
混合持久化与配置建议
Redis从4.0版本开始支持混合持久化，通过aof-use-rdb-preamble参数开启。开启后，AOF文件的重写阶段会先生成RDB格式的全量数据，再追加AOF增量命令，这样既能保持AOF的数据安全性，又能利用RDB文件加载快的特点。对于既要恢复速度、又要保证数据完整性的业务，混合持久化是较好的选择。
生产环境常见的配置策略是：开启AOF和RDB，并设置合理的save规则，例如save 900 1、save 300 10，同时开启aof-use-rdb-preamble yes。如果数据量较大，可以适当放宽save触发频率，避免频繁fork影响性能。还需监控RDB生成时长、文件大小和磁盘剩余空间，防止磁盘写满导致bgsave失败。
最后，无论选择哪种持久化方案，都应定期演练数据恢复流程。RDB文件可能因为磁盘损坏、复制中断或版本不兼容而无法加载，因此要保留多个时间点的备份，并在测试环境验证恢复。只有把配置、监控和恢复流程结合起来，才能真正发挥RDB快照在Redis数据可靠性中的作用。