【2025下半年系统架构设计师案例分析】电商平台 MySQL + Redis 与缓存击穿治理
文章目录题目背景概念速记缓存击穿题目 2.3.1【问题1】6分图意说明线程1 / 线程2参考答案填空解析题目 2.3.2【问题2】8分参考答案填空解析题目 2.3.3【问题3】11分参考答案要点互斥锁方案逻辑过期方案解析综合考点小结题目背景某电商平台为提升系统性能采用MySQL作为主数据库同时引入Redis作为缓存存储热点数据。系统主要支持商品信息查询、库存管理及订单存储等业务业务特点商品详情访问频繁需快速响应库存需实时准确支持高并发修改订单需长期保存查询频率较低数据分工Redis热门商品基本信息名称、价格等、实时库存数量、热销商品排名等。MySQL完整商品数据、库存明细、订单全量信息及用户数据。本题围绕热点数据在缓存失效时可能出现的缓存击穿热点 Key 失效瞬间大量请求直达数据库分别考察互斥锁方案王工、逻辑过期方案李工的流程填空与方案对比。概念速记缓存击穿缓存击穿某个 Key 非常热点在某一时刻被超高并发访问当该 Key失效的瞬间持续的大并发“穿透”缓存直接请求数据库导致数据库压力骤增甚至故障。互斥锁思路缓存过期后大量并发中只有首个成功拿到锁的线程去查库并回写缓存其余线程等待/重试待缓存就绪后从缓存读取从而避免同一热点多次打库。逻辑过期思路在缓存值中附带逻辑过期时间物理上可不依赖 Redis TTL 立即删键过期后异步从数据库刷新期间仍可先返回旧数据以换取低延迟与高吞吐容忍短暂不一致。题目 2.3.1【问题1】6分针对热点数据可能发生的缓存失效问题架构师王工提出基于互斥锁的缓存实现方案。请补充架构图序列图「互斥锁」中的空白(1) ~ (6)。图意说明线程1 / 线程2线程1缓存未命中后作为成功拿到锁的线程完成「查库 → 回写 → 释放锁」。线程2缓存未命中后在循环内抢锁失败则休眠再重试直到缓存被线程1写好最终缓存命中。下列序列图按真题常见左右两泳道线程1 / 线程2绘制左侧线程1 自顶向下完成「未命中 → 加锁 → 查库 → 回写 → 释锁」右侧线程2 在循环内完成「未命中 → 抢锁失败 → 休眠重试」退出循环后缓存命中。填空(1)~(6)与图中序号一致。为贴近试卷排版不单独拉出Redis/MySQL/锁对象泳道访问缓存与数据库体现在步骤说明中。读图说明时间线上线程1 与线程2并发进入线程2 在循环中多次「失败 → 休眠 → 再查缓存」直到线程1 写完缓存后某次查询命中跳出循环。若需在图中显式画出对 Redis/MySQL 的消息可在备考时另画带缓存/数据库参与者的展开图答卷填空以本题五步 线程2 循环三步为准。参考答案填空序号内容(1)获取互斥锁成功(2)查询数据库(3)更新缓存(4)释放锁(5)获取互斥锁失败(6)休眠一会重试解析缓存击穿场景中互斥锁是常用手段只有首个线程在缓存失效后访问数据库并更新缓存其他线程暂停等待首线程释放锁后其余线程直接从缓存读取避免对数据库的并发冲击。题目 2.3.2【问题2】8分针对同类问题架构师李工提出逻辑过期方案。请补充架构图含「逻辑过期时间」、多线程协作中的空白(1) ~ (8)。参考答案填空注真题图中锁的表述可能写作「分布式锁」或「互斥锁」语义一致同一热点更新互斥即可。序号内容(1)获取分布式锁成功(2)开启新线程(3)返回旧数据(4)查询数据库(5)更新缓存(6)释放锁(7)获取分布式锁失败(8)返回旧数据解析逻辑过期通过在缓存数据中额外存储逻辑过期时间过期后不立即删除缓存而是启动异步任务从数据库加载最新数据并写回缓存刷新期间仍返回旧数据避免请求阻塞。代价是可能出现短时不一致。图意说明典型三线程版本线程1发现逻辑过期 →加锁成功→启动新线程异步刷新→立即返回旧数据不阻塞用户。线程2后台查库 →更新缓存并重置逻辑过期时间→释放锁。线程3发现逻辑过期 →加锁失败→直接返回旧数据与线程1抢锁失败时的处理一致避免集体打库。完整流程还可包含线程4逻辑时间已被线程2刷新后缓存命中且未过期返回新数据。图示常强调不设置物理过期 / 逻辑过期、高可用、性能好但存在短暂不一致。题目 2.3.3【问题3】11分对比王工互斥锁方案与李工逻辑过期方案各自的优缺点。参考答案要点互斥锁方案优点数据一致性高同一时刻仅一个线程访问数据库并更新缓存减少并发写缓存、读脏数据等问题一致性较好。实现简单直观过期后抢锁 → 查库 → 回写 → 释放流程清晰。缺点线程阻塞持锁线程若查库/写缓存较慢其他线程长时间等待响应时间变差。死锁风险异常路径若未释放锁可能造成死锁需超时、finally、看门狗等治理。性能问题高并发下大量线程阻塞等待锁吞吐下降。逻辑过期方案优点非阻塞逻辑过期后仍可立即返回多为旧数据请求不被长时间阻塞。性能好线程竞争与等待少并发能力相对更强。缺点数据不一致刷新完成前用户可能读到过期数据难以保证强一致多为最终一致。实现复杂需维护逻辑过期字段、异步刷新、锁与缓存更新的原子性/协作边界情况多。内存占用数据不随物理 TTL 立即淘汰时可能长期占内存需额外淘汰或容量策略。解析综合互斥锁与逻辑过期都是应对缓存击穿的常见策略。互斥锁缓存失效未命中时首个请求线程尝试获取互斥锁成功则查库、更新缓存并释放锁失败则等待直至锁释放。通过串行化数据库访问保证一致性但高并发下大量线程等待会增加延迟、降低吞吐更适合一致性要求极高、并发相对可控的场景。逻辑过期缓存“过期”后仍可先返回旧数据同时异步查库更新不阻塞主流程并发能力与体验更好但存在短暂不一致更适合高并发、可容忍短时不一致的业务如电商展示、资讯类读多写少场景。考点小结缓存击穿与缓存雪崩、缓存穿透的区别本题侧重热点 Key 失效瞬间。互斥锁强一致、实现简单代价是阻塞与锁治理。逻辑过期高可用、低延迟代价是一致性减弱与工程复杂度。