【软考备考】软件架构设计需要考虑系统性能 如何使用缓存提高系统性能知识点七

一、 核心思想：缓存的本质与价值

在软考中，你首先需要建立起对缓存的正确认知：

• 本质：缓存是一种用空间换时间的策略，通过将高频访问或计算代价高的数据存储在更快的存储介质中，来加速后续的访问。

• 价值：

  1. 降低延迟：从缓存读取数据远比从数据库或远程服务获取快。

  2. 提高吞吐量：减少了后端系统的负载，使其能处理更多请求。

  3. 提升系统扩展性：缓存层可以独立扩展，是系统水平扩展的重要组成部分。

  4. 增强可用性：在网络分区或后端服务短暂不可用时，缓存的数据可以作为降级方案，保证部分功能可用。

---

二、 缓存类型（有哪些缓存可以使用）

在架构设计中，缓存可以应用在多个层次，形成多级缓存体系。这是软考回答中的第一个关键点。

1. 客户端缓存

• 位置：浏览器、手机APP等客户端。

• 技术：HTTP协议缓存头（Expires、Cache-Control、ETag）、浏览器本地存储（LocalStorage）、小程序缓存等。

• 作用：避免向服务器重复请求静态资源（如图片、CSS、JS）甚至部分API数据，直接从本地加载，体验最佳。

2. CDN缓存

• 位置：遍布全球的边缘节点。

• 技术：CDN服务商（如阿里云CDN、腾讯云CDN）。

• 作用：缓存静态资源，用户可以从离自己最近的节点获取数据，极大降低网络延迟。是提升全球用户访问速度的利器。

3. 反向代理/Web服务器缓存

• 位置：应用服务器之前，如Nginx、Apache。

• 技术：Nginx的proxy_cache模块。

• 作用：缓存整个页面的HTML输出或API响应。如果请求命中缓存，请求将不会到达应用服务器，直接由Nginx返回结果，极大减轻应用服务器压力。

4. 应用层缓存（进程内/本地缓存）

• 位置：应用进程内部。

• 技术：Java的 HashMap/ConcurrentHashMap、Guava Cache、Caffeine、Ehcache。

• 作用：缓存计算复杂或频繁使用的业务数据（如字典数据、用户会话信息）。

• 优点：速度极快，无网络开销。

• 缺点：

  • 容量有限，受JVM堆内存大小限制。

  • 数据一致性难保证，在集群环境下，一个实例更新了缓存，其他实例无法感知。

  • 应用重启后缓存失效。

5. 分布式缓存（进程外缓存）

• 位置：独立的、部署在集群中的缓存服务。

• 技术：Redis、Memcached。

• 作用：缓存海量的结构化或非结构化数据，为整个应用集群提供共享的缓存服务。这是架构中最核心、最常用的缓存层。

• 优点：

  • 容量大，可独立扩展。

  • 数据共享，解决了应用层缓存的数据一致性问题。

  • 数据结构丰富（特指Redis，如String, List, Hash, Set等）。

• 缺点：需要网络IO，速度慢于应用层缓存。

6. 数据库缓存

• 位置：数据库内部。

• 技术：MySQL的Query Cache、InnoDB Buffer Pool。

• 作用：数据库自身为了加速查询而设计的机制，如Buffer Pool缓存数据和索引。

• 注意：架构师通常不直接设计这一层，但需要理解其原理以进行SQL优化。

---

三、 核心缓存策略与设计模式（具体策略是什么）

这是软考回答中的精髓，能体现你的架构设计深度。

1. 缓存读写策略

这是决定缓存与数据源（如数据库）如何协同工作的核心模式。

• Cache-Aside（旁路缓存）：最常用、最灵活的策略。

  • 读：先读缓存，命中则返回；未命中则读数据库，并将数据写入缓存。

  • 写：直接更新数据库，然后删除缓存。

  • 优点：避免在写操作时同时更新缓存和数据库带来的并发问题。

  • 缺点：首次请求一定 miss；可能产生短暂的数据不一致（可通过设置短过期时间或延迟双删缓解）。

• Read/Write-Through（读写穿透）

  • 读：与Cache-Aside类似，但缓存组件自己负责在未命中时从数据库加载。

  • 写：先写缓存，然后缓存组件自己负责同步写入数据库。

  • 优点：对应用更透明，业务逻辑更简单。

  • 缺点：需要缓存支持此功能，不常用。

• Write-Behind/Cache（写回）

  • 写：只更新缓存，然后异步批量地更新数据库。

  • 优点：写性能极高。

  • 缺点：有数据丢失风险（缓存宕机），一致性最弱。

软考建议：重点掌握并论述 Cache-Aside 策略及其优缺点。

2. 缓存数据过期与淘汰策略

• 过期策略：

  • TTL：为缓存数据设置一个生存时间，到期后自动失效。最常用。

  • TTI：在最后一次访问后开始倒计时，适合热点数据。

• 淘汰策略（当缓存空间不足时）：

  • LRU：最近最少使用。最常用，符合“二八定律”。

  • LFU：最不经常使用。

  • FIFO：先进先出。

  • Random：随机淘汰。

3. 经典问题与解决方案

• 缓存穿透

  • 问题：大量请求查询一个数据库中根本不存在的数据（如id=-1），导致请求直接打到数据库。

  • 解决方案：

    1. 缓存空对象：即使查询不到，也缓存一个空值或特殊标记（如null），并设置一个较短的过期时间。

    2. 布隆过滤器：在缓存之前加一层布隆过滤器，快速判断某个key是否一定不存在于数据库中。如果不存在，直接返回，避免查询缓存和数据库。

• 缓存击穿

  • 问题：某个热点key过期的瞬间，大量并发请求同时发现缓存失效，集体涌向数据库，导致数据库瞬间压力过大。

  • 解决方案：

    1. 设置热点数据永不过期：通过后台任务定期更新缓存。

    2. 互斥锁：当缓存失效时，只让一个请求去数据库加载数据，其他请求等待，然后从缓存中获取。可以用Redis的setnx命令实现。

• 缓存雪崩

  • 问题：在同一时间，大量的缓存key同时失效，或者缓存服务宕机，导致所有请求都涌向数据库，造成数据库崩溃。

  • 解决方案：

    1. 设置不同的过期时间：在基础TTL上增加一个随机值，避免大量key同时到期。

    2. 构建高可用的缓存集群：如Redis Sentinel或Cluster，避免单点故障。

    3. 服务降级与熔断：当检测到数据库压力过大时，对非核心业务进行降级，直接返回预定义内容（如“服务繁忙”），保护核心业务和数据库。

---

四、 软考实战：如何回答案例分析题和论文题

案例分析题答题框架

场景：某电商平台商品详情页访问缓慢，数据库负载极高，尤其在秒杀活动时，数据库几乎崩溃。

你的回答应遵循以下结构：

1. 分析问题：指出这是典型的高并发读取场景，所有请求直接穿透到数据库，导致数据库成为性能瓶颈。

2. 提出缓存解决方案：

   • 引入分布式缓存：采用 Redis 作为分布式缓存集群，对商品详情、库存等热点数据进行缓存。

   • 采用Cache-Aside模式：读请求优先访问Redis，未命中再从数据库加载并回写到Redis。写请求（如扣库存）更新数据库后，删除Redis中的对应缓存，保证数据一致性。

   • 预防经典问题：

     • 防穿透：对查询不到的商品ID，在Redis中缓存一个空值（TTL设为5分钟）。

     • 防击穿：对秒杀商品这类极致热点数据，设置永不过期，并通过后台服务在活动前预加载。或使用分布式锁来更新。

     • 防雪崩：为不同的商品key设置基础过期时间+随机抖动。

   • 构建多级缓存（可选，体现深度）：在应用本地使用 Caffeine 做一层JVM内缓存，缓存极少量的顶级热点数据（如前100个商品），进一步减少对Redis的访问。

3. 总结效果：通过以上综合的缓存设计方案，可以极大提升商品详情页的响应速度，将绝大部分请求挡在数据库之外，保障系统在高并发场景下的稳定运行。

论文写作要点

在论文中，可以设立专门的小节，如“4.3 缓存架构设计”。

• 背景：描述原系统在性能上遇到的挑战。

• 设计选型：阐述你为什么选择Redis作为分布式缓存，以及为什么采用Cache-Aside模式。

• 详细设计：

  • 画出缓存数据流向图。

  • 描述你是如何设计Key的（如product:{id}），以及选择的数据结构（如使用Hash存储商品对象）。

  • 明确写出你设置的过期时间策略（如30分钟 + 随机0-10分钟）。

• 难点与解决方案：（高分关键） 专门论述你是如何解决缓存穿透、击穿、雪崩问题的，并说明你使用了布隆过滤器、互斥锁等具体技术。

• 效果验证：用数据说明引入缓存后，系统QPS的提升和响应时间的下降。