7.0 KiB
tags, create time
| tags | create time | ||||||
|---|---|---|---|---|---|---|---|
|
2026-08-09 12:00 |
旁路缓存与读写策略_测试题
概述
本测试覆盖四种经典的缓存读写策略：Cache Aside、Read Through、Write Through 和 Write Behind。共 10 道题：6 道选择题、3 道填空题、1 道简答题，考察对各自一致性模型、延迟特征和适用场景的理解。
一、选择题（6道，由浅入深）
难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
Q1（基础）— 考察定义层面
在 Cache Aside（旁路缓存）模式中，读操作的默认处理流程是：
A. 应用先写 DB，再从 DB 读取返回 B. 先查缓存，命中直接返回；未命中查 DB 并将结果写入缓存 C. 先查缓存，未命中直接查 DB 不写缓存 D. 直接从 DB 读取并同时通知缓存层刷新
Q2（基础）— 考察行为判断
Cache Aside 模式在写操作时的标准动作是什么？
A. 先更新 DB，再删除缓存 B. 先删除缓存，再更新 DB C. 先更新 DB，再更新缓存为新值 D. 只更新 DB，不操作缓存
Q3（进阶）— 考察核心原理
关于 Write Behind（异步回写）策略，以下哪项描述是正确的？
A. 写操作同时等待缓存和 DB 确认后才返回 B. 写操作只写缓存，由后台线程异步批量刷盘到 DB C. 读操作始终直连 DB，不经过缓存 D. 缓存和 DB 之间通过分布式锁保证强一致
Q4（进阶）— 考察对比辨析
下列哪种缓存策略在一致性保证上最强但在写延迟上最高？
A. Cache Aside —— 最终一致，中等延迟 B. Read Through —— 强一致，miss 时有 DB RTT C. Write Through —— 强一致，写必须同步等 DB 确认 D. Write Behind —— 弱一致，写延迟极低
Q5（深入）— 考察场景推理
某会话管理系统需要将用户的 Session 信息存储在缓存中作为主存储（非持久化存储）。以下哪种策略最合适？
A. Cache Aside，因为简单解耦 B. Write Behind，追求极致写入速度 C. Read Through + Write Through，因为缓存本身就是主存储 D. 直接不用缓存，全部存数据库
Q6（深入）— 考察源码级别细节
在 Go 实现的 Cache Aside 中，为了缓解"写完后 DEL 之前并发读可能把旧值回填缓存"的竞态窗口，可以采用的变体策略是什么？
A. Cache Aside with Delayed Delete：写操作后延时几百毫秒再删缓存 B. 在 DEL 之前加一个 sleep 固定等待 1 秒 C. 改用 Mutex 锁保护整个写操作流程 D. 删除缓存后再手动验证缓存是否真的被删除
二、填空题（3道）
F1 — 填空
在 Write Through 模式下，应用发送写请求后，只有收到 ______ 层的确认才算写入成功，由该层负责同步写入 DB。
提示: 应用的写操作只和一层交互。
F2 — 填空
大多数通用场景的首选缓存策略是 ______ ，因为它简单、解耦、容错好，DB 是权威数据源。
提示: 四个字母的缩写。
F3 — 填空
Write Behind 的风险在于：如果缓存层在尚未刷盘前宕机，该批次数据会 ______ 。
提示: 这是对业务数据安全性的最大威胁。
三、简答题（1道）
S1
一个日志采集系统有以下需求：
- 每秒接收百万级日志事件，每条都需记录
- 日志数据不需要强一致性，延迟几分钟也可以接受
- 系统必须保证极低的写入延迟以保证高吞吐
- 偶尔丢失少量日志完全可接受
请按决策树思路分析应选择哪种缓存策略，并详细说明你的设计方案（包括如何处理缓存层故障导致的数据丢失风险）。
答题框架提示:
- 根据需求逐层对照决策树
- 对比各策略的延迟和一致性特征
- 针对所选方案的缺陷提出补偿措施
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| Q1 | B | Cache Aside 读流程：先看缓存，命中返回；未命中查 DB，并将结果 SET 回缓存（带 TTL）。这是最常见的缓存读写模式。 |
| Q2 | A | Cache Aside 写的标准动作是先更新 DB 再删除缓存。注意不是更新缓存而是删除——下次读取时会从 DB 重建最新值。先删再写的方式存在竞态风险。 |
| Q3 | B | Write Behind 只写缓存，后台线程异步批量刷盘到 DB。特点是极致性能但崩溃丢数据。A 描述的是 Write Through；C 和 D 都与 Write Behind 的设计相反。 |
| Q4 | C | Write Through 写操作必须同步等待 DB 确认后返回，延迟最高但一致性最强——缓存和 DB 之间天然一致。Write Behind 虽然快但一致性弱（异步延迟）；Cache Aside 最终一致。 |
| Q5 | C | Session 本身就是主存储（非持久化），缓存层挂掉需要降级方案。这种情况下应考虑 Read Through + Write Through，因为缓存即主要数据源，Session 的生命周期由缓存管理。 |
| Q6 | A | "Cache Aside with Delayed Delete"是一种变体：写操作后延时几百毫秒再删缓存，可以缓解部分竞态问题。但不适合高一致性要求场景，因为这段时间内缓存仍然可能是旧的。 |
填空题答案
| 题号 | 答案 | 解析 |
|---|---|---|
| F1 | 缓存（CacheLayer） | Write Through 模式下应用只和缓存层交互，不直接接触 DB。缓存层接收到写请求后立即返回 OK（缓存写入成功），然后在内部异步同步到 DB。 |
| F2 | Cache Aside | 面试标准答案——绝大多数场景首选 Cache Aside。它简单、解耦、容错好。只有当架构本身就是"缓存为主存储"时才考虑 Read Through + Write Through。 |
| F3 | 丢失 | Write Behind 的崩溃丢数据风险是最大短板：缓存未刷盘前宕机，该批次数据永远丢失。需要复杂的故障恢复机制，因此只用于能接受短暂数据丢失的非关键场景。 |
简答题参考答案
S1：参考答案要点：
- 选择 Write Behind 策略。决策思路：日志数据不需要强一致性（否）→ 能否接受写延迟（要极致速度）→ Write Behind。
- Write Behind 的优势：写操作只写缓存，后台线程异步批量刷盘到 ClickHouse/TimescaleDB，几乎无额外开销。
- 补偿措施：由于偶尔丢失少量日志可接受，所以 Write Behind 的风险可控。但可以增加 WAL（Write Ahead Log）机制，先将日志写入本地磁盘文件再异步刷盘，即使 crash 也能从本地 WAL 恢复未提交的数据。
- 批处理优化：后台线程每隔 N 毫秒或积攒 M 条消息后批量刷盘，减少 DB IO 次数。配合监控 unacked 数量和 Queue depth 发现趋势性增长立即扩容。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖策略选择、优势分析、补偿措施三个维度。