Redis-bgsave浅析

什么是bgsave？

BGSAVE 是 Redis 用于生成 RDB 持久化文件的核心操作，它的本质是：

主线程 fork 一个子进程，子进程会独立遍历 Redis 内存数据，将其序列化并写入磁盘（生成.rdb 文件）；
整个过程中，主线程完全不参与数据遍历，仍能正常处理业务请求。

什么时候会用到bgsave？

定期备份

定期备份策略

bash 复制代码

# 生产环境典型备份计划
0 2 * * * /usr/local/bin/redis-backup.sh  # 每天凌晨2点执行

# 备份脚本示例
#!/bin/bash
redis-cli BGSAVE
wait_for_bgsave_complete
cp /var/lib/redis/dump.rdb /backup/redis/dump-$(date +%Y%m%d).rdb

适用场景：

数据库每日/每周全量备份
灾备恢复准备
数据迁移前的快照

数据迁移

javascript 复制代码

源服务器：
redis-cli BGSAVE
scp dump.rdb new-server:/path/to/redis/

目标服务器：
systemctl stop redis
cp dump.rdb /var/lib/redis/
systemctl start redis

故障排查与数据分析

scss 复制代码

# 使用RDB文件进行分析
redis-cli BGSAVE
# 等待完成后使用工具分析
rdb --command memory dump.rdb --bytes 128 --largest 10 // 大key分析

分析场景：

查找内存泄漏原因
分析大Key分布
优化数据结构设计

AOF重写机制

markdown 复制代码

# AOF重写内部流程
1. redis-cli BGREWRITEAOF
2. Redis执行fork()创建子进程
3. 子进程基于当前数据生成新的AOF文件
4. 实际上就是执行了一次BGSAVE+命令回放

** AOF重写 = BGSAVE + 命令回放**

主从复制初始化

markdown 复制代码

# 新从节点加入集群时
主节点流程：
1. 接收到SLAVEOF命令
2. 执行BGSAVE创建RDB快照
3. 将RDB文件发送给从节点
4. 从节点加载RDB完成初始化

bgsave会存在哪些问题？

GSAVE 会导致 "业务抖动" 和 "实例抖动"。

BGSAVE 虽然不阻塞主线程，但会占用大量系统资源（CPU、内存、磁盘 IO） ，这些资源抢占会间接影响 Redis 服务和依赖它的业务，具体体现在三个方面：

1. CPU 抢占

CPU 抢占：导致业务请求响应变慢（业务抖动）

BGSAVE 子进程的核心工作是 "遍历内存数据 + 序列化 + 写磁盘"，这三个步骤都需要消耗 CPU。比如：子进程要把一个 1GB 的哈希表序列化到磁盘，需要持续占用 CPU 进行数据结构解析和二进制编码 ------ 如果单机 CPU 是 4 核，子进程可能会占用 1 核的 80% 以上资源。

而 Redis 主线程（处理业务请求）也需要 CPU：比如执行HGET user:100 name需要解析 key、查找哈希表、返回结果。当子进程抢占大量 CPU 时，主线程能拿到的 "CPU 时间片" 会减少，直接导致：

正常情况下 1~~2ms 就能响应的请求，延迟可能飙升到 10~~20ms；
高并发场景（如每秒 10 万请求）下，部分请求会因超时被业务端重试，甚至返回失败 ------ 这就是 "业务请求抖动"。

2. 内存复制

内存复制：可能触发 "内存交换"（Redis 实例抖动）

BGSAVE 子进程创建时，会用到 Linux 的写时复制（Copy-On-Write，COW） 机制，这个机制是为了 "节省内存"，但也可能引发新问题。

COW 的逻辑是：

子进程刚创建时，不直接拷贝主线程的内存数据，而是和主线程共享同一块内存；
只有当主线程修改某块内存（比如执行SET key new_val）时，系统才会 "复制" 这块内存的旧版本给子进程（确保子进程能拿到修改前的数据，生成一致快照）。

如果 Redis 内存占用很高（比如 16GB 内存用了 14GB），且 BGSAVE 期间有大量写操作（比如每秒 1 万次SET），会发生什么？

大量内存被 "复制"：主线程每修改一块内存，就会生成一份副本，导致系统可用内存骤降；
触发 Swap（内存交换）：当可用内存不足时，操作系统会把部分内存数据写到磁盘的 "交换分区"（Swap 分区），而磁盘 IO 速度比内存慢 1000 倍以上；
Redis 实例卡顿：主线程要读取被交换到磁盘的数据时，需要等待磁盘 IO，响应延迟会从毫秒级变成百毫秒级，甚至出现 "实例短暂无响应"------ 这就是 "Redis 服务实例抖动"。

3. 磁盘 IO 抢占

磁盘 IO 抢占：拖慢 AOF 持久化（雪上加霜）

如果你的 Redis 同时开启了 AOF 持久化（AppendOnly yes，生产环境大多会开），BGSAVE 还会和 AOF 抢占磁盘 IO 资源。

AOF 的逻辑是：主线程执行修改命令后，会把命令写入 AOF 缓冲区，再由后台线程定期将缓冲区内容刷到磁盘（默认每秒一次，appendfsync everysec）。

而 BGSAVE 子进程需要把 16GB 的内存数据写入磁盘（生成.rdb 文件），会占用大量磁盘写 IO------ 比如原本 AOF 刷盘每秒只需要 10MB IO，BGSAVE 执行时磁盘写 IO 可能飙升到 100MB/s，导致：

AOF 刷盘延迟：原本 1ms 能完成的刷盘，变成 20ms；
主线程等待刷盘：如果 AOF 缓冲区满了，主线程会暂时阻塞等待刷盘完成，进一步加剧业务请求延迟。