149 lines
7.0 KiB
Markdown
149 lines
7.0 KiB
Markdown
|
---
|
|||
|
|
tags: [test/review, redis, cache-strategy, cache-aside, read-through, write-through]
|
|||
|
|
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
|
|||
|
|
|
|||
|
|
一个日志采集系统有以下需求：
|
|||
|
|
- 每秒接收百万级日志事件，每条都需记录
|
|||
|
|
- 日志数据不需要强一致性，延迟几分钟也可以接受
|
|||
|
|
- 系统必须保证极低的写入延迟以保证高吞吐
|
|||
|
|
- 偶尔丢失少量日志完全可接受
|
|||
|
|
|
|||
|
|
请按决策树思路分析应选择哪种缓存策略，并详细说明你的设计方案（包括如何处理缓存层故障导致的数据丢失风险）。
|
|||
|
|
|
|||
|
|
> **答题框架提示**:
|
|||
|
|
> 1. 根据需求逐层对照决策树
|
|||
|
|
> 2. 对比各策略的延迟和一致性特征
|
|||
|
|
> 3. 针对所选方案的缺陷提出补偿措施
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 参考答案与解析
|
|||
|
|
|
|||
|
|
### 选择题答案
|
|||
|
|
|
|||
|
|
| 题号 | 正确答案 | 解析 |
|
|||
|
|
|------|---------|------|
|
|||
|
|
| 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：**参考答案要点**：
|
|||
|
|
1. 选择 Write Behind 策略。决策思路：日志数据不需要强一致性（否）→ 能否接受写延迟（要极致速度）→ Write Behind。
|
|||
|
|
2. Write Behind 的优势：写操作只写缓存，后台线程异步批量刷盘到 ClickHouse/TimescaleDB，几乎无额外开销。
|
|||
|
|
3. 补偿措施：由于偶尔丢失少量日志可接受，所以 Write Behind 的风险可控。但可以增加 WAL（Write Ahead Log）机制，先将日志写入本地磁盘文件再异步刷盘，即使 crash 也能从本地 WAL 恢复未提交的数据。
|
|||
|
|
4. 批处理优化：后台线程每隔 N 毫秒或积攒 M 条消息后批量刷盘，减少 DB IO 次数。配合监控 unacked 数量和 Queue depth 发现趋势性增长立即扩容。
|
|||
|
|
|
|||
|
|
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖策略选择、优势分析、补偿措施三个维度。
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
- [[03.Redis/strategies/多级缓存架构设计]]
|
|||
|
|
- [[03.Redis/strategies/缓存穿透击穿雪崩解决方案]]
|
|||
|
|
- [[03.Redis/strategies/HeavyKeeper 热点探测算法]]
|