Redis bgsave的使用小结

什么是bgsave？

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

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

什么时候会用到bgsave？

定期备份

定期备份策略

# 生产环境典型备份计划
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

适用场景：

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

数据迁移

源服务器：
redis-cli BGSAVE
scp dump.rdb new-server:/path/to/redis/
目标服务器：
systemctl stop redis
cp dump.rdb /var/lib/redis/
systemctl start redis

故障排查与数据分析

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

分析场景：

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

AOF重写机制

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

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

主从复制初始化

# 新从节点加入集群时
主节点流程：
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 时间片” 会减少，直接导致：

• 正常情况下 12ms 就能响应的请求，延迟可能飙升到 1020ms；
• 高并发场景（如每秒 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 缓冲区满了，主线程会暂时阻塞等待刷盘完成，进一步加剧业务请求延迟。

到此这篇关于Redis bgsave的使用小结的文章就介绍到这了,更多相关Redis bgsave使用内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！