hello~ 这里是软考系统架构师备考笔记。

在软考高级系统架构设计师考试里，分布式缓存和高并发数据库架构是真正的“常青树”。无论是综合知识、案例分析还是论文，Redis 缓存设计几乎年年都是必考考点。

特别是在高并发、高可用场景下，“缓存穿透、缓存雪崩、缓存击穿”这三座大山，很多老铁在考场上一紧张就开始串台：把击穿答成穿透，把雪崩的随机时间往击穿上怼，白白丢掉十几分。

今天咱们就通过一道真实大厂背景的模拟案例大题，把这三个经典异常的病因和防御方案一次讲透，帮大家把采分点死死拿捏住。

模拟案例还原

某大型互联网电商平台在“双十一”大促活动前夕，为了应对每秒数十万的高并发商品浏览与秒杀请求，架构团队将原有的单体数据库升级为“Redis 集群 + MySQL 读写分离”的高性能存储架构。

在系统高并发运行过程中，出现了以下存储与缓存异常现象

• ▪▪ ▪ ▪ ▪ 现象 1 ：很多恶意用户和爬虫程序利用批量随机生成的非法商品 ID（这些 ID 在 Redis 缓存和后台 MySQL 数据库中均不存在），进行高频并发查询。这导致大量请求直接穿透 Redis 缓存打在数据库上，使数据库 CPU 使用率瞬间飙升至 100%。

：很多恶意用户和爬虫程序利用批量随机生成的非法商品 ID（这些 ID 在 Redis 缓存和后台 MySQL 数据库中均不存在），进行高频并发查询。这导致大量请求直接穿透 Redis 缓存打在数据库上，使数据库 CPU 使用率瞬间飙升至 100%。

• ▪▪ ▪ ▪ ▪ 现象 2 ：大促活动开启瞬间，系统首页推荐的“爆款热销商品”由于预设的缓存 TTL 过期时间突然到期，导致海量并发读请求瞬间全部砸在后台数据库上，数据库连接池迅速耗尽。

：大促活动开启瞬间，系统首页推荐的“爆款热销商品”由于预设的缓存 TTL 过期时间突然到期，导致海量并发读请求瞬间全部砸在后台数据库上，数据库连接池迅速耗尽。

• ▪▪ ▪ ▪ ▪ 现象 3 ：系统在凌晨对上万个促销商品的缓存 Key 统一设置了固定的 2 小时过期时间。到了凌晨 2 点，这上万个商品缓存 Key 在同一秒钟集中失效，大量并发流量瞬间涌入数据库，引发数据库宕机并导致上游微服务发生雪崩式崩溃。

：系统在凌晨对上万个促销商品的缓存 Key 统一设置了固定的 2 小时过期时间。到了凌晨 2 点，这上万个商品缓存 Key 在同一秒钟集中失效，大量并发流量瞬间涌入数据库，引发数据库宕机并导致上游微服务发生雪崩式崩溃。

• ▪▪ ▪ ▪ ▪ 请指出上述现象 1、2、3 分别属于哪种缓存异常问题（缓存穿透、缓存雪崩、缓存击穿）。
• ▪▪ ▪ ▪ ▪ 针对现象 1，项目组如果采用布隆过滤器（Bloom Filter）来防御，请简述布隆过滤器的基本工作原理及其优缺点。
• ▪▪ ▪ ▪ ▪ 针对现象 2 和现象 3，请分别给出最有效的架构优化与防御方案。

出题意图与采分逻辑

老铁们做案例题，先别急着默写八股文，咱们先琢磨命题组为什么偏偏爱考这道题？

你以为考官在考几个 Redis 命令怎么敲，其实考的是系统架构师在高并发、海量读写场景下，保护脆弱数据库的护城河设计能力。

命题组的核心考察逻辑主要看三点

• ▪▪ ▪ ▪ ▪ 高可用与服务韧性意识 ：在分布式互联网系统中，数据库永远是最脆弱的瓶颈。缓存不仅仅是为了“加速读取”，更是保护数据库不被高并发大流量冲垮的防浪堤。架构师必须具备多层防御的韧性架构思维。

：在分布式互联网系统中，数据库永远是最脆弱的瓶颈。缓存不仅仅是为了“加速读取”，更是保护数据库不被高并发大流量冲垮的防浪堤。架构师必须具备多层防御的韧性架构思维。

• ▪▪ ▪ ▪ ▪ 问题根因与解法精准匹配 ：阅卷时不看你写了多少套话，而是看你能不能根据题目给出的业务现象，精准区分是“查询不存在的数据（穿透）”、“单个热点失效（击穿）”还是“批量同时失效/宕机（雪崩）”，并对症下药给出架构选型。

：阅卷时不看你写了多少套话，而是看你能不能根据题目给出的业务现象，精准区分是“查询不存在的数据（穿透）”、“单个热点失效（击穿）”还是“批量同时失效/宕机（雪崩）”，并对症下药给出架构选型。

• ▪▪ ▪ ▪ ▪ 机考采分关键词检索 ：机考系统的采分点对“布隆过滤器、Bitmap、误判率、互斥锁、分布式锁、SETNX、随机 TTL、逻辑永不过期、限流熔断”等核心关键词有硬性检索，用词不准或者技术放错位置直接扣分。

：机考系统的采分点对“布隆过滤器、Bitmap、误判率、互斥锁、分布式锁、SETNX、随机 TTL、逻辑永不过期、限流熔断”等核心关键词有硬性检索，用词不准或者技术放错位置直接扣分。

一个通俗比喻：图书馆前台与地下书库

为了让大家脑子里有清晰的物理画面，咱们打个极通俗的比方

把 Redis 缓存看作“图书馆前台快速检索台”，把后台数据库看作“地下总书库”。

• ▪▪ ▪ ▪ ▪ 缓存穿透 —— 恶作剧读者拿着根本不存在的书名来查书 ： 地下总书库藏书有限且取书极慢，前台检索台放着所有书的索引卡片。有恶作剧读者拿着根本不存在的书名（如《宇宙无敌爆米花史》）高频狂搜。前台卡片库里根本没有，只能不断派管理员跑去地下总书库几万个架子里死找，最后总书库管理员被活活累瘫。 💡 防守方案 ：在图书馆大门口贴一张“总馆现有书名目录列表”（布隆过滤器），只要目录里没有的书，直接在大门口拦住；或者前台查不到后，在前台记上一张“该书不存在”的空卡片（缓存空值/NULL），下一次再查直接在前台打回。

： 地下总书库藏书有限且取书极慢，前台检索台放着所有书的索引卡片。有恶作剧读者拿着根本不存在的书名（如《宇宙无敌爆米花史》）高频狂搜。前台卡片库里根本没有，只能不断派管理员跑去地下总书库几万个架子里死找，最后总书库管理员被活活累瘫。 💡 防守方案 ：在图书馆大门口贴一张“总馆现有书名目录列表”（布隆过滤器），只要目录里没有的书，直接在大门口拦住；或者前台查不到后，在前台记上一张“该书不存在”的空卡片（缓存空值/NULL），下一次再查直接在前台打回。

• ▪▪ ▪ ▪ ▪ 缓存击穿 —— 全城疯抢的“超级爆款书”卡片刚好到期撤下了 ： 图书馆有一本全城人都在抢着看的超级爆款书（热点 Key）。1000 个读者同时拥挤在前台要借这本书。巧的是，前台这张热点书卡片刚好在此时过期被工作人员撤下了！1000 个读者瞬间全部冲向狭窄的地下总书库通道去抢那唯一的一本书，总书库书架瞬间被挤塌。 💡 防守方案 ：前台发现卡片过期时，给地下通道加上一把独占锁（互斥锁/分布式锁），只允许 1 个读者代表拿着锁进地下书库取书并重新贴好卡片，其余 999 个读者在门口原地稍等；或者直接将这种爆款书卡片设置为“逻辑永不过期”，后台异步刷卡。

： 图书馆有一本全城人都在抢着看的超级爆款书（热点 Key）。1000 个读者同时拥挤在前台要借这本书。巧的是，前台这张热点书卡片刚好在此时过期被工作人员撤下了！1000 个读者瞬间全部冲向狭窄的地下总书库通道去抢那唯一的一本书，总书库书架瞬间被挤塌。 💡 防守方案 ：前台发现卡片过期时，给地下通道加上一把独占锁（互斥锁/分布式锁），只允许 1 个读者代表拿着锁进地下书库取书并重新贴好卡片，其余 999 个读者在门口原地稍等；或者直接将这种爆款书卡片设置为“逻辑永不过期”，后台异步刷卡。

• ▪▪ ▪ ▪ ▪ 缓存雪崩 —— 前台所有的图书卡片在同一秒钟被集体丢弃 ： 前台所有的图书卡片，被管理员统一设置了“存放 2 小时，晚上 8 点集中清理”。到了晚上 8 点，前台成千上万张卡片瞬间全部清空！刚好此时涌入大量读者，前台查不到任何卡片，所有读者瞬间全部涌入地下总书库，总书库直接全军覆没。 💡 防守方案 ：给每张卡片的存放时间加上一个随机数（比如 2 小时加上随机 1-30 分钟），让卡片错开时间陆续失效；同时做前台多机热备（Redis 集群）并在大门口设置限流闸机。

： 前台所有的图书卡片，被管理员统一设置了“存放 2 小时，晚上 8 点集中清理”。到了晚上 8 点，前台成千上万张卡片瞬间全部清空！刚好此时涌入大量读者，前台查不到任何卡片，所有读者瞬间全部涌入地下总书库，总书库直接全军覆没。 💡 防守方案 ：给每张卡片的存放时间加上一个随机数（比如 2 小时加上随机 1-30 分钟），让卡片错开时间陆续失效；同时做前台多机热备（Redis 集群）并在大门口设置限流闸机。

核心概念本质辨析

咱们把这三个缓存异常问题的本质差异，总结成一张硬核对照表

押韵记忆口诀

穿透查无布隆挡，击穿爆款锁来扛；雪崩乱打加随机，集群降级防宕网！

考点判断顺序（先看数据存不存在，再看 Key 的数量）

• ▪▪ ▪ ▪ ▪ 第一步看数据到底存不存在 ：如果请求的数据在数据库中也根本不存在，无论查询多少次，都是 缓存穿透 。

：如果请求的数据在数据库中也根本不存在，无论查询多少次，都是 缓存穿透 。

• ▪▪ ▪ ▪ ▪ 第二步看是单个 Key 还是批量 Key ：如果是单一高并发热点 Key 失效，这是 缓存击穿 ；如果是成千上万个 Key 同时到期或者 Redis 服务整体瘫痪，这就是 缓存雪崩 。

：如果是单一高并发热点 Key 失效，这是 缓存击穿 ；如果是成千上万个 Key 同时到期或者 Redis 服务整体瘫痪，这就是 缓存雪崩 。

架构师的必备武器：布隆过滤器与分布式锁

在答题或写论文时，布隆过滤器（Bloom Filter）和互斥锁（Mutex / 分布式锁）是展现技术深度的关键点。

为什么防穿透优先选布隆过滤器，而不是用普通的 Hash 集合？

核心就在于 内存成本与空间效率 ！

在海量数据（如几亿个用户 ID 或商品 ID）场景下，如果使用传统 Hash Set 将几亿个 Key 缓存在内存中，可能需要消耗几十 GB 甚至上百 GB 的昂贵内存。而布隆过滤器利用 二进制位图（Bitmap）和多个独立哈希函数 ，将几亿个 Key 映射到一个紧凑的位图上，只需几百兆内存即可完成判重。

但架构师必须在方案中写明布隆过滤器的两个天然特性与权衡（Trade-off）

• ▪▪ ▪ ▪ ▪ 存在误判率（False Positive） ：布隆过滤器判断“存在”不一定真的存在（哈希碰撞），但判断“不存在”就一定不存在！因此它非常适合作为第一道防线，把确定不存在的非法流量 100% 拦截在外。

：布隆过滤器判断“存在”不一定真的存在（哈希碰撞），但判断“不存在”就一定不存在！因此它非常适合作为第一道防线，把确定不存在的非法流量 100% 拦截在外。

• ▪▪ ▪ ▪ ▪ 删除困难 ：由于多个 Key 映射的 Bit 位可能重叠，传统布隆过滤器不支持直接删除元素（删除一位可能会影响其他正常数据）。

：由于多个 Key 映射的 Bit 位可能重叠，传统布隆过滤器不支持直接删除元素（删除一位可能会影响其他正常数据）。

缓存击穿中的分布式锁机制

当热点 Key 失效瞬间，如果有 10000 个并发请求同时发现缓存为空，如果不加控制，这 10000 个线程会同时涌向数据库，瞬间打崩数据库连接池。

架构师的标准做法是：利用 Redis 的 SETNX 或 Redisson 分布式锁获取互斥锁。只有成功拿到锁的第 1 个线程去查询数据库并写回缓存；其余 9999 个线程获取锁失败后，休眠几十毫秒后重试，此时缓存已被第 1 个线程补齐，直接命中缓存返回。

码农思维是“出了问题加个重试脚本”，架构师思维是“在极限并发下，用几百 KB 的位图和微秒级的互斥锁，筑起不可摧毁的数据防浪堤”！

高并发缓存异常防护速查表

答题模板与本题实战作答

万能答题句式

“本系统在 【高并发业务/海量数据查询】 场景中，考虑到 【缓存穿透/雪崩/击穿导致数据库崩溃】 的风险，采用了【布隆过滤器 / 随机 TTL / 分布式锁 / Redis Cluster 高可用集群】防护方案。该方案通过【核心机制：如位图哈希拦截 / 互斥锁控流 / 过期时间平滑分散】，在保障 【高并发读取与低延时响应】 的同时，有效避免了 【海量请求穿透/击穿/雪崩对底层数据库的冲击】 ，满足了系统 【高可用性与高韧性】 的质量属性要求。”

本期模拟练习规范解答

在解答本期模拟练习时，标准踩分要点如下

问题 1：异常类型识别 - 现象 1 属于 缓存穿透 ：恶意用户和爬虫查询 Redis 和数据库中均不存在的非法 ID。 - 现象 2 属于 缓存击穿 ：单个爆款热销商品 Key 的缓存 TTL 在大促开启瞬间过期，高并发流量集中砸在数据库上。 - 现象 3 属于 缓存雪崩 ：上万个促销商品缓存 Key 设置了相同的过期时间，在凌晨 2 点集中同一秒失效。

问题 2：布隆过滤器原理与优缺点 - 工作原理 ：利用一个很长的二进制向量（Bitmap）和多个独立哈希函数。当写入一个 Key 时，通过多个哈希函数计算出多个 Bit 位置为 1；查询时重新计算对应位置，若对应的 Bit 位中只要有一位为 0，则该 Key 一定不存在 ；若全为 1，则该 Key 可能存在 。 - 优点 ：空间效率极高，内存占用极小，查询时间复杂度为 O(k)，性能优异。 - 缺点 ：存在误判率（判断存在可能实际不存在），且不支持元素直接删除。

问题 3：现象 2 与现象 3 的优化方案 - 针对现象 2（击穿） ：采用 分布式锁（互斥锁） 机制，当缓存失效时，仅允许获取锁的单个线程查询数据库并重建缓存，其余线程等待重试；或将爆款商品 Key 设置为 逻辑永不过期 ，由后台异步任务定期刷新。 - 针对现象 3（雪崩） ：在设置商品 Key 的 TTL 时，在固定过期时间（如 2 小时）上 叠加一个随机时间偏差 （如 1-15 分钟），使 Key 均匀错开过期；同时部署 Redis Cluster 高可用集群 ，并配置 Sentinel 服务限流与熔断降级 。

跨行业应用场景与论文素材

在软考高级论文（如《论分布式缓存技术在高性能系统中的应用》）中，将缓存防御方案与具体行业业务结合，能极大提升论文的真实感和专业度

本期小结

• ▪▪ ▪ ▪ ▪ 口诀牢记 ：穿透查无布隆挡，击穿爆款锁来扛；雪崩乱打加随机，集群降级防宕网！
• ▪▪ ▪ ▪ ▪ 核心结论 ：查无此数用布隆/空值（防穿透）；单点爆款用互斥锁/逻辑永不过期（防击穿）；大面积到期加随机时间/集群限流（防雪崩）。

：查无此数用布隆/空值（防穿透）；单点爆款用互斥锁/逻辑永不过期（防击穿）；大面积到期加随机时间/集群限流（防雪崩）。

• ▪▪ ▪ ▪ ▪ 答题句式 ：“本系统在 【场景】 中，采用了 【防御方案】 ，通过 【核心机制】 ，实现了 【流量控制与防护】 ，满足了 【高可用与高韧性】 要求。”

：“本系统在 【场景】 中，采用了 【防御方案】 ，通过 【核心机制】 ，实现了 【流量控制与防护】 ，满足了 【高可用与高韧性】 要求。”

下一期咱们继续啃软考架构师数据库硬骨头——分库分表实战设计（水平拆分、垂直拆分与分布式全局 ID 生成），不见不散！

觉得有帮助欢迎点赞、推荐、转发。还没关注的老铁，点下方名片关注一下，下期继续啃案例硬骨头。