Redis基础

上一篇我们学习了Redis发布订阅（Pub/Sub）模式，依靠“发布-频道-订阅”模型实现了轻量级实时通知，搞定了博客评论、站内消息等简单推送场景。但不管是缓存、分布式锁还是消息通信，Redis数据默认都存在内存中，一旦服务重启、服务器宕机，所有内存数据都会彻底丢失。

想要保住Redis数据，就必须用到持久化机制。Redis提供了两种持久化方案：RDB快照和AOF日志，其中RDB（Redis Database）快照是最基础、最常用的持久化方式，通过定时生成内存数据快照文件，实现数据备份与恢复。本篇从零入门RDB持久化，从原理、配置、手动触发到避坑，带你牢牢掌握Redis数据备份核心技能。

核心定位：RDB是Redis快照式持久化，定时将内存中的全量数据压缩写入磁盘，生成二进制快照文件；服务重启时，加载快照文件快速恢复数据，适合全量备份、数据容灾场景。

一、为什么需要Redis持久化？

Redis是内存数据库，所有读写操作都在内存中完成，速度极快但也有致命短板：断电即失。

  • 服务器重启、Redis进程崩溃，内存数据会全部清空
  • 缓存数据丢失会导致缓存击穿，瞬间压垮数据库
  • 计数器、分布式锁、Pub/Sub等业务数据丢失，会造成业务故障

持久化的核心作用：将内存数据落地磁盘，防止数据丢失，实现故障恢复。而RDB作为入门级持久化方案，配置简单、性能损耗小，是新手首选。

二、RDB持久化核心原理

RDB采用快照全量备份机制，简单来说就是给内存数据“拍照片”：

  1. 满足触发条件时，Redis主线程fork子进程
  2. 子进程将内存全量数据写入临时二进制文件
  3. 写入完成后，替换旧的RDB快照文件（默认文件名：dump.rdb）
  4. Redis重启时，自动加载dump.rdb文件，快速恢复数据

关键特性：RDB是全量备份，fork子进程过程中主线程会短暂阻塞（数据量越大阻塞越久）；子进程备份时主线程可正常处理请求，不会阻塞业务。

三、RDB核心配置项（redis.conf）

RDB默认开启，通过修改redis.conf配置文件，可自定义备份规则、文件路径、文件名，新手只需关注核心配置即可。

1. 基础配置（必改项）

配置项作用默认值推荐配置
save 秒钟 写次数自动触发RDB的规则：N秒内有M次写操作，自动备份save 3600 1save 300 100save 60 10000根据业务调整，高频写可缩短周期
dbfilenameRDB快照文件名dump.rdb保持默认或自定义（如：redis_dump.rdb）
dirRDB文件存储目录（必须是目录，非文件）./（Redis启动目录）自定义绝对路径（如：/usr/local/redis/data/）

2. 进阶配置（优化项）

  • rdbcompression yes：开启LZF压缩RDB文件，节省磁盘空间，默认开启
  • rdbchecksum yes：开启校验和，防止RDB文件损坏，默认开启
  • stop-writes-on-bgsave-error yes：RDB备份失败时，停止写操作，保证数据安全，默认开启

配置示例

# 3600秒（1小时）内至少1次写操作，触发RDB
save 3600 1
# 300秒（5分钟）内至少100次写操作，触发RDB
save 300 100
# 60秒（1分钟）内至少10000次写操作，触发RDB
save 60 10000

# RDB文件名
dbfilename dump.rdb

# RDB文件存储路径
dir /usr/local/redis/data/

# 开启压缩
rdbcompression yes

# 开启校验
rdbchecksum yes

四、手动触发RDB备份（两种方式）

除了自动备份，日常运维、数据迁移、重启服务前，可手动触发RDB快照，保证数据最新。Redis提供两条手动备份命令，适用场景不同。

1. SAVE命令（阻塞式）

  • 命令：SAVE
  • 原理：主线程直接执行备份，全程阻塞Redis，期间无法处理任何请求
  • 适用场景：Redis停机维护、离线备份，业务低峰期
  • 缺点：阻塞业务，生产环境严禁使用

2. BGSAVE命令（后台非阻塞式，推荐）

  • 命令：BGSAVE
  • 原理：fork子进程在后台异步备份，主线程正常处理业务请求，无阻塞
  • 适用场景：生产环境实时备份、数据迁移、重启前备份
  • 优点：不影响业务，是手动备份的首选

手动触发实操

  1. 连接Redis客户端：redis-cli
  2. 执行后台备份：BGSAVE
  3. 查看备份结果：客户端返回 Background saving started 代表触发成功
  4. 查看RDB文件：进入配置的dir目录，可看到最新的dump.rdb文件
# 连接Redis
redis-cli

# 手动触发后台RDB备份
127.0.0.1:6379> BGSAVE
Background saving started

# 查看备份状态
127.0.0.1:6379> lastsave
(integer) 1742524800  # 返回最近一次RDB备份的时间戳

3. 查看RDB备份状态

  • lastsave：查看最近一次成功执行RDB备份的时间戳
  • 查看Redis日志：日志中会记录 Background saving terminated with success 代表备份完成

五、RDB数据恢复（自动加载）

Redis数据恢复极其简单，无需额外命令，只需两步：

  1. 将备份好的dump.rdb文件，移动至redis.conf配置的dir目录下
  2. 启动Redis服务，Redis会自动加载RDB文件，恢复内存数据

恢复提示：启动Redis时，日志会打印 Loading RDB file，加载完成后即可正常使用数据。

六、RDB持久化优缺点

✅ 优点

  • 文件体积小：二进制压缩文件，占用磁盘空间小，便于传输、备份
  • 恢复速度快：直接加载全量快照，比AOF恢复快很多
  • 性能开销小：子进程异步备份，主线程不阻塞业务
  • 配置简单：无需复杂参数，开箱即用

❌ 缺点

  • 数据丢失风险：RDB是定时备份，两次备份之间宕机，会丢失增量数据
  • fork阻塞风险：数据量极大时，fork子进程会短暂阻塞主线程
  • 全量备份开销：每次都是全量备份，频繁触发会消耗磁盘IO

七、RDB生产最佳实践与避坑

1. 生产禁用SAVE命令

SAVE会阻塞整个Redis服务，高并发场景下会导致业务雪崩，一律使用BGSAVE手动备份。

2. 合理设置自动备份规则

避免过于频繁触发RDB（如每秒备份），防止磁盘IO过高；也不要间隔太久，降低数据丢失风险。

3. 定期迁移RDB文件

定时将dump.rdb文件迁移至其他服务器、云存储，防止服务器磁盘损坏导致备份文件丢失。

4. 搭配AOF使用（高可靠场景）

对数据可靠性要求高的业务，可同时开启RDB+AOF，RDB做全量备份，AOF做增量补全，兼顾速度与安全性。

5. 监控RDB备份状态

通过lastsave命令、Redis日志监控备份状态，设置告警，防止备份失败未察觉。

八、核心总结

RDB速记：快照全量备，fork后台跑；配置超简单，恢复速度快；丢数有风险，搭配AOF稳。 核心命令：BGSAVE（手动备份）、lastsave（查看状态）

结语与下篇预告

本篇我们掌握了RDB快照持久化的配置、手动触发与数据恢复，解决了Redis断电丢数据的痛点。

发表回复