210 lines
9.4 KiB
JSON
210 lines
9.4 KiB
JSON
{
|
|
"topic": "cache-three-problems",
|
|
"type": "single_choice",
|
|
"schema_version": "1.0.0",
|
|
"generated": "2026-09-05T00:00:00+08:00",
|
|
"questions": [
|
|
{
|
|
"id": "sc-001",
|
|
"type": "single_choice",
|
|
"difficulty": 1,
|
|
"tags": [
|
|
"缓存穿透"
|
|
],
|
|
"question": "「缓存穿透」的本质与下列哪种情况最匹配？",
|
|
"options": {
|
|
"A": "查询数据库中存在但缓存中不存在的数据",
|
|
"B": "查询数据库中也根本不存在的数据，每次请求都直达数据库",
|
|
"C": "单个热点 key 刚好过期导致大量请求同时打数据库",
|
|
"D": "大批量 key 在同一时刻集体失效"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "缓存穿透指查询一个数据库中也【不存在】的数据。缓存查不到、DB 也查不到，无法写回缓存，导致每一次请求都直达 DB。选项 A 属于正常缓存未命中可回源；C 是缓存击穿；D 是缓存雪崩。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-002",
|
|
"type": "single_choice",
|
|
"difficulty": 1,
|
|
"tags": [
|
|
"缓存雪崩"
|
|
],
|
|
"question": "「缓存雪崩」的典型特征是？",
|
|
"options": {
|
|
"A": "单个热点 key 过期导致的高并发尖峰",
|
|
"B": "查询不存在的数据导致持续打到数据库",
|
|
"C": "大批 key 同时过期或整台缓存服务宕机，瞬间请求全部穿透到数据库",
|
|
"D": "布隆过滤器误判导致正常请求被拦截"
|
|
},
|
|
"answer": "C",
|
|
"explanation": "缓存雪崩的特征是【多 key、集中失效、集体崩溃】：一大批 key 在同一时刻集体失效（如同期设置了相同过期时间），或整台缓存服务宕机，导致瞬间所有请求穿透到 DB。选项 A 是击穿，B 是穿透，D 是布隆过滤器的副作用。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-003",
|
|
"type": "single_choice",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"缓存击穿",
|
|
"热点key"
|
|
],
|
|
"question": "某个微博热搜 key 缓存恰好过期，瞬时大量请求同时回源打数据库，这属于哪种问题？",
|
|
"options": {
|
|
"A": "缓存穿透",
|
|
"B": "缓存击穿",
|
|
"C": "缓存雪崩",
|
|
"D": "缓存一致性问题"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "该场景是【单个特别热门的 key】缓存过期，此刻大量请求同时来全部 miss、同时打 DB。特点是单 key、高并发、瞬时尖峰，正符合缓存击穿的定义。穿透针对不存在的 key，雪崩针对多 key 集体失效，一致性问题与本题无关。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-004",
|
|
"type": "single_choice",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"缓存穿透",
|
|
"布隆过滤器"
|
|
],
|
|
"question": "关于布隆过滤器判断数据「是否存在」，下列说法正确的是？",
|
|
"options": {
|
|
"A": "判断不存在时，数据可能实际存在",
|
|
"B": "判断不存在时，数据一定不存在",
|
|
"C": "判断存在时，数据一定存在",
|
|
"D": "不支持删除，因此只能用于处理缓存击穿"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "布隆过滤器不存在假阴性：判断为「不存在」则一定不存在。存在假阳性：判断为「存在」时可能实际不存在。选项 C 错误（存在→可能存在），选项 A 描述的是假阳性而非不存在，选项 D 布隆过滤器是解决穿透的方案而非击穿。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-005",
|
|
"type": "single_choice",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"缓存穿透",
|
|
"缓存空对象"
|
|
],
|
|
"question": "使用「缓存空对象」方案解决缓存穿透时，下列说法错误的是？",
|
|
"options": {
|
|
"A": "数据库查不到时，也缓存一个 null 值并设置较短的 TTL",
|
|
"B": "可以有效防止对同一个不存在 key 的反复穿透",
|
|
"C": "大量不同的空 key 都会占满内存，存在内存被写满的风险",
|
|
"D": "空值对象应该设置与正常数据相同甚至更长的 TTL"
|
|
},
|
|
"answer": "D",
|
|
"explanation": "缓存空对象应设置【极短 TTL】（如 5 分钟），防止大量空 key 长期占用内存，而不是设置相同或更长的 TTL。A、B 正确描述了原理，C 正确指出了空值缓存的主要内存风险，故错误的选项是 D。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-006",
|
|
"type": "single_choice",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"缓存击穿",
|
|
"互斥锁",
|
|
"SETNX"
|
|
],
|
|
"question": "使用 Redis SETNX 实现互斥锁解决缓存击穿时，只有抢到锁的请求才能回源数据库，它的核心作用是？",
|
|
"options": {
|
|
"A": "让所有请求都穿透到数据库以加快数据同步",
|
|
"B": "保证只有一个线程去查库回填缓存，其余请求等待或降级",
|
|
"C": "把锁上的请求直接丢弃以减少数据库压力",
|
|
"D": "用于给缓存 key 设置统一的过期时间"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "互斥锁保证同一时刻只有一个请求能去查 DB 并回填缓存，其他请求阻塞等待或返回旧值，从而避免雪崩式地打 DB。A、C 与思路相悖，D 与过期时间无关。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-007",
|
|
"type": "single_choice",
|
|
"difficulty": 4,
|
|
"tags": [
|
|
"缓存雪崩",
|
|
"TTL加随机"
|
|
],
|
|
"question": "为防止缓存雪崩，给大量缓存 key 的 TTL 增加随机偏差（如 60+random(0~300) 秒）能达到什么效果？",
|
|
"options": {
|
|
"A": "让所有 key 在同时到期，保证数据最新",
|
|
"B": "把到期时间打散，避免一批 key 在同一时刻集体失效",
|
|
"C": "彻底消除缓存过期，让数据永不失效",
|
|
"D": "减少缓存换取流量，降低服务器带宽消耗"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "给每个 key 的 TTL 加随机偏差可以把到期时刻分散开，避免一大批复集中在同一时刻失效触发雪崩。A、C 与目标相反，D 与带宽无关。加随机是雪崩最直接有效的兜底手段之一。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-008",
|
|
"type": "single_choice",
|
|
"difficulty": 4,
|
|
"tags": [
|
|
"缓存击穿",
|
|
"逻辑过期"
|
|
],
|
|
"question": "关于「逻辑过期」解决缓存击穿的方案，下列说法正确的是？",
|
|
"options": {
|
|
"A": "到逻辑过期时间就立即物理删除缓存里的 key",
|
|
"B": "不真正删除缓存，缓存到期后由异步线程后台更新，数据保持持续可用",
|
|
"C": "逻辑过期会增加 DB 的瞬时并发压力",
|
|
"D": "逻辑过期是专门用来解决缓存穿透的方案"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "逻辑过期不删除 key，而是在 value 中记录逻辑过期时间，允许返回旧值或标记过期后由后台异步线程刷新，从而挡住并发的瞬时冲击。A 是物理丢弃，C 与 B 的异步刷新理念相悖，D 它是解决击穿的方案。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-009",
|
|
"type": "single_choice",
|
|
"difficulty": 5,
|
|
"tags": [
|
|
"缓存穿透",
|
|
"参数校验",
|
|
"布隆过滤器"
|
|
],
|
|
"question": "某系统收到大量针对「不存在 userId」的请求，为在【不合法参数被鉴权】之前、从入口处优先拦截绝大多数非法请求，最直接的做法是？",
|
|
"options": {
|
|
"A": "直接返回数据库全表数据给客户端",
|
|
"B": "对所有请求做参数校验，在入口拦截非法参数与不存在数据",
|
|
"C": "给数据库添加唯一约束",
|
|
"D": "把所有请求都用 SETNX 加锁串行化"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "参数校验是穿透的第一道防线：在入口处拦截非法参数、明显不存在的请求，避免其打到 DB。A 会雪上加霜，C 是数据库层措施但不防穿透，D 的加锁是为击穿而设且无法区分合法不存在的 key。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "sc-010",
|
|
"type": "single_choice",
|
|
"difficulty": 5,
|
|
"tags": [
|
|
"多级缓存",
|
|
"Redis高可用",
|
|
"缓存雪崩"
|
|
],
|
|
"question": "以下属于「缓存雪崩」完整治理组合方案的是？",
|
|
"options": {
|
|
"A": "仅设置：对所有 key 采用永久不过期",
|
|
"B": "过期时间加随机值 + 多级缓存（本地/Redis/DB 兜底）+ 限流熔断降级 + Redis 主从/集群高可用",
|
|
"C": "只使用布隆过滤器拦截不存在的 key",
|
|
"D": "只采用互斥锁让单 key 回源串行"
|
|
},
|
|
"answer": "B",
|
|
"explanation": "雪崩是多 key 集体失效 + 服务宕机的双重风险，治理需要组合：TTL 加随机打散失效时间、多级缓存层层兜底、加锁/限流/熔断降级保护 DB、Redis 主从哨兵集群保证高可用。A 永不失效既不现实也不能防宕机，C 针对穿透，D 针对单 key 击穿而非成批雪崩。",
|
|
"source": null,
|
|
"related": []
|
|
}
|
|
]
|
|
}
|