Redis-数据持久化（RBD）

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

数据库是一个系统（应用）最重要的资产之一，所以我们的数据库将从以下几个数据库来进行介绍。

MySQL

PostgreSQL

MongoDB

Redis（本章节）

Etcd

前面介绍Redis的各种特性和集群部署方式，Redis虽然作为内存数据库，但是他还是有一定的持久化需求的，接下来两个小节，我们就来介绍Redis的两种持久化方式：RBD和AOF。

一、RDB 概述

RDB 是 Redis 默认的持久化方式，通过生成数据快照（snapshot）将内存中的数据保存到磁盘的二进制文件（默认名 dump.rdb）中。

二、核心特性

1. 快照机制

• 记录某一时刻的完整数据状态
• 二进制压缩存储，文件体积较小
• 恢复速度快，适合大数据量场景

2. 触发方式

# 手动触发
SAVE          # 同步保存，阻塞所有命令
BGSAVE        # 后台异步保存（推荐）

# 自动触发（配置文件中设置）
save 900 1    # 900秒内至少1个key被修改
save 300 10   # 300秒内至少10个key被修改  
save 60 10000 # 60秒内至少10000个key被修改

三、工作流程（BGSAVE）

主进程
   │
   ├─ 检查是否有正在执行的BGSAVE/AOF重写
   │
   ├─ 调用fork()创建子进程
   │     │
   │    子进程
   │     ├─ 基于父进程内存副本生成RDB
   │     ├─ 写入临时文件
   │     └─ 替换旧的RDB文件
   │
   └─ 继续处理客户端请求

四、配置示例

# redis.conf
# 持久化配置
dir ./               # RDB文件存储目录
dbfilename dump.rdb  # 文件名

# 自动保存策略
save 900 1
save 300 10
save 60 10000

# 其他配置
stop-writes-on-bgsave-error yes  # 保存出错时停止写入
rdbcompression yes               # 启用压缩
rdbchecksum yes                  # 启用校验和

五、优势与局限

✅ 优势：

1. 性能影响小：fork子进程处理，主进程几乎不受影响
2. 恢复速度快：直接加载二进制文件到内存
3. 文件紧凑：压缩存储，适合备份和传输
4. 兼容性好：不同版本Redis的RDB文件基本兼容

❌ 局限：

1. 数据可能丢失：两次快照间的数据有丢失风险
2. fork性能问题：大数据量时fork可能阻塞（内存越大问题越明显）
3. 不够实时：无法做到秒级持久化

六、与AOF对比

七、使用建议

1. 适用场景

• 对数据完整性要求不高的缓存场景
• 需要快速恢复的大数据量场景
• 需要定期备份和灾难恢复