凌晨两点，订单服务突然报错，缓存节点重启后数据回退，流量直接打到数据库。我是老李，一个长期跟缓存和数据库打交道的后端。很多团队把 Redis 当“有就加速、没有就查库”的缓存，直到容器被 kill、节点故障，才发现持久化配置是个盲区。为什么现在要讲？因为 Redis 的持久化能力已经不只 RDB 和 AOF 两种老面孔，8.10 新增的 BACKUP 能力，把节点侧备份恢复这件事拉回了主流程。今天我们把 RDB、AOF、混合持久化和 BACKUP 放到一起，从原理打到恢复演练。

## 01、痛点

第一类问题：Redis 被当成纯缓存，不做任何持久化。平时跑得飞快，一旦容器被 kill、宿主机重启或主从切换，内存里的数据全部归零，冷启动后缓存击穿，数据库压力瞬间拉满。

第二类问题：知道要开 AOF，但以为开了 AOF 就绝对不会丢数据。实际上 AOF 的刷盘策略决定了丢失窗口，appendfsync everysec 最多可能丢约一秒的写操作，always 能更接近不丢但性能会明显下降。

第三类问题：只用 RDB 做持久化，却忽略了保存间隔。默认 save 900 1 意味着十五分钟内至少有一次写才触发快照，如果写频率不高，最后一次快照之后的数据可能全部没有。

第四类问题：容器化部署时，配置文件里明明写了持久化，但数据目录没有挂载出来，docker kill 一执行，容器一重建，旧文件跟着容器一起消失。

第五类问题：备份文件长期存在，但从来没有做过恢复演练。真到故障要恢复时，不知道先看哪个文件、不知道怎么校验一致性、不知道新节点能不能起来。

这些问题的本质，其实都不是不会用 Redis，而是没有理解持久化机制的代价和边界。

## 02、是什么

RDB 是 Redis 的全量快照机制。它把某一时刻的内存数据集序列化成二进制文件，默认文件是 dump.rdb。触发方式可以是手动执行 SAVE 或 BGSAVE，也可以配置 save 参数按写入次数自动触发。

AOF 是追加写日志。Redis 每收到一条写命令，就会把它追加到 AOF 文件尾部。恢复时从文件头到尾重放命令，重建内存数据。AOF 提供 appendfsync 参数控制刷盘节奏：always 每条命令刷盘，everysec 每秒刷盘，no 交给操作系统。

混合持久化是 RDB 和 AOF 的结合。开启 aof-use-rdb-preamble yes 之后，AOF 文件的前半部分是一个 RDB 格式的全量快照，后半部分是快照之后的 AOF 增量命令。这样恢复时先加载快照，再重放少量增量，速度快很多。

Redis 8.10 新增的 BACKUP 能力，是基于 multi-part AOF 实现的节点侧备份恢复。multi-part AOF 把传统的单文件 AOF 拆成多个部分：一块基础文件、若干增量文件，再加上一个 manifest 清单记录这些文件的顺序和元信息。BACKUP 利用这个结构，在节点侧生成一个一致性备份点，复制或硬链接相关文件到备份目录。它更像是持久化体系上的一层原生备份入口，而不是替代 RDB 或 AOF。

## 03、为什么

先说 RDB 的恢复速度与数据窗口。RDB 文件是紧凑的二进制快照，加载时不需要逐条回放命令，所以恢复速度通常远快于 AOF。但代价是数据窗口。如果只靠自动 save，且间隔较大，那么从上次快照到故障点之间的写入都会丢。手动 BGSAVE 可以缩小窗口，但执行频率太高又会引入 fork 开销。

再说 AOF 的完整性与写放大。AOF 记录每一次写命令，完整性比 RDB 好得多。然而写放大也很明显：同一条数据可能被反复修改，AOF 中会留下大量中间状态。随着时间增长，文件越来越大，恢复时间越来越长，还会占用更多磁盘。为了压缩文件，Redis 会进行 AOF Rewrite。

理解 fork 和 COW 是理解延迟影响的关键。BGSAVE 和 AOF Rewrite 都会让主进程 fork 一个子进程。子进程共享父进程的内存页表，父进程继续处理写请求时，被修改的内存页会触发 COW，即写时复制。内存越大，页表越大，fork 本身耗时越长；写负载越高，COW 复制的页越多，可能造成额外的内存占用和延迟抖动。这是很多线上 Redis 每隔一段时间就出现毫秒级尖刺的原因。

AOF Rewrite 并不是重放旧日志。子进程会基于当前内存数据，直接生成一个能重建当前数据集的最小命令集合。主进程在重写期间的新写命令，会被写入一个重写缓冲区，等子进程完成后再追加到新 AOF 文件末尾，最后原子替换旧文件。这个过程虽然不阻塞主进程，但 fork、COW、磁盘 I/O 都会带来成本。

为什么 8.10 要引入 BACKUP 能力？因为 multi-part AOF 出现后，持久化目录下不再只有一个文件。base、incr、manifest 多个文件如果靠人工脚本复制，很容易出现文件不齐、顺序错乱或备份到中间态的问题。BACKUP 在节点侧直接识别 manifest，按清单生成一致性备份，能显著降低运维失误。

Spring Boot 业务代码不需要直接实现持久化，但开发者和运维都要理解它。比如 Lettuce 连接池的命令超时设置得太短，遇到 fork 或 Rewrite 导致的毫秒级阻塞，就可能误判 Redis 不可用，触发重试甚至熔断。集群模式下，拓扑刷新和主从切换期间，如果持久化恢复时间过长，也会放大上游超时。

## 04、架构

从进程和文件的角度看，Redis 持久化架构可以分成三条线。

RDB 线：主进程根据 save 配置或手动命令触发 BGSAVE，fork 出子进程。子进程读取自己的内存视图，把数据写入临时 RDB 文件，完成后原子替换 dump.rdb。父进程写操作触发的 COW 只会复制被修改的页，不会整体复制内存。

AOF 线：主进程把写命令写入 AOF 缓冲区，再根据 appendfsync 策略刷到 AOF 文件。Rewrite 时 fork 子进程，子进程生成新的 AOF 文件，主进程把重写期间的增量写入重写缓冲区。子进程完成后，主进程把重写缓冲区追加到新文件末尾，再用新文件替换旧文件。

multi-part AOF 线：AOF 不再是单文件，而是用 manifest 管理一组文件。base 文件保存基础数据，incr 文件保存后续增量，manifest 记录文件顺序、类型和校验信息。重写时会生成新的 base 文件，旧 incr 文件可以被清理。这样做的优点是重写粒度更细，备份和恢复的边界更清楚。

BACKUP 架构：节点根据 manifest 找到完整的 AOF 文件集合，将它们复制或硬链接到指定备份目录，同时写入备份元数据。恢复时，节点读取备份目录中的 manifest，按顺序加载 base 和 incr 文件，重建数据。相比外部工具拷贝单个 AOF 文件，这样做更容易保证一致性。

Spring Boot 视角下，持久化对业务的影响主要体现在延迟和恢复上。连接池无需关心 RDB 和 AOF 的具体实现，但需要为可能出现的 fork 停顿、Rewrite I/O 尖峰留出合理的超时余量。业务侧的重试策略也要考虑缓存恢复期间可能短暂不可用，避免重试风暴。

## 05、实战

为了把原理落到地上，我用 Docker 分别跑 RDB、AOF 和混合持久化，然后模拟容器被杀后的恢复。

先启动一个只开 RDB 的容器：
```
docker run -d --name redis-rdb -p 6379:6379 redis:7.2 redis-server --appendonly no --save 900 1 --save 300 10 --save 60 10000
```

写入两条数据，第一条之后执行 BGSAVE 生成快照，第二条刻意不触发新的保存条件：
```
docker exec redis-rdb redis-cli set k1 v1
docker exec redis-rdb redis-cli bgsave
docker exec redis-rdb redis-cli set k2 v2
docker kill redis-rdb
docker start redis-rdb
docker exec redis-rdb redis-cli get k2
```

你会看到 k2 大概率返回空。因为 k2 是在最近一次 BGSAVE 之后写入的，RDB 文件里没有它，容器重启后数据窗口内的写入就丢了。如果 k2 还能读到，说明在 kill 前恰好又触发了保存条件，这是运气。

再测 AOF。启动一个开 AOF 的容器：
```
docker run -d --name redis-aof -p 6380:6379 redis:7.2 redis-server --appendonly yes --appendfsync everysec
```

写入数据后立即 kill：
```
docker exec redis-aof redis-cli set k1 v1
docker exec redis-aof redis-cli set k2 v2
docker kill redis-aof
docker start redis-aof
docker exec redis-aof redis-cli get k2
```

在 everysec 策略下，k2 大概率能恢复，但如果你在 Redis 写入后的一秒内立刻杀掉进程，最后一条命令可能还没刷到磁盘。换句话说，AOF 开启绝不等于零丢失。

混合持久化测试也可以快速做一遍。在 AOF 容器上增加 aof-use-rdb-preamble yes，重启后写入数据，观察 AOF 文件头部会出现 REDIS 字样，后面跟 RDB 快照和增量命令：
```
docker exec redis-aof redis-cli config set aof-use-rdb-preamble yes
docker exec redis-aof redis-cli config rewrite
```

最后做一次备份恢复演练。这里以 8.10 的 BACKUP 能力为例，假设节点已经开启 multi-part AOF。执行节点侧备份命令，将一致性备份生成到指定目录：
```
docker exec redis-810 redis-cli backup create /data/backup/redis-backup-20250601
```

然后模拟节点损坏，启动一个新容器，把备份目录挂载进去，并指向备份数据目录启动 Redis：
```
docker run -d --name redis-restore -v /data/backup/redis-backup-20250601:/data redis:8.10 redis-server --appendonly yes --multi-part-aof yes
```

恢复后检查数据量和业务键：
```
docker exec redis-restore redis-cli dbsize
docker exec redis-restore redis-cli get k1
```

演练中最容易暴露的问题不是命令不对，而是备份目录未挂载、manifest 文件缺失、文件权限不对、恢复后业务没有全链路验证。定期演练的价值就在这。

## 06、洞见

持久化不是零成本开关，而是在恢复速度、数据完整性、写入延迟之间做选择。RDB 适合冷备和快速恢复，但数据窗口最大；AOF 适合高完整性场景，但写放大和恢复成本高；混合持久化在大多数业务里是最稳妥的默认项。

8.10 的 BACKUP 能力让节点侧备份从外围脚本变成原生能力。它依赖 multi-part AOF 的 manifest，把一个模糊的“备份 AOF 文件”动作变成了“按清单生成一致性备份”。这背后的变化是，备份不再依赖人对文件的理解，而依赖节点自身对持久化结构的理解。

容器环境会放大持久化配置的错误。Redis 配置写在容器里，文件写在容器里，但数据目录没有挂载到宿主机或命名卷，容器一删，持久化就成了空谈。容器化部署必须把数据目录和备份目录显式管理起来。

Spring Boot 开发者不需要写持久化代码，但要理解 fork、COW、Rewrite 这些机制带来的延迟波动。否则遇到偶发慢查询，很难定位是业务问题还是 Redis 持久化引起的尖刺。

最后回答测验：Redis 开启 AOF 就绝对不会丢数据吗？答案是否定的。appendfsync everysec 最多会丢约一秒的数据；always 能进一步降低丢失概率，但受限于操作系统和磁盘，也有极端的写入确认问题。再加上主从异步复制，即使主节点 AOF 开启，从节点也可能没有同步到最新写入。真正的数据不丢，需要在主从、持久化、磁盘落盘、业务确认多个层面一起设计。

## 07、行动

今天就可以做四件事。第一，检查现有 Redis 实例的 appendonly、save、appendfsync、aof-use-rdb-preamble 配置，确认恢复时间目标和可接受丢失窗口。第二，对核心业务至少开启混合持久化，appendfsync everysec，并配置好数据目录挂载。第三，给 BGSAVE、AOF Rewrite 加监控，关注 fork 耗时、内存使用、磁盘 I/O 和重写失败。第四，至少每季度做一次备份恢复演练，包括 RDB 恢复和 multi-part AOF 或 BACKUP 恢复，验证 keys 数量和业务读写。

如果计划升级到 Redis 8.10，先在测试环境验证 BACKUP 能力。重点看它能否替代现有备份脚本，恢复流程是否简化，以及 manifest 文件在变更时是否稳定。

## 08、小结

从会用缓存到进入 Redis 运维世界，分水岭就是持久化。RDB 恢复快但数据窗口大，AOF 完整但有写放大，混合持久化是平衡，8.10 的 BACKUP 基于 multi-part AOF 提供节点侧备份恢复。理解 fork、COW 和 AOF Rewrite，才能不被偶发延迟吓到。把配置、监控、演练做扎实，才能让缓存真正成为稳定层，而不是隐藏的故障源。

## 09、链接与概念说明

RDB：Redis Database，全量二进制快照。
AOF：Append Only File，追加写日志。
fork：操作系统创建子进程的能力，Redis 用于后台保存和重写。
COW：Copy On Write，写时复制，子进程与父进程共享内存页直到写入发生。
AOF Rewrite：AOF 重写，根据当前内存数据生成最小命令集。
multi-part AOF：多部分 AOF，由 base、incr 和 manifest 组成。
BACKUP：Redis 8.10 新增的节点侧备份恢复能力。
建议进一步查阅 Redis 官方文档中 persistence、backup 和 multi-part AOF 相关章节，并关注版本发布说明中对恢复流程的更新。

凌晨两点，订单服务突然报错，缓存节点重启后数据回退，流量直接打到数据库。我是老李，一个长期跟缓存和数据库打交道的后端。很多团队把 Redis 当“有就加速、没有就查库”的缓存，直到容器被 kill、节点故障，才发现持久化配置是个盲区。为什么现在要讲？因为 Redis 的持久化能力已经不只 RDB 和 AOF 两种老面孔，8.10 新增的 BACKUP 能力，把节点侧备份恢复这件事拉回了主流程。今天我们把 RDB、AOF、混合持久化和 BACKUP 放到一起，从原理打到恢复演练。

《Redis 8.10 + Spring Boot 实战》第11招 持久化——Redis 在内存里，为什么重启之后数据还能回来

从 RDB、AOF 到混合持久化，再到 Redis 8.10 基于 multi-part AOF 的 BACKUP 能力，结合容器恢复演练，讲清数据窗口、写放大

架构师

数据库

后端

运维

Redis持久化全解析：RDB快照恢复快但易丢数据，AOF完整但写放大明显，混合持久化是业务稳妥默认项。8.10新增BACKUP基于multi-partAOF实现节点侧一致性备份。容器部署需挂载数据目录，定期演练恢复流程，关注fork与COW导致的延迟尖刺，配置appendfsync策略控制丢失窗口。

数据完整性

代码解释

容器

Redis

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第11招 持久化——Redis 在内存里，为什么重启之后数据还能回来-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第11招持久化——Redis 在内存里，为什么重启之后数据还能回来

《Redis 8.10 + Spring Boot 实战》第11招持久化——Redis 在内存里，为什么重启之后数据还能回来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第11招 持久化——Redis 在内存里，为什么重启之后数据还能回来

《Redis 8.10 + Spring Boot 实战》第11招 持久化——Redis 在内存里，为什么重启之后数据还能回来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第11招持久化——Redis 在内存里，为什么重启之后数据还能回来

《Redis 8.10 + Spring Boot 实战》第11招持久化——Redis 在内存里，为什么重启之后数据还能回来