Redis-bgsave浅析

什么是bgsave?

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

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

什么时候会用到bgsave?

定期备份

定期备份策略

 #后端 #Redis# 生产环境典型备份计划

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 服务和依赖它的业务,具体体目前三个方面:

C 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 缓冲区满了,主线程会暂时阻塞等待刷盘完成,进一步加剧业务请求延迟。
© 版权声明
THE END
如果内容对您有所帮助,就支持一下吧!
点赞0 分享
两眼一闭就过去了_的头像 - 鹿快
评论 抢沙发

请登录后发表评论

    暂无评论内容