华为技术架构师分享：高并发场景下缓存处理的一些思路

在实际的开发当中，我们经常需要进行磁盘数据的读取和搜索，因此经常会有出现从数据库读取数据的场景出现。但是当数据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮整个数据库，导致系统卡死等严重问题。

常规的应用系统中，我们通常会在需要的时候对数据库进行查找，因此系统的大致结构如下所示：

1.缓存和数据库之间数据一致性问题

常用于缓存处理的机制我总结为了以下几种：

首先来简单说说Cache aside的这种方式：

Cache Aside模式

这种模式处理缓存通常都是先从数据库缓存查询，如果缓存没有命中则从数据库中进行查找。

这里面会发生的三种情况如下：

缓存命中：

当查询的时候发现缓存存在，那么直接从缓存中提取。

缓存失效：

当缓存没有数据的时候，则从database里面读取源数据，再加入到cache里面去。

缓存更新：

当有新的写操作去修改database里面的数据时，需要在写操作完成之后，让cache里面对应的数据失效。

关于这种模式下依然会存在缺陷。比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

Facebook的大牛们也曾经就缓存处理这个问题发表过相关的论文，链接如下:

分布式环境中要想完全的保证数据一致性是一件极为困难的事情，我们只能够尽可能的减低这种数据不一致性问题产生的情况。

Read Through模式

Read Through模式是指应用程序始终从缓存中请求数据。 如果缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。 检索数据后，缓存会自行更新并将数据返回给调用应用程序。使用Read Through 有一个好处。

我们总是使用key从缓存中检索数据, 调用的应用程序不知道数据库， 由存储方来负责自己的缓存处理，这使代码更具可读性， 代码更清晰。但是这也有相应的缺陷，开发人员需要给编写相关的程序插件，增加了开发的难度性。

Write Through模式

Write Through模式和Read Through模式类似，当数据发生更新的时候，先去Cache里面进行更新，如果命中了，则先更新缓存再由Cache方来更新database。如果没有命中的话，就直接更新Cache里面的数据。

2.缓存穿透问题

在高并发的场景中，缓存穿透是一个经常都会遇到的问题。

什么是缓存穿透？

大量的请求在缓存中没有查询到指定的数据，因此需要从数据库中进行查询，造成缓存穿透。

会造成什么后果？

大量的请求短时间内涌入到database中进行查询会增加database的压力，最终导致database无法承载客户单请求的压力，出现宕机卡死等现象。

常用的解决方案通常有以下几类：

1.空值缓存

在某些特定的业务场景中，对于数据的查询可能会是空的，没有实际的存在，并且这类数据信息在短时间进行多次的反复查询也不会有变化，那么整个过程中，多次的请求数据库操作会显得有些多余。

不妨可以将这些空值（没有查询结果的数据）对应的key存储在缓存中，那么第二次查找的时候就不需要再次请求到database那么麻烦，只需要通过内存查询即可。这样的做法能够大大减少对于database的访问压力。

2.布隆过滤器

通常对于database里面的数据的key值可以预先存储在布隆过滤器里面去，然后先在布隆过滤器里面进行过滤，如果发现布隆过滤器中没有的话，就再去redis里面进行查询，如果redis中也没有数据的话，再去database查询。这样可以避免不存在的数据信息也去往存储库中进行查询情况。

什么是缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

如何避免缓存雪崩问题？

1.使用加锁队列来应付这种问题。当有多个请求涌入的时候，当缓存失效的时候加入一把分布式锁，只允许抢锁成功的请求去库里面读取数据然后将其存入缓存中，再释放锁，让后续的读请求从缓存中取数据。但是这种做法有一定的弊端，过多的读请求线程堵塞，将机器内存占满，依然没有能够从根本上解决问题。

2.在并发场景发生前，先手动触发请求，将缓存都存储起来，以减少后期请求对database的第一次查询的压力。数据过期时间设置尽量分散开来，不要让数据出现同一时间段出现缓存过期的情况。

3.从缓存可用性的角度来思考，避免缓存出现单点故障的问题，可以结合使用 主从+哨兵的模式来搭建缓存架构，但是这种模式搭建的缓存架构有个弊端，就是无法进行缓存分片，存储缓存的数据量有限制，因此可以升级为Redis Cluster架构来进行优化处理。（需要结合企业实际的经济实力，毕竟Redis Cluster的搭建需要更多的机器）

4.Ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。

使用 Ehcache本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，Ehcache本地缓存还能够支撑一阵。

使用 Hystrix进行限流 &降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。

然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。

《深入理解计算机系统》p422

6.1 存储器层次结构中的缓存

一般而言,高速缓存( cache ,读作“ cash ”)是一个小而快速的存储设备,它作为存储在更大、也更慢的设备中的数据对象的缓冲区域。使用高速缓存的过程称为缓存( caching ,读作“ cashing ”)。存储器层次结构的中心思想是,对于每个 k ,位于 k 层的更快更小的存储设备作为位于 k 十1层的更大更慢的存储设备的缓存。换句话说,层次结构中的每一层都缓存来自较低一层的数据对象。例如,本地磁盘作为通过网络从远程磁盘取出的文件(例如 Web 页面)的缓存,主存作为本地磁盘上数据的缓存,依此类推,直到最小的缓存—— CPU 寄存器组。图6-22展示了存储器层次结构中缓存的一般性概念。第 k 十1层的存储器被划分成连续的数据对象组块( chunk ),称为块( block )。每个块都有一个唯一的地址或名字,使之区别于其他的块。块可以是固定大小的(通常是这样的),也可以是可变大小的(例如存储在 Web 服务器上的远程 HTML 文件)。例如,图6-22中第 k 十1层存储器被划分成16个大小固定的块,编号为0~15。

类似地,第 k 层的存储器被划分成较少的块的集合,每个块的大小与 k 十1层的块的大小一样。在任何时刻,第 k 层的缓存包含第 k 十1层块的一个子集的副本。例如,在图6-22中,第 k 层的缓存有4个块的空间,当前包含块4、9、14和3的副本。

数据总是以块大小为传送单元( transfer unit )在第 k 层和第 k +1层之间来回复制的。虽然在层次结构中任何一对相邻的层次之间块大小是固定的,但是其他的层次对之间可以有不同的块大小。例如,在图6-21中,L1和 LO 之间的传送通常使用的是1个字大小的块。L2和L1之间(以及I3和I2之间、L4和I3之间)的传送通常使用的是几十个字节的

块。而L5和L4之间的传送用的是大小为几百或几千字节的块。一般而言,层次结构中较低层(离 CPU 较远)的设备的访问时间较长,因此为了补偿这些较长的访问时间,倾向于使用较大的块。

1. 缓存命中

当程序需要第 k 十1层的某个数据对象 d 时,它首先在当前存储在第 k 层的一个块中查找 d 。如果 d 刚好缓存在第 k 层中,那么就是我们所说的缓存命中( cache hit )。该程序直接从第 k 层读取 d ,根据存储器层次结构的性质,这要比从第 k +1层读取 d 更快。例如,一个有良好时间局部性的程序可以从块14中读出一个数据对象,得到一个对第 k 层的缓存命中。

2. 缓存不命中

另一方面,如果第 k 层中没有缓存数据对象 d ,那么就是我们所说的缓存不命中( cache miss )。当发生缓存不命中时,第 k 层的缓存从第 k 十1层缓存中取出包含 d 的那个块,如果第 k 层的缓存已经满了,可能就会覆盖现存的一个块。

覆盖一个现存的块的过程称为替换( replacing )或驱逐( evicting )这个块。被驱逐的这个块有时也称为牺牲块( victim block )。决定该替换哪个块是由缓存的替换策略( replace — ment policy )来控制的。例如,一个具有随机替换策略的缓存会随机选择一个牺牲块。一个具有最近最少被使用 LRU )替换策略的缓存会选择那个最后被访问的时间距现在最远的块。

在第 k 层缓存从第 k 十1层取出那个块之后,程序就能像前面一样从第 k 层读出 d 了。例如,在图6-22中,在第 k 层中读块12中的一个数据对象,会导致一个缓存不命中,因为块12当前不在第 k 层缓存中。一旦把块12从第 k 十1层复制到第 k 层之后,它就会保持在那里,等待稍后的访问。

3. 缓存不命中的种类

区分不同种类的缓存不命中有时候是很有帮助的。如果第 k 层的缓存是空的,那么对

任何数据对象的访问都会不命中。一个空的缓存有时被称为冷缓存( cold cache ),此类不命中称为强制性不命中( compulsory miss )或冷不命中( cold miss )。冷不命中很重要,因为它们通常是短暂的事件,不会在反复访问存储器使得缓存暖身( warmed up )之后的稳定状态中出现。

只要发生了不命中,第 k 层的缓存就必须执行某个放置策略( placement policy ),确定把它从第 k 十1层中取出的块放在哪里。最灵活的替换策略是允许来自第 k +1层的任何块放在第 k 层的任何块中。对于存储器层次结构中高层的缓存(靠近 CPU ),它们是用硬件来实现的,而且速度是最优的,这个策略实现起来通常很昂贵,因为随机地放置块,定位起来代价很高。

因此,硬件缓存通常使用的是更严格的放置策略,这个策略将第 k 十1层的某个块限制放置在第 k 层块的一个小的子集中(有时只是一个块)。例如,在图6-22中,我们可以确定第 k 十1层的块 i 必须放置在第 k 层的块( i mod 4)中。例如,第 k 十1层的块0、4、8和12会映射到第 k 层的块0块1、5、9和13会映射到块1依此类推。注意,图6-22中的示例缓存使用的就是这个策略。

这种限制性的放置策略会引起一种不命中,称为冲突不命中( conflict miss ),在这种情况中,缓存足够大,能够保存被引用的数据对象,但是因为这些对象会映射到同一个缓存块,缓存会一直不命中。例如,在图6-22中,如果程序请求块0,然后块8,然后块0,然后块8,依此类推,在第 k 层的缓存中,对这两个块的每次引用都会不命中,即使这个缓存总共可以容纳4个块。

程序通常是按照一系列阶段(如循环)来运行的,每个阶段访问缓存块的某个相对稳定不变的集合。例如,一个嵌套循环可能会反复地访问同一个数组的元素。这个块的集合称为这个阶段的工作集( working set )。当工作集的大小超过缓存的大小时,缓存会经历容量不命中( capacity miss )。换句话说就是,缓存太小了,不能处理这个工作集。

4. 缓存管理

正如我们提到过的,存储器层次结构的本质是,每一层存储设备都是较低一层的缓存。在每一层上,某种形式的逻辑必须管理缓存。这里,我们的意思是指某个东西要将缓存划分成块,在不同的层之间传送块,判定是命中还是不命中,并处理它们。管理缓存的逻辑可以是硬件、软件,或是两者的结合。

例如,编译器管理寄存器文件,缓存层次结构的最高层。它决定当发生不命中时何时发射加载,以及确定哪个寄存器来存放数据。L1、L2和L3层的缓存完全是由内置在缓存中的硬件逻辑来管理的。在一个有虚拟内存的系统中, DRAM 主存作为存储在磁盘上的数据块的缓存,是由操作系统软件和 CPU 上的地址翻译硬件共同管理的。对于一个具有像 AFS 这样的分布式文件系统的机器来说,本地磁盘作为缓存,它是由运行在本地机器上的 AFS 客户端进程管理的。在大多数时候,缓存都是自动运行的,不需要程序采取特殊的或显式的行动。

6.3.2 存储器层次结构概念小结

概括来说,基于缓存的存储器层次结构行之有效,是因为较慢的存储设备比较快的存储设备更便宜,还因为程序倾向于展示局部性:

1）利用时间局部性: 由于时间局部性,同一数据对象可能会被多次使用。一旦一个数据对象在第一次不命中时被复制到缓存中,我们就会期望后面对该目标有一系列的访问命中。因为缓存比低一层的存储设备更快,对后面的命中的服务会比最开始的不命中快很多。

2）利用空间局部性: 块通常包含有多个数据对象。由于空间局部性,我们会期望后面对该块中其他对象的访问能够补偿不命中后复制该块的花费。现代系统中到处都使用了缓存。正如从图6-23中能够看到的那样, CPU 芯片、操作系统、分布式文件系统中和万维网上都使用了缓存。各种各样硬件和软件的组合构成和管理着缓存。注意,图6-23中有大量我们还未涉及的术语和缩写。在此我们包括这些术语和缩写是为了说明缓存是多么的普遍。

---