149 lines
7.1 KiB
Markdown
149 lines
7.1 KiB
Markdown
|
---
|
|||
|
|
tags: [test/review, redis, rdb-aof, persistence, fork, snapshot]
|
|||
|
|
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 <seconds> <changes>。
|
|||
|
|
|
|||
|
|
### F2 — 填空
|
|||
|
|
|
|||
|
|
AOF 重写期间，父进程同时将新的写命令写入一个叫 ______ 的缓冲区，确保重写完成后的数据不会丢失。
|
|||
|
|
|
|||
|
|
> **提示**: 这个缓冲区的名字与其用途直接相关。
|
|||
|
|
|
|||
|
|
### F3 — 填空
|
|||
|
|
|
|||
|
|
当 Redis 内存超过 ______ GB 时，fork 导致的 COW 成本会显著剧增，需要特别注意性能影响。
|
|||
|
|
|
|||
|
|
> **提示**: 这是一个经验阈值。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、简答题（1道）
|
|||
|
|
|
|||
|
|
### S1
|
|||
|
|
|
|||
|
|
一个电商系统的购物车数据存储在 Redis 中，数据特点如下：
|
|||
|
|
- 数据量中等（内存约 3GB），读多写少
|
|||
|
|
- 对数据安全性要求较高，最多允许丢失 1 分钟数据
|
|||
|
|
- 每晚凌晨需要对数据进行冷备份到对象存储
|
|||
|
|
|
|||
|
|
请为该系统设计一套持久化方案，说明具体配置选择及其理由，并解释每层设计如何满足不同需求。
|
|||
|
|
|
|||
|
|
> **答题框架提示**:
|
|||
|
|
> 1. 日常运行的持久化策略选择（AOF vs RDB vs 混合）
|
|||
|
|
> 2. appendfsync 的参数选择依据
|
|||
|
|
> 3. 冷备份的操作方式及注意事项
|
|||
|
|
> 4. 各方案的取舍权衡
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 参考答案与解析
|
|||
|
|
|
|||
|
|
### 选择题答案
|
|||
|
|
|
|||
|
|
| 题号 | 正确答案 | 解析 |
|
|||
|
|
|------|---------|------|
|
|||
|
|
| 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：**参考答案要点**：
|
|||
|
|
1. 日常运行推荐开启混合持久化（aof-use-rdb-preamble yes），兼顾数据安全性和启动恢复速度。大多数互联网公司的标准配置。
|
|||
|
|
2. appendfsync 设置为 everysec（默认值），在性能和安全性之间取得平衡——最多丢 1 秒数据，系统调用开销仅约 1ms。
|
|||
|
|
3. 冷备策略：每天凌晨通过 BGSAVE 生成 dump.rdb 后上传到 OSS/S3。注意 SAVE 是阻塞命令，不要在高峰期执行，应使用 BGSAVE 后台执行后再复制文件。
|
|||
|
|
4. 对于 3GB 数据量，fork COW 成本可控，无需拆分实例。但可以监控 last_bgsave_status 确认健康度。
|
|||
|
|
|
|||
|
|
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点及各方案的取舍分析。
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
- [[03.Redis/core/Redis 五大核心数据结构]]
|
|||
|
|
- [[03.Redis/core/集群与哨兵机制]]
|
|||
|
|
- [[03.Redis/strategies/多级缓存架构设计]]
|