205 lines
10 KiB
JSON
205 lines
10 KiB
JSON
{
|
||
"topic": "cache-architecture",
|
||
"type": "single_choice",
|
||
"schema_version": "1.0.0",
|
||
"generated": "09-2026-09-05T00:00:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "sc-001",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"单机缓存"
|
||
],
|
||
"question": "一台机器上运行着多个独立的业务进程，各进程需要共享同一份热点数据缓存。此时关于是否需要引入 Redis，下列说法正确的是？",
|
||
"options": {
|
||
"A": "因为部署在一台机器上，用进程内 Caffeine 即可，无需 Redis",
|
||
"B": "只要数据能被重启后重新加载，就绝不该用 Redis",
|
||
"C": "缓存需要跨进程共享，进程内本地缓存会各自持有副本导致不一致，应引入 Redis",
|
||
"D": "单机场景下 Redis 会因为网络开销绝对劣于本地缓存"
|
||
},
|
||
"answer": "C",
|
||
"explanation": "决定是否用 Redis 的关键不是'单机'而是'缓存是否需要被多进程/多能力共享'。多进程部署时每个进程各持一份本地缓存的副本会彼此不一致，因此需要引入 Redis 作为共享缓存层。单机不等于单进程，A 把'单机'误当'单进程'。B 忽略了跨进程共享的需求。D 中 Redis 在网络开销上高于本地缓存，但在跨进程共享场景下是必要的，不能说'绝对劣于'。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-002",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"单机缓存"
|
||
],
|
||
"question": "一个单进程应用，缓存数据可以随时重启后从 DB 重新加载，也不依赖任何 Redis 特性。下列最合理的做法是？",
|
||
"options": {
|
||
"A": "接入 Redis，保证缓存能被其他进程共享",
|
||
"B": "直接使用进程内本地缓存（如 Caffeine），不加 Redis",
|
||
"C": "必须同时使用本地缓存和 Redis 两层缓存",
|
||
"D": "放弃缓存，所有请求直连 DB"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "判断三问：①缓存是否被多进程共享？否；②依赖 Redis 某项能力（可持久化、分布式锁、原子计数等）？否；③数据量本地扛不住？否。三条都'否'，说明本地缓存足够，加 Redis 反而引入一层网络与一致性麻烦，属于多余。因此直接用进程内本地缓存即可。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-003",
|
||
"type": "single_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"多进程共享",
|
||
"Redis持久化"
|
||
],
|
||
"question": "某系统需要：缓存跨多个进程共享、进程重启后缓存不丢失、支持分布式锁与原子自增。针对该需求，下列说法正确的是？",
|
||
"options": {
|
||
"A": "用进程内 Caffeine 即可满足全部需求",
|
||
"B": "必须引入 Redis，因为它支持共享、AOF 持久化、分布式锁和原子计数",
|
||
"C": "只要本地缓存设置足够大的容量就能解决",
|
||
"D": "跨进程共享和持久化互斥，无法同时满足"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "该需求命中判断三问中的①②：需要跨进程共享、且依赖 Redis 特性。Redis 独立于进程、支持 AOF/RDB 持久化，原生支持分布式锁（SETNX/Redlock）、原子计数（INCR）、榜单（ZSET）、PubSub，因此必须引入 Redis。Caffeine 是进程内内存，无法跨进程共享、无法在进程崩溃后保留数据，故 A、C 错误。共享与持久化并不互斥，D 错误。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-004",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"多级缓存"
|
||
],
|
||
"question": "在多级缓存架构中，客户端完全不直接访问 DB，统一通过缓存层读写，并由缓存层异步地把写入批量同步回 DB。这种架构被称为？",
|
||
"options": {
|
||
"A": "Cache-Aside（旁路缓存）",
|
||
"B": "Read-Through + Write-Behind（回写式缓存）",
|
||
"C": "Cache-Aside + 同步写库",
|
||
"D": "直写缓存（Write-Through）"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "Read-Through 指程序只读缓存，缓存缺失时由缓存层负责回源加载；Write-Behind（回写式/懒更新缓存）指写操作只写入缓存，由缓存层异步批量写回 DB。两者结合即为'客户端只读写缓存+异步落库'的架构。Write-Through 是同步写入库，与题目'异步批量'不符。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-005",
|
||
"type": "single_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"Write-Behind",
|
||
"回写式缓存"
|
||
],
|
||
"question": "采用 Write-Behind 回写式缓存架构时，最终哪类数据绝不应进入该链路？",
|
||
"options": {
|
||
"A": "可容忍短暂滞后的报表统计数据",
|
||
"B": "仅供内部读、允许弱一致的数据",
|
||
"C": "交易、余额、库存等强一致且不可丢失的业务数据",
|
||
"D": "热点读多写少的页面配置数据"
|
||
},
|
||
"answer": "C",
|
||
"explanation": "Write-Behind 存在两个天然代价：外部直查 DB 的系统会读到滞后旧值，以及若缓存崩溃且未持久化可能丢写。因此该架构只适合内部读、可容忍一致性的数据；而交易、余额、库存等强一致、不可丢失的核心业务数据绝不能进入此链路，必须走强一致方案。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-006",
|
||
"type": "single_choice",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"多级缓存"
|
||
],
|
||
"question": "针对多级缓存（L1 本地 + L2 Redis）副本不一致的问题，下列哪项方案不能从根本上缓解不一致？",
|
||
"options": {
|
||
"A": "本地缓存设置较短 TTL 并配合逻辑过期兜底",
|
||
"B": "写入时通过 MQ 广播失效事件，通知所有节点清除本地缓存",
|
||
"C": "为缓存条目附带版本号/时间戳，读时判定过期",
|
||
"D": "把本地缓存 TTL 无限拉长以减少回源次数"
|
||
},
|
||
"answer": "D",
|
||
"explanation": "加剧不一致的做法是把本地 TTL 无限拉长——本地副本长时间不过期，L2 已更新时本地仍返回旧值，反而放大不一致。正确治理是：短 TTL+逻辑过期兜底、主动失效并广播、版本号/时间戳判定过期。A、B、C 都是缓解一致性的正确手段。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-007",
|
||
"type": "single_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"Caffeine",
|
||
"TinyLFU"
|
||
],
|
||
"question": "关于 Caffeine 与 Redis 的对比，下列说法正确的是？",
|
||
"options": {
|
||
"A": "Caffeine 是独立进程可跨机器共享，访问无需网络",
|
||
"B": "Redis 是进程内 JVM 内存，重启后即失",
|
||
"C": "Caffeine 采用 TinyLFU 淘汰策略，纳秒级访问、适合做 L1 极热点缓存，但重启即失",
|
||
"D": "Redis 只能做本地内存，不支持持久化和分布式锁"
|
||
},
|
||
"answer": "C",
|
||
"explanation": "Caffeine 是进程内 JVM 内存，采用 TinyLFU 淘汰，单元访问纳秒级、无网络开销，适合做 L1 极热点层，但重启即失、无法跨进程共享。Redis 是独立进程、可跨机器，毫秒级网络 I/O，支持持久化、分布式锁/原子计数/榜单/PubSub，是 L2 共享层。A、B、D 的描述正好反了。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-008",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"多级缓存"
|
||
],
|
||
"question": "若业务场景为'读多写少、数据不强一致、希望提升极端热点访问性能'，最合适的缓存方案是？",
|
||
"options": {
|
||
"A": "放弃缓存，全部走 DB",
|
||
"B": "引入多级缓存：进程内 Caffeine 作 L1 极热层，Redis 作 L2 共享层",
|
||
"C": "只用 DB 并加大连接池压力",
|
||
"D": "直接把 DB 当作缓存使用"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "读多写少、不强一致、极端热点适合多级缓存：本地 Caffeine 承担 L1 极热高频访问（纳秒级，无网络），Redis 作为 L2 跨进程共享与兜底层。该组合在热点场景显著降低回源。该场景不需要强一致，无需回 DB。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-009",
|
||
"type": "single_choice",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"缓存降级",
|
||
"限流",
|
||
"熔断"
|
||
],
|
||
"question": "关于缓存架构的可靠性设计，下列说法错误的是？",
|
||
"options": {
|
||
"A": "Redis 可通过主从复制 + 哨兵表决实现高可用",
|
||
"B": "限流、熔断、降级主要用于保护 DB 和后端服务免于过载",
|
||
"C": "必要的 TTL 加上随机抖动可以有效防止缓存雪崩",
|
||
"D": "当 Redis 抖动或不可用时，应把流量无限回源 DB，不做任何降级"
|
||
},
|
||
"answer": "D",
|
||
"explanation": "可靠性设计的另一面恰恰是降级与兜底：当 Redis 不可用时，直接全量回源 DB 可能瞬间打爆 DB，应通过本地缓存兜底、限流/熔断、返回降级数据等方式保护后端。A、B、C 均是正确描述，D 忽略了降级策略，是错误的说法。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-010",
|
||
"type": "single_choice",
|
||
"difficulty": 5,
|
||
"tags": [
|
||
"Redis Cluster",
|
||
"哨兵"
|
||
],
|
||
"question": "关于 Redis 组成的选型，下列说法正确的是？",
|
||
"options": {
|
||
"A": "哨兵（Sentinel）负责数据分片扩容，用于水平扩展写容量",
|
||
"B": "Redis Cluster 负责故障检测与主从自动切换，不具备分片能力",
|
||
"C": "哨兵用于主从复制的高可用表决与故障切换，Cluster 用于多分片横向扩展",
|
||
"D": "RDB 与 AOF 只能二选一，不能同时开启"
|
||
},
|
||
"answer": "C",
|
||
"explanation": "哨兵（Sentinel）用于对主从复制架构做监控、故障检测、自动提升与切换（顾向选举），保障高可用；Redis Cluster 提供的是数据分片（slot），用于横向扩展容量与吞吐。二者职责不同。A、B 将两者职责对调了。RDB 与 AOF 可以同时开启，故 D 错误。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
}
|