Redis作为主流的内存数据库，提供了RDB和AOF两种持久化方式。其中RDB快照可以把某一时刻的内存数据以二进制形式落到磁盘，方便备份与恢复。BGSAVE命令的作用，就是让Redis在后台异步完成这份快照文件的生成，而不像SAVE那样由主进程同步写盘导致服务暂停。
BGSAVE的基本执行流程
当客户端向Redis发送BGSAVE指令，或者服务端根据配置的save规则自动触发时，Redis主进程会调用fork系统调用创建一个子进程。fork之后，操作系统采用写时复制机制，父子进程最初共享同一块物理内存，因此创建子进程的速度很快，且不会立刻占用双倍内存。
子进程诞生后便开始遍历自己的内存空间，将数据库中的键值对按照RDB格式序列化，并写入到临时文件，写完后替换旧的dump.rdb。与此同时，主进程继续处理命令请求，新写入的数据会通过写时复制机制分配到新的内存页，不会影响子进程已经看到的数据视图，从而保证快照是某一时刻的一致性镜像。
为什么BGSAVE不会长时间阻塞主进程
传统SAVE是主进程亲自做磁盘IO，大数据集下可能阻塞数百毫秒甚至数秒。BGSAVE把最重的IO和CPU序列化工作交给子进程，主进程只承担了一次fork的代价。fork本身在页表复制时会有短暂停顿，但一般不需要读写全部内存内容。
需要注意的是，如果实例内存很大且页表庞大，fork延迟仍可能达到几十毫秒。另外在子进程写盘期间，如果业务频繁修改数据，写时复制会让部分内存页被复制，导致实际内存占用上升。因此评估BGSAVE影响时，不能只看到主进程不阻塞，还要看fork成本和写时复制带来的内存波动。
自动触发与手动触发的区别
除了手动执行BGSAVE，Redis也会在满足配置文件中的save指令条件时自动后台保存。例如配置save 900 1表示900秒内有至少1次修改就触发。自动触发走的就是BGSAVE逻辑，不会用同步SAVE。
手动触发适合在业务低峰做一次性备份，比如升级前执行一次。自动触发则依赖运维对数据丢失窗口的容忍度。如果save条件过密，BGSAVE频率过高，磁盘IO和fork压力会叠加；如果过松，故障时会丢更多数据。实践中常用save 900 1、save 300 10、save 60 10000这类梯度配置平衡安全与开销。
关键配置与监控参数
redis.conf里和BGSAVE相关的核心配置包括dir（RDB文件目录）、dbfilename（文件名）、save（触发规则）、stop-writes-on-bgsave-error（保存出错是否停止写）、rdbcompression（是否压缩）。这些参数直接决定快照行为和故障表现。
监控上可用INFO persistence查看latest_bgsave_status、rdb_last_bgsave_time_sec、rdb_last_bgsave_status等指标。若发现bgsave耗时变长或状态失败，应检查磁盘空间、IO负载及内存是否紧张。以下表格列出常用观测项：
| 指标名 | 含义 | 关注点 |
|---|---|---|
| rdb_last_bgsave_time_sec | 上次BGSAVE耗时秒数 | 过大说明数据集大或磁盘慢 |
| rdb_last_bgsave_status | 上次执行结果 | 非ok需排查错误 |
| latest_fork_usec | 最近一次fork微秒数 | 反映主进程停顿长短 |
常见误区与处理建议
有人认为BGSAVE完全无感，其实fork在超大实例上仍会造成可感知延迟。还有人把stop-writes-on-bgsave-error设成no，虽避免写停但可能掩盖存储故障，导致一直无法落盘而不自知。
建议对关键业务保留默认yes，并在监控里对接bgsave失败告警。若实例内存超过20G，可评估是否改用AOF配合rewrite，或把BGSAVE放到专用从节点执行，主节点关闭自动save，由从库承担快照压力，从而隔离风险。
总体来看，BGSAVE用fork加子进程的方式实现了不阻塞主服务的RDB快照，是Redis高可用备份的基石。理解其机制有助于在容量规划、配置调优和故障定位中做出合理决策。