7.1 KiB
tags, create time
| tags | create time | ||||||
|---|---|---|---|---|---|---|---|
|
2026-08-09 12:00 |
RDB与AOF持久化_测试题
概述
本测试覆盖 Redis 的 RDB 快照、AOF 追加日志以及混合持久化三种方案。共 10 道题：6 道选择题、3 道填空题、1 道简答题，考察对 fork 机制、COW 开销、重写原理及选型策略的理解。
一、选择题（6道，由浅入深）
难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
Q1（基础）— 考察定义层面
Redis 的 BGSAVE 命令触发 RDB 持久化的核心步骤中，哪一步是造成内存峰值的关键因素？
A. 子进程遍历内存数据结构写入临时文件 B. fork 子进程时操作系统复制被修改的内存页（Copy-On-Write） C. 将临时文件 mv 替换为 dump.rdb D. 主进程继续处理客户端写请求
Q2（基础）— 考察行为判断
在 AOF 的三种 appendfsync 策略中，哪一种会在每次写命令执行后都调用一次操作系统 fsync 系统调用？
A. always B. everysec C. no D. 自动触发模式
Q3（进阶）— 考察核心原理
RDB 文件采用压缩二进制格式存储。关于其特性，以下说法正确的是：
A. RDB 文件是纯文本格式，可以直接用 text editor 查看和编辑 B. RDB 文件在不同 Redis 版本之间完全兼容，可以跨版本还原 C. RDB 是无损压缩的二进制格式，但不同版本间不兼容 D. RDB 只保存过期 key 的数据，跳过已失效的数据
Q4（进阶）— 考察对比辨析
AOF 重写（Rewrite）过程中，子进程序列化数据的方式是：
A. 读取旧的 AOF 文件，去除重复命令后写入新文件 B. 遍历当前内存数据，将每个 key 用 SET 命令逐条序列化 C. 读取 RDB 快照文件并转换为 AOF 格式 D. 直接从数据库查询最新数据然后序列化
Q5（深入）— 考察场景推理
某 Redis 实例内存使用量约为 12GB，每次 BGSAVE 时 COW 导致额外占用约 500MB，持续数秒。运维同学希望在不停机的情况下降低 BGSAVE 期间的内存峰值。以下哪种方案最有效？
A. 增大 save 时间窗口减少触发频率
B. 改用 appendfsync no 策略关闭持久化
C. 开启混合持久化并将业务拆分到多个实例
D. 增加 maxmemory 配置以提供更大的内存池
Q6（深入）— 考察源码级别细节
混合持久化（Hybrid Persistence）的文件结构是怎样的？
A. 前半部分是 AOF 文本指令，后半部分是 RDB 二进制快照 B. 前半部分是 RDB 全量快照，后半部分是 fork 时刻之后的增量 AOF 命令 C. RDB 和 AOF 完全独立，分别存储在两个文件中 D. 随机分布，RDB 部分和 AOF 部分交错排列
二、填空题（3道）
F1 — 填空
save 900 1 的含义是：在 900 秒内有至少 ______ 个 key 被修改，则自动触发 BGSAVE 快照。
提示: 语法为 save 。
F2 — 填空
AOF 重写期间，父进程同时将新的写命令写入一个叫 ______ 的缓冲区，确保重写完成后的数据不会丢失。
提示: 这个缓冲区的名字与其用途直接相关。
F3 — 填空
当 Redis 内存超过 ______ GB 时，fork 导致的 COW 成本会显著剧增，需要特别注意性能影响。
提示: 这是一个经验阈值。
三、简答题（1道）
S1
一个电商系统的购物车数据存储在 Redis 中，数据特点如下：
- 数据量中等（内存约 3GB），读多写少
- 对数据安全性要求较高，最多允许丢失 1 分钟数据
- 每晚凌晨需要对数据进行冷备份到对象存储
请为该系统设计一套持久化方案，说明具体配置选择及其理由，并解释每层设计如何满足不同需求。
答题框架提示:
- 日常运行的持久化策略选择（AOF vs RDB vs 混合）
- appendfsync 的参数选择依据
- 冷备份的操作方式及注意事项
- 各方案的取舍权衡
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| Q1 | B | fork 瞬间父子进程共享内存页，当父进程修改某页时操作系统会复制该页给子进程使用（Copy-On-Write）。这意味着 RDB 过程中的内存峰值 = 当前内存 + fork 瞬间的增量变化量。其他选项虽然是流程的一部分但不是造成峰值的原因。 |
| Q2 | A | always 策略每条命令执行完就 fsync，等同于 MySQL innodb_flush_log_at_trx_commit=1，最安全但性能最差。everysec 每秒一次，no 由 OS 决定刷新时机。 |
| Q3 | C | RDB 是无损压缩的二进制格式，空间效率高，但不同 Redis 版本间的 RDB 文件不兼容，不能跨版本还原。 |
| Q4 | B | AOF 重写不是简单地删旧写新，而是 fork 子进程后直接遍历当前内存数据，将每个 key 用 SET 命令序列化。这比读取旧 AOF 更高效，因为去除了已过期 key 的记录。 |
| Q5 | C | 12GB 已经超过了 10GB 的经验阈值，fork 的 COW 成本会非常可观。混合持久化可以加快启动恢复速度，拆分实例可以避免单次 fork 过大的开销。A 只能减少触发频率但不能降低单次成本；B 会牺牲数据安全；D 治标不治本。 |
| Q6 | B | 混合持久化 = RDB 全量快照（前半部分）+ 增量 AOF 命令（后半部分）。RDB 部分保证从 fork 时刻的完整状态，AOF 部分保证增量不丢，兼顾了启动速度和数据安全性。 |
填空题答案
| 题号 | 答案 | 解析 |
|---|---|---|
| F1 | 1 | save 900 1 表示 900 秒内至少有 1 个 key 变更就触发快照。这是 Redis 默认的自动触发规则之一（通常搭配 save 300 10 和 save 60 10000 形成三级触发体系）。 |
| F2 | aof_rewrite_buffer | AOF 重写期间旧 AOF 保持不变，子进程生成新文件的同时父进程把新写命令累积到 aof_rewrite_buffer 中，合并后原子替换原 AOF 文件，确保零丢失。 |
| F3 | 10 | 当内存超过 10GB 时，fork 导致 COW 成本剧增。此时应考虑增大 AOF 重写阈值或将业务拆分到多实例，避免单次 fork 过大的内存开销。 |
简答题参考答案
S1：参考答案要点：
- 日常运行推荐开启混合持久化（aof-use-rdb-preamble yes），兼顾数据安全性和启动恢复速度。大多数互联网公司的标准配置。
- appendfsync 设置为 everysec（默认值），在性能和安全性之间取得平衡——最多丢 1 秒数据，系统调用开销仅约 1ms。
- 冷备策略：每天凌晨通过 BGSAVE 生成 dump.rdb 后上传到 OSS/S3。注意 SAVE 是阻塞命令，不要在高峰期执行，应使用 BGSAVE 后台执行后再复制文件。
- 对于 3GB 数据量，fork COW 成本可控，无需拆分实例。但可以监控 last_bgsave_status 确认健康度。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点及各方案的取舍分析。