聊一聊作为高并发系统基石之一的缓存，会用很简单，用好才是技术活

秒速五厘米 2023-09-23 15:27 6阅读 0赞

大家好，又见面了。

在服务端开发中，**缓存**常常被当做系统*性能扛压*的不二之选。在实施方案上，缓存使用策略虽有一定普适性，却也并非完全绝对，需要结合实际的项目诉求与场景进行综合权衡与考量，进而得出符合自己项目的最佳实践。

### 缓存使用的演进 ###

现有这么一个系统：

> 一个互动论坛系统，用户登录系统之后，可以在论坛上查看帖子列表、查看帖子详情、发表帖子、评论帖子、为帖子点赞等操作。

系统中所有的配置数据与业务数据均存储在`数据库`中。随着业务的发展，注册用户量越来越多，然后整个系统的响应速度也越来越慢，用户体验越来越差，用户逐渐出现流失。

#### 本地缓存的牛刀小试 ####

为了挽救这一局面，开发人员需要介入去分析性能瓶颈并尝试优化提升响应速度，并很快找到响应慢的瓶颈在数据库的频繁操作，于是想到了使用`缓存`来解决问题。

于是，开发人员在项目中使用了**基于接口**维度的**短期缓存**，对每个接口的`请求参数`（帖子ID）与`响应内容`缓存一定的时间（比如1分钟），对于相同的请求，如果匹配到缓存则直接返回缓存的结果即可，不用再次去执行查询数据库以及业务维度的运算逻辑。

![format_png][]

`JAVA`中有很多的开源框架都有提供类似的能力支持，比如`Ehcache`或者`Guava Cache`、`Caffeine Cache`等，可以通过简单的添加注解的方式就实现上述需要的缓存效果。比如使用*Ehcache*来实现接口接口缓存的时候，代码使用方式如下（这里先简单的演示下，后续的系列文档中会专门对这些框架进行深入的探讨）：

@Cacheable(value="UserDetailCache", key="#userId")
    public UserDetail queryUserDetailById(String userId) {
        UserEntity userEntity = userMapper.queryByUserId(userId);
        return convertEntityToUserDetail(userEntity);
    }
    复制代码

基上面的本地缓存策略改动后重新上线，整体的响应性能上果然提升了很多。**本地缓存**的策略虽然有效地提升了处理请求的速度，*但新的问题也随之浮现*。有用户反馈，社区内的帖子列表多次刷新后会出现内容不一致的情况，有的帖子刷新之后会从列表消失，多次刷新后偶尔会出现。

其实这就是本地缓存在集群多节点场景下会遇到的一个很常见的**缓存漂移**现象：

![format_png 1][]

因为业务集群存在多个节点，而缓存是每个业务节点本地独立构建的，所以才出现了更新场景导致的本地缓存不一致的问题，进而表现为上述问题现象。

#### 集中式缓存的初露锋芒 ####

为了解决集群内多个节点间执行写操作之后，各节点本地缓存不一致的问题，开发人员想到可以构建一个**集中式缓存**，然后所有业务节点都读取或者更新同一份缓存数据，这样就可以完美地解决节点间缓存不一致的问题了。

![format_png 2][]

业界成熟的集中式缓存有很多，最出名的莫过于很多人都耳熟能详的`Redis`，或者是在各种面试中常常被拿来与Redis进行比较的`Memcached`。也正是由于它们出色的自身性能表现，在当前的各种分布式系统中，Redis近乎已经成为了一种标配，常常与`MySQL`等持久化数据库搭配使用，放在数据库前面进行扛压。比如下面图中示例的一种最简化版本的组网架构：

![format_png 3][]

开发人员对缓存进行了整改，将**本地缓存**改为了**Redis集中式缓存**。这样一来：

1.  **缓存不一致问题解决**：解决了各个节点间数据不一致的问题。
2.  **单机内存容量限制解决**：使用了Redis这种分布式的集中式缓存，扩大了内存缓存的容量范围，可以顺便将很多业务层面的数据全部加载到Redis中分片进行缓存，性能也相比而言得到了提升。

似乎使用集中式缓存已经是分布式系统中的最优解了，但是现实情况真的就这么简单么？*也不尽然*！

#### 多级缓存的珠联璧合 ####

在尝到了集中式缓存的甜头之后，暖心的程序员们想到要彻底为数据库减压，将所有业务中需要频繁使用的数据全部同步存储到`Redis`中，然后业务使用的时候直接从Redis中获取相关数据，大大地减少了数据库的请求频次。但是改完上线之后，发现有些处理流程中**并没有**太大的性能提升。缘何如此？只因为对`集中式缓存`的过分**滥用**！分析发现这些流程的处理需要涉及大量的交互与数据整合逻辑，一个流程需要访问近乎`30`次Redis！虽然Redis的单次请求处理性能极高，甚至可以达到微秒级别的响应速度，但是每个流程里面几十次的`网络IO`交互，导致频繁的`IO请求`，以及线程的`阻塞`与`唤醒`切换交替，使得系统在线程上下文切换层面**浪费巨大**。

那么，要想破局，最常规的手段便是尝试降低对集中式缓存（如Redis）的请求数量，降低网络IO交互次数。而如何来降低呢？ —— 又回到了**本地缓存**！集中式缓存并非是分布式系统中提升性能的银弹，但我们可以将本地缓存与集中式缓存结合起来使用，**取长补短**，实现效果最大化。如图所示：

![format_png 4][]

上图演示的也即**多级缓存**的策略。具体而言：

*  对于一些**变更频率比较高**的数据，采用`集中式缓存`，这样可以确保数据变更之后所有节点都可以实时感知到，确保数据一致；
 *  对于一些**极少变更的数据**（比如一些系统配置项）或者是一些**对短期一致性要求不高**的数据（比如用户昵称、签名等）则采用`本地缓存`，大大减少对远端集中式缓存的网络IO次数。

这样一来，系统的响应性能又得到了进一步的提升。

通过对缓存使用策略的一步步演进，我们可以感受到缓存的恰当使用对系统性能的帮助作用。

![format_png 5][]

### 无处不在的缓存 ###

缓存存在的初衷，就是为了**兼容两个处理速度不一致的场景对接适配**的。在我们的日常生活中，也常常可以看到“**缓存**”的影子。比如对于几年前比较盛行的那种带桶的净水器（见下图），由于净水的功率比较小，导致实时过滤得到纯净水的水流特别的缓慢，用户倒一杯水要等`2分钟`，体验太差，所以配了个蓄水桶，净水机先慢慢的将净化后的水存储到桶中，然后用户倒水的时候可以从桶里快速的倒出，无需焦急等待 —— 这个蓄水桶，便是一个**缓存器**。

![format_png 6][]

编码源于生活，`CPU`的**高速缓存**设计就是这一生活实践在计算机领域的原样复制。缓存可以说在软件世界里无处不在，除了我们自己的业务系统外，在`网络传输`、`操作系统`、`中间件`、`基础框架`中都可以看到缓存的影子。如：

1.  **网络传输场景**。

比如`ARP协议`，基于ARP缓存表进行`IP`与终端硬件`MAC`地址之间的缓存映射。这样与对端主机之间有通信需求的时候，就可以在ARP缓存中查找到IP对应的对端设备MAC地址，避免每次请求都需要去发送ARP请求查询MAC地址。

1.  **MyBatis的多级缓存**。

`MyBatis`作为`JAVA`体系中被广泛使用的数据库操作框架，其内部为了提升处理效率，构建了**一级缓存**与**二级缓存**，大大减少了对`SQL`的重复执行次数。

1.  **CPU中的缓存**。

`CPU`与`内存`之间有个临时存储器（**高速缓存**），容量虽比内存小，但是处理速度却远快于普通内存。高速缓存的机制，有效地解决了`CPU运算速度`与`内存读写速度`不匹配的问题。

![format_png 7][]

### 缓存的使用场景 ###

缓存作为互联网类软件系统架构与实现中的**基石**般的存在，不仅仅是在*系统扛压*或者*接口处理速度提升*等性能优化方案，在其他多个方面都可以发挥其独一无二的关键价值。下面就让我们一起来看看缓存都可以用在哪些场景上，可以解决我们哪方面的痛点。

#### 降低自身CPU消耗 ####

如前面章节中提到的项目实例，缓存最典型的使用场景就是用在系统的**性能优化**上。而在性能优化层面，一个经典的策略就是“**空间换时间**”。比如：

*  **在数据库表中做一些字段冗备**。

比如用户表`T_User`和部门表`T_Department`，在`T_User`表中除了有个`Department_Id`字段`与T_Department`表进行关联之外，还额外在`T_User`表中存储`Department_Name`值。这样在很多需要展示用户所属部门信息的时候就省去了多表关联查询的操作。

![format_png 8][]

*  **对一些中间处理结果进行存储**。

比如系统中的**数据报表**模块，需要对整个系统内所有的关联业务数据进行计算统计，且需要多张表多来源数据之间的综合汇总之后才能得到最终的结果，整个过程的计算非常的耗时。如果借助缓存，则可以将一些*中间计算结果*进行**暂存**，然后报表请求中基于中间结果进行二次简单处理即可。这样可以大大降低基于请求触发的实时计算量。

在“`空间换时间`”实施策略中，**缓存**是该策略的*核心*、也是被使用的最为广泛的一种方案。借助缓存，可以将一些`CPU`耗时计算的处理结果进行缓存复用，以降低重复计算工作量，达到降低`CPU`占用的效果。

![format_png 9][]

#### 减少对外IO交互 ####

上面介绍的使用缓存是为了不断降低请求处理时对自身CPU占用，进而提升服务的处理性能。这里我们介绍缓存的另一典型使用场景，就是减少系统`对外依赖`的**请求频次**。即通过将一些从远端请求回来的响应结果进行缓存，后面直接使用此缓存结果而无需再次发起网络IO请求交互。

对于服务端而言，通过构建缓存的方式来减少自身对外的**IO请求**，主要有几个考量出发点：

1.  从**自身性能**层面考虑，减少对外`IO操作`，降低了对外接口的`响应时延`，也对服务端自身处理性能有一定提升。
2.  从**对端服务**稳定性层面考虑，避免对端服务`负载过大`。很多时候调用方和被调用方系统的承压能力是不匹配的，甚至有些被调用方系统可能是不承压的。为了避免将对端服务压垮，需要调用方缓存请求结果，`降低IO`请求。
3.  从**自身可靠性**层面而言，将一些远端服务请求到的结果缓存起来，即使远端服务出现故障，自身业务依旧可以基于缓存数据进行正常业务处理，起到一个`兜底作用`，**提升自身的抗风险能力**。

在分布式系统服务治理范畴内，服务注册管理服务是必不可少的，比如`SpringCloud`家族的`Eureka`，或者是`Alibaba`开源的`Nacos`。它们对于缓存的利用，可以说是对上面所提几点的完美阐述。

以`Nacos`为例：

![format_png 10][]

除了上述的因素之外，对一些移动端`APP`或者`H5`界面而言，缓存的使用还有一个层面的考虑，即**降低用户的流量消耗**，通过将一些资源类数据缓存到本地，避免反复去下载，给用户省点流量，也可以**提升用户的使用体验**（界面渲染速度快，减少出现白屏等待的情况）。

![format_png 11][]

#### 提升用户个性化体验 ####

缓存除了在系统性能提升或系统可靠性兜底等场景发挥价值外，在`APP`或者`web`类用户侧产品中，还经常被用于存储一些临时非永久的个性化使用习惯配置或者身份数据，以提升用户的个性化使用体验。

*  缓存`cookie`、`session`等身份鉴权信息，这样就可以避免用户每次访问都需要进行身份验证。

![format_png 12][]

*  记住一些用户上次`操作习惯`，比如用户在一个页面上将列表分页查询设置为`100`条/页，则后续在系统内访问其它列表页面时，都沿用这一设置。
 *  缓存用户的一些`本地设置`，这个主要是`APP`端常用的功能，可以在缓存中保存些与当前设备绑定的设置信息，仅对当前设备有效。比如同一个账号登录某个APP，用户希望在手机端可以显示深色主题，而PAD端则显示浅色主体，这种基于设备的个性化设置，可以缓存到设备本身即可。

![format_png 13][]

### 业务与缓存的集成模式 ###

如前所述，我们可以在不同的方面使用缓存来辅助达成项目在某些方面的诉求。而根据使用场景的不同，在结合缓存进行业务逻辑实现的时候，也会存在不同的**架构模式**，典型的会有`旁路型缓存`、`穿透型缓存`与`异步型缓存`三种。

#### 旁路型缓存 ####

在**旁路型缓存**模式中，业务自行负责与缓存以及数据库之间的交互，可以**自由决定缓存未命中场景的处理策略**，更加契合大部分业务场景的定制化诉求。

![format_png 14][]

由于业务模块自行实现缓存与数据库之间的数据写入与更新的逻辑，实际实现的时候需要注意下在**高并发**场景的`数据一致性`问题，以及可能会出现的`缓存击穿`、`缓存穿透`、`缓存雪崩`等问题的防护。

旁路型缓存是实际业务中**最常使用**的一种架构模式，在后面的内容中，我们还会不断的涉及到旁路缓存中相关的内容。

![format_png 15][]

#### 穿透型缓存 ####

**穿透型缓存**在实际业务中*使用的较少*，主要是应用在一些缓存类的中间件中，或者在一些大型系统中专门的数据管理模块中使用。

一般情况下，业务使用缓存的时候，会是先尝试读取缓存，在尝试读取`DB`，而使用穿透型缓存架构时，会有专门模块将这些动作封装成黑盒的，业务模块不会与数据库进行直接交互。如下图所示：

![format_png 16][]

这种模式对业务而言是比较友好的，业务只需调用缓存接口即可，无需自行实现缓存与DB之间的交互策略。

#### 异步型缓存 ####

还有一种缓存的使用模式，可以看作是穿透型缓存的演进异化版本，其使用场景也相对较少，即**异步型缓存**。其主要策略就是业务侧请求的实时读写交互都是基于缓存进行，任何数据的读写也完全基于缓存进行操作。此外，**单独实现**一个数据持久化操作(独立线程或者进程中执行)，用于将缓存中变更的数据写入到数据库中。

![format_png 17][]

这种情况，**实时业务**读写请求完全**基于缓存**进行，而将数据库仅仅作为一个数据持久化存储的备份盘。由于实时业务请求仅与缓存进行交互，所以在性能上可以得到更好的表现。但是这种模式也存在一个致命的问题：数据可靠性！因为是异步操作，所以在下一次数据写入DB前，会有一段时间数据仅存在于缓存中，**一旦缓存服务宕机，这部分数据将会丢失**。所以这种模式仅适用于对数据一致性要求不是特别高的场景。

### 缓存的优秀实践 ###

`缓存`与`持久化存储`的一个很大的不同点就是缓存的定位应该是一种辅助角色，是一种**锦上添花**般的存在。

`缓存`也是一把**双刃剑**，基于缓存可以大幅提升我们的系统*并发*与*承压*能力，但稍不留神也可能会让我们的系统陷入**灭顶之灾**。所以我们在决定使用缓存的时候，需要知晓缓存设计与使用的一些关键要点，才可以让我们在使用的时候更加游刃有余。

#### 可删除重建 ####

**可删除重建**，这是缓存与持久化存储最大的一个差别。缓存的定位一定是为了辅助业务处理而生的，也就是说缓存有则使用，没有也不会影响到我们具体的业务运转。此外，即使我们的缓存数据除了问题，我们也可以将其删除重建。

这一点在`APP`类的产品中体现的会比较明显。比如对于`微信APP`的缓存，就有明确的提示说缓存可以删除而不会影响其功能使用：

![format_png 18][]

同样地，我们也可以去放心的清理`浏览器`的缓存，而不用担心清理之后我们浏览器或者网页的功能会出现异常（最多就是需要重新下载或者重建缓存数据，速度会有一些慢）。

![format_png 19][]

相同的逻辑，在服务端构建的一些缓存，也应该具备此特性。比如基于内存的缓存，当业务进程重启后，应该有途径可以将缓存重建出来（比如从`MySQL`中加载数据然后构建缓存，或者是缓存`从0开始`基于请求触发而构建）。

![format_png 20][]

#### 有兜底屏障 ####

缓存作为高并发类系统中的核心组件，负责抗住大部分的并发请求，一旦缓存组件出问题，往往对整个系统会造成毁灭性的打击。所以我们的缓存在实现的时候必须要有充足且完备的**兜底**与**自恢复**机制。需要做到以下几点：

*  关注下缓存数据量超出承受范围的处理策略，比如定好数据的`淘汰机制`。
 *  避免缓存集中失效，比如批量加载数据到缓存的时候`随机打散`过期时间，避免同一时间大批量缓存失效引发**缓存雪崩**问题。
 *  有效地**冷数据预热**加载机制，以及**热点数据防过期**机制，避免出现大量对冷数据的请求无法命中缓存或者热点数据突然失效，导致`缓存击穿`问题。
 *  合理的**防身自保**手段，比如采用`布隆过滤器`机制，避免被恶意请求攻陷，导致**缓存穿透**类的问题。

缓存的可靠性与兜底策略设计，是一个宏大且宽泛的命题，在本系列专栏后续的文章中，我们会逐个深入的探讨。

![format_png 21][]

#### 关注缓存的一致性保证 ####

在高并发类的系统中进行数据更新的时候，缓存与数据库的`数据一致性`问题，是一个永远无法绕过的话题。对于基于**旁路型缓存**的大部分业务而言，数据更新操作，一般可以组合出几种不同的处理策略：

*  先更新缓存，再更新数据库
 *  先更新数据库， 再更新缓存
 *  先删除缓存，再更新数据库
 *  先更新数据库，再删除缓存

由于大部分数据库都支持`事务`，而几乎所有的缓存操作都不具有事务性。所以在一些写操作并发不是特别高且一致性要求不是特别强烈的情况下，可以简单的借助数据库的事务进行控制。比如先更新数据库再更新缓存，如果缓存更新失败则回滚数据库事务。

然而在一些并发请求特别高的时候，基于事务控制来保证数据一致性往往会对性能造成影响，且事务`隔离级别`设置的越高影响越大，所以也可以采用一些其它辅助策略，来替代事务的控制，如`重试机制`、或`异步补偿机制`、或多者结合方式等。

比如下图所示的这种策略：

![format_png 22][]

上图的数据更新处理策略，可以有效地保证数据的最终一致性，降低极端情况可能出现数据不一致的概率，并兜底增加了数据不一致时的自恢复能力。

数据一致性保证作为缓存的另一个重要命题，我们会在本系列专栏后续的文章中专门进行深入的剖析。

![format_png 23][]

### 总结回顾 ###

本篇文章的内容中，我们对缓存的各个方面进行了一个简单的阐述与了解，也可以看出缓存对于一个软件系统的重要价值。通过对缓存的合理、充分利用，可以大大的增强我们的系统`承压性能`、提升产品的`用户体验`。

缓存作为**高并发系统**中的`神兵利器`被广泛使用，堪称**高并发系统的基石之一**。而缓存的内容还远远不止我们本篇文档中所介绍的这些、它是一个非常宏大的命题。

![format_png 24][]

为了能够将缓存的方方面面彻底的讲透、讲全，在接下来的一段时间里，我会以**系列专栏**的形式，从不同的角度对缓存的方方面面进行探讨。不仅仅着眼于如何去使用缓存、也一起聊聊缓存设计中的一些`哲学理念` —— 这一点是我觉得更有价值的一点，因为这些理念对提升我们的**软件架构认知**、完善我们的**软件设计思维**有很大的指导与借鉴意义。

![format_png 25][]

**我是悟道，聊技术、又不仅仅聊技术~**

如果觉得有用，请**点赞 + 关注**让我感受到您的支持。也可以关注下我的公众号【架构悟道】，获取更及时的更新。

[format_png]: https://img-blog.csdnimg.cn/img_convert/f8b5f39a0593efc438a2f27355cb79ae.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/2b50ec9160bada27bce7c56da6aff786.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/2d53cd755ef8047c66b4bf7f75fe3e45.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/d5a6664aa74445ba6a5c76d710dff0c4.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/c2574e02046d1ee9e8a7c162aed0cc90.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/3881e65f92f60dce5f8c0c5d951050d0.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/bf562ecb5bbd2eea21e32026d8d3dbc4.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/593ae77894253c2699051b9624c9586d.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/6d02481b6a35423f3f070e541b9e8008.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/abb1583e759df2a77f0b11379e310b6c.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/1f3a4bb63511e70b6779c647d0f6c07c.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/dc058e6f35e8f1d80f02e9ac58c9dda0.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/42fb298bf9652ad6a7cb19cc572df02d.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/1c1b6139f1531447f6d2d288bbe2d234.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/6a2bc2ef4f50727b5821d39778dc77a9.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/881e07e287920b2809b7f25fc888ec13.webp?x-oss-process=image/format,png
[format_png 16]: https://img-blog.csdnimg.cn/img_convert/ff40e1174a166b5c1743b9d7e455b155.webp?x-oss-process=image/format,png
[format_png 17]: https://img-blog.csdnimg.cn/img_convert/38906bb83302a26f7de427059420e6ed.webp?x-oss-process=image/format,png
[format_png 18]: https://img-blog.csdnimg.cn/img_convert/bb5033a535380eba111c70d03514d264.webp?x-oss-process=image/format,png
[format_png 19]: https://img-blog.csdnimg.cn/img_convert/7c9cafc529bd4daed6bd2d9f8210a8ea.webp?x-oss-process=image/format,png
[format_png 20]: https://img-blog.csdnimg.cn/img_convert/c63401bb31af31d92953e629a63dae92.webp?x-oss-process=image/format,png
[format_png 21]: https://img-blog.csdnimg.cn/img_convert/2b7118cf0bc3d49b5ee4873dfe6d714b.webp?x-oss-process=image/format,png
[format_png 22]: https://img-blog.csdnimg.cn/img_convert/0e5d00de10afc4f9fdc6b65e9dbe4fdf.webp?x-oss-process=image/format,png
[format_png 23]: https://img-blog.csdnimg.cn/img_convert/d5ac1a131ee91b2c05eac6f85d960f3c.webp?x-oss-process=image/format,png
[format_png 24]: https://img-blog.csdnimg.cn/img_convert/3c8718acbf66561d068145d3c371d242.webp?x-oss-process=image/format,png
[format_png 25]: https://img-blog.csdnimg.cn/img_convert/3d8987d2993dd7d414598383b68571ed.webp?x-oss-process=image/format,png