181 lines
7.1 KiB
JSON
181 lines
7.1 KiB
JSON
{
|
|
"topic": "cache-architecture",
|
|
"type": "fill_blank",
|
|
"schema_version": "1.0.0",
|
|
"generated": "09-2026-09-05T00:00:00+08:00",
|
|
"questions": [
|
|
{
|
|
"id": "fb-001",
|
|
"type": "fill_blank",
|
|
"difficulty": 1,
|
|
"tags": [
|
|
"单机缓存"
|
|
],
|
|
"question": "判断单机应用是否需要引入 Redis 的核心依据不是'是否单机'，而是缓存是否需要被______共享。",
|
|
"answer": [
|
|
"多进程/多个服务"
|
|
],
|
|
"answer_rule": "any",
|
|
"explanation": "决定要不要 Redis 的核心判断是'缓存是否需要被多进程/多能力共享'。单进程应用可用本地缓存；一旦多进程共享缓存，就必须引入 Redis 以保证一致性。常见误判是把'单机'当'单进程'。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-002",
|
|
"type": "fill_blank",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"多进程共享"
|
|
],
|
|
"question": "一台机器上多个进程需要共享缓存时，若各进程持本地副本会彼此不一致，此时应引入______作为独立的共享缓存层。",
|
|
"answer": [
|
|
"Redis"
|
|
],
|
|
"answer_rule": "any",
|
|
"explanation": "多个业务进程同时访问缓存时，进程内本地缓存各持副本必然不一致，应引入 Redis 这类独立进程的缓存服务作为共享层，保证所有进程看到同一份数据。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-003",
|
|
"type": "fill_blank",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"Redis持久化",
|
|
"AOF"
|
|
],
|
|
"question": "在进程重启后缓存不能丢失，且依赖原子自增（INCR）能力的场景下，应选择的缓存组件是______，并结合______持久化保证重启不丢。",
|
|
"answer": [
|
|
"Redis",
|
|
"AOF"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "需要跨进程共享、进程重启不丢且依赖原子计数时，应选 Redis。Redis 通过 AOF（追加日志）或 RDB（快照）持久化；其中 AOF 基于操作日志、重放后数据恢复更完整，符合'重启不丢'的诉求。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-004",
|
|
"type": "fill_blank",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"Write-Behind",
|
|
"回写式缓存"
|
|
],
|
|
"question": "客户端不直接访问 DB，统一读写缓存层，由缓存层异步批量写回 DB，这种架构被称为 Read-Through + ______（回写式缓存 / 懒更新缓存）。",
|
|
"answer": [
|
|
"Write-Behind"
|
|
],
|
|
"answer_rule": "any",
|
|
"explanation": "Write-Behind 也叫回写式缓存或懒更新缓存：写操作只更新缓存，由缓存层异步批量同步到 DB。它带来了异步落库、可批量合并写的优势，但也有丢写风险和外部读到旧值的代价。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-005",
|
|
"type": "fill_blank",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"Write-Behind"
|
|
],
|
|
"question": "Write-Behind 架构下为保证不丢写，缓存必须开启______持久化，并配套兜底日志/队列；为保证批量落库不乱序，需为数据附带______或时间戳。",
|
|
"answer": [
|
|
"AOF",
|
|
"版本号"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "Write-Behind 丢写风险高，缓存必须持久化（AOF）并有兜底日志/队列；批量落库时要带版本号或时间戳，防止旧数据覆盖新数据造成乱序。绝不能把缓存当作唯一真相源。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-006",
|
|
"type": "fill_blank",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"多级缓存"
|
|
],
|
|
"question": "多级缓存（L1 本地 + L2 Redis）副本不一致的常见解法之一是：本地缓存设短 TTL 结合______过期做兜底，或写时通过 MQ ______通知各节点清本地缓存。",
|
|
"answer": [
|
|
"逻辑",
|
|
"广播"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "L1 本地与 L2 Redis 副本不一致是核心难点。缓解手段包括：本地短 TTL + 逻辑过期兜底；主动失效 + MQ 广播通知所有节点清本地缓存；版本号/时间戳判定过期。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-007",
|
|
"type": "fill_blank",
|
|
"difficulty": 2,
|
|
"tags": [
|
|
"Caffeine",
|
|
"TinyLFU"
|
|
],
|
|
"question": "Caffeine 是进程内 JVM 内存缓存，采用______淘汰策略，单次访问纳秒级、无网络开销，适合做 L1 ______热点缓存。",
|
|
"answer": [
|
|
"TinyLFU",
|
|
"极热/高"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "Caffeine 使用 TinyLFU 淘汰策略，能更精确地识别高频热数据；作为进程内内存虽然纳秒级访问，但重启即失、无法跨进程共享，因此适合做 L1 极热/高访问层，与 Redis（L2 共享）搭配成多级缓存。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-008",
|
|
"type": "fill_blank",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"限流",
|
|
"熔断"
|
|
],
|
|
"question": "在缓存降级设计中，当 Redis 抖动不可用时，为防止流量全部回源打爆 DB，应引入本地缓存兜底、配合______、______等保护手段。",
|
|
"answer": [
|
|
"限流",
|
|
"熔断"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "Redis 不可用时应降级而不是无限回源。常用手段包括：本地缓存兜底、限流（限制回源速率）、熔断（快速失败保护后端）、以及返回降级数据。共同目标都是保护 DB 和后端服务免于过载。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-009",
|
|
"type": "fill_blank",
|
|
"difficulty": 4,
|
|
"tags": [
|
|
"哨兵",
|
|
"Redis Cluster"
|
|
],
|
|
"question": "Redis 高可用的两种组成方式：由______负责主从复制的故障检测与自动切换，由______负责数据分片以实现横向扩容。",
|
|
"answer": [
|
|
"哨兵/Sentinel",
|
|
"Redis Cluster"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "哨兵（Sentinel）部署在主从复制之上，监控、故障检测并自动提升换来主从切换，保障高可用；Redis Cluster 按 slot 分片，把数据分发到不同分片实现水平扩展。两者职责互补。",
|
|
"source": null,
|
|
"related": []
|
|
},
|
|
{
|
|
"id": "fb-010",
|
|
"type": "fill_blank",
|
|
"difficulty": 4,
|
|
"tags": [
|
|
"RDB"
|
|
],
|
|
"question": "Redis 提供两种主流持久化方式：______以周期性快照落盘，______则记录每一次写命令，二者可以同时开启。",
|
|
"answer": [
|
|
"RDB",
|
|
"AOF"
|
|
],
|
|
"answer_rule": "ordered",
|
|
"explanation": "RDB（快照）按周期把内存数据整份序列化写入磁盘，恢复快但可能丢失最后一次快照后的数据；AOF 记录每次写命令的追加日志，可重放到最近状态，数据更安全。两者不相斥，生产上可同时开启。",
|
|
"source": null,
|
|
"related": []
|
|
}
|
|
]
|
|
}
|