当前位置：首页 > news >正文

6、架构-服务端缓存

news 2025/9/14 21:10:09

为系统引入缓存之前，第一件事情是确认系统是否真的需要缓存。从开发角度来说，引入缓存会提高系统复杂度，因为你要考虑缓存的失效、更新、一致性等问题；从运维角度来说，缓存会掩盖一些缺陷，让问题在更久的时间以后，出现在距离发生现场更远的位置上；从安全角度来说，缓存可能会泄漏某些保密数据，也是容易受到攻击的薄弱点。冒着上述种种风险，仍能说服你引入缓存的理由，总结起来无外乎以下两种。

为缓解CPU压力而引入缓存：譬如把方法运行结果存储起来、把原本要实时计算的内容提前算好、对一些公用的数据进行复用，这可以节省CPU算力，顺带提升响应性能。
为缓解I/O压力而引入缓存：譬如把原本对网络、磁盘等较慢介质的读写访问变为对内存等较快介质的访问，将原本对单点部件（如数据库）的读写访问变为对可扩缩部件（如缓存中间件）的访问，顺带提升响应性能。

请注意，缓存虽然是典型以空间换时间来提升性能的手段，但它的出发点是缓解CPU和I/O资源在峰值流量下的压力，“顺带”而非 “专门”地提升响应性能。这里的言外之意是如果可以通过增强CPU、 I/O本身的性能（譬如扩展服务器的数量）来满足需要的话，那升级硬件往往是更好的解决方案，即使需要一些额外的投入成本，也通常要优于引入缓存后可能带来的风险。

缓存属性

有不少软件系统最初的缓存功能是以HashMap或者 ConcurrentHashMap为起点演进的。当开发人员发现系统中某些资源的构建成本比较高，而这些资源又有被重复使用的可能时，会很自然地产生“循环再利用”的想法，将它们放到Map容器中，待下次需要时取出重用，避免重新构建，这种原始朴素的复用就是最基本的缓存。不过，一旦我们专门把“缓存”看作一项技术基础设施，一旦它有了通用、高效、可统计、可管理等方面的需求，其中要考虑的因素就变得复杂起来。通常，我们设计或者选择缓存至少会考虑以下四个维度的属性。

吞吐量：缓存的吞吐量使用OPS值（每秒操作数，Operation per Second，ops/s）来衡量，反映了对缓存进行并发读、写操作的效率，即缓存本身的工作效率高低。
命中率：缓存的命中率即成功从缓存中返回结果次数与总请求次数的比值，反映了引入缓存的价值高低，命中率越低，引入缓存的收益越小，价值越低。
扩展功能：即缓存除了基本读写功能外，还提供哪些额外的管理功能，譬如最大容量、失效时间、失效事件、命中率统计，等等。
分布式缓存：缓存可分为“进程内缓存”和“分布式缓存”两大类，前者只为节点本身提供服务，无网络访问操作，速度快但缓存的数据不能在各服务节点中共享，后者则相反。

吞吐量

缓存的吞吐量只在并发场景中才有统计的意义，因为若不考虑并发，即使是最原始的、以HashMap实现的缓存，访问效率也已经是常量时间复杂度（即O(1)），其中涉及碰撞、扩容等场景的处理属于数据结构基础，这里不再展开。但HashMap并不是线程安全的容器，如果要让它在多线程并发下正确地工作，就要用 Collections.synchronizedMap进行包装，这相当于给Map接口的所有访问方法都自动加全局锁；或者改用ConcurrentHashMap来实现，这相当于给Map的访问分段加锁（从JDK 8起已取消分段加锁，改为 CAS+Synchronized锁单个元素）。无论采用怎样的实现方法，这些线程安全措施都会带来一定的吞吐量损失。

命中率与淘汰策略

有限的物理存储决定了任何缓存的容量都不可能是无限的，所以缓存需要在消耗空间与节约时间之间取得平衡，这要求缓存必须能够自动或者人工淘汰掉缓存中的低价值数据。考虑到由人工管理的缓存淘汰主要取决于开发者如何编码，不能一概而论，这里只讨论由缓存自动进行淘汰的情况。笔者所说的“缓存如何自动地实现淘汰低价值目标”，现在被称为缓存的淘汰策略。

在了解缓存如何实现自动淘汰低价值数据之前，首先要定义怎样的数据才算是“低价值”。由于缓存的通用性，这个问题的答案必须是与具体业务逻辑无关的，只能从缓存工作过程收集到的统计结果来确定数据是否有价值，通用的统计结果包括但不限于数据何时进入缓存、被使用过多少次、最近什么时候被使用，等等。一旦确定选择何种统计数据，就决定了如何通用地、自动地判定缓存中每个数据的价值高低，也相当于决定了缓存的淘汰策略是如何实现的。目前，最基础的淘汰策略实现方案有以下三种。

FIFO（First In First Out）：优先淘汰最早进入被缓存的数据。 FIFO的实现十分简单，但一般来说它并不是优秀的淘汰策略，越是频繁被用到的数据，往往会越早存入缓存之中。如果采用这种淘汰策略，很可能会大幅降低缓存的命中率。
LRU（Least Recent Used）：优先淘汰最久未被访问过的数据。 LRU通常会采用HashMap加LinkedList的双重结构（如LinkedHashMap）来实现，以HashMap来提供访问接口，保证常量时间复杂度的读取性能，以LinkedList的链表元素顺序来表示数据的时间顺序，每次缓存命中时把返回对象调整到LinkedList开头，每次缓存淘汰时从链表末端开始清理数据。对大多数的缓存场景来说，LRU明显要比FIFO策略合理，尤其适合用来处理短时间内频繁访问的热点对象。但是如果一些热点数据在系统中被频繁访问，只是最近一段时间因为某种原因未被访问过，那么这些热点数据此时就会有被LRU淘汰的风险，换句话说，LRU依然可能错误淘汰价值更高的数据。
LFU（Least Frequently Used）：优先淘汰最不经常使用的数据。 LFU会给每个数据添加一个访问计数器，每访问一次就加1，需要淘汰时就清理计数器数值最小的那批数据。LFU可以解决上面LRU中热点数据间隔一段时间不访问就被淘汰的问题，但同时它又引入了两个新的问题。第一个问题是需要对每个缓存的数据专门维护一个计数器，每次访问都要更新，但这样做会带来高昂的维护开销；另一个问题是不便于处理随时间变化的热度变化，譬如某个曾经频繁访问的数据现在不需要了，但很难自动将它清理出缓存。

缓存的淘汰策略直接影响缓存的命中率，没有一种策略是完美的、能够满足系统全部需求的。不过，随着淘汰算法的不断发展，近年来的确出现了许多相对性能更好、也更复杂的新算法。以LFU为例，针对它存在的两个问题，近年来提出的TinyLFU和W-TinyLFU算法就会有更好的效果。

分布式缓存

相比缓存数据在进程内存中读写的速度，一旦涉及网络访问，由网络传输、数据复制、序列化和反序列化等操作所导致的延迟要比内存访问高得多，所以对分布式缓存来说，处理与网络相关的操作是对吞吐量影响更大的因素，往往也是比淘汰策略、扩展功能更重要的关注点，这也决定了尽管有Ehcache、Infinispan这类能同时支持分布式部署和进程内部署的缓存方案，但通常进程内缓存和分布式缓存选型时会有完全不同的候选对象及考察点。在我们决定使用哪种分布式缓存前，首先必须确定自己的需求是什么。

尽管多级缓存结合了进程内缓存和分布式缓存的优点，但它的代码侵入性较大，需要由开发者承担多次查询、多次回填的工作，也不便于管理，如超时、刷新等策略都要设置多遍，数据更新更是麻烦，很容易出现各个节点的一级缓存以及二级缓存中数据不一致的问题。所以，必须“透明”地解决以上问题，才能使多级缓存具有实用的价值。一种常见的设计原则是变更以分布式缓存中的数据为准，访问以进程内缓存的数据优先。大致做法是当数据发生变动时，在集群内发送推送通知（简单点的话可采用Redis的PUB/SUB，求严谨的话可引入 ZooKeeper或etcd来处理），让各个节点的一级缓存中的相应数据自动失效。当访问缓存时，提供统一封装好的一、二级缓存联合查询接口，接口外部是只查询一次，接口内部自动实现优先查询一级缓存，未获取到数据再自动查询二级缓存的逻辑。

缓存风险

1.缓存穿透

缓存的目的是缓解CPU或者I/O的压力，譬如对数据库做缓存，大部分流量都从缓存中直接返回，只有缓存未能命中的数据请求才会流到数据库中，这样数据库压力自然就减小了。但是如果查询的数据在数据库中根本不存在，缓存里自然也不会有，这类请求的流量每次都不会命中，且每次都会触及末端的数据库，缓存就起不到缓解压力的作用了，这种查询不存在的数据的现象被称为缓存穿透。

缓存穿透有可能是业务逻辑本身就存在的固有问题，也有可能是恶意攻击所导致。为了解决缓存穿透问题，通常会采取下面两种办法。

对于业务逻辑本身不能避免的缓存穿透，可以约定在一定时间内对返回为空的Key值进行缓存（注意是正常返回但是结果为空，不应把抛异常的也当作空值来缓存），使得在一段时间内缓存最多被穿透一次。如果后续业务在数据库中对该Key值插入了新记录，那应当在插入之后主动清理掉缓存的Key值。如果业务时效性允许的话，也可以对缓存设置一个较短的超时时间来自动处理。
对于恶意攻击导致的缓存穿透，通常会在缓存之前设置一个布隆过滤器来解决。所谓恶意攻击是指请求者刻意构造数据库中肯定不存在的Key值，然后发送大量请求进行查询。布隆过滤器是用最小的代价来判断某个元素是否存在于某个集合的办法。如果布隆过滤器给出的判定结果是请求的数据不存在，直接返回即可，连缓存都不必去查。虽然维护布隆过滤器本身需要一定的成本，但比起攻击造成的资源损耗仍然是值得的。

2.缓存击穿

我们都知道缓存的基本工作原理是首次从真实数据源加载数据，完成加载后回填入缓存，以后其他相同的请求就从缓存中获取数据，以缓解数据源的压力。如果缓存中某些热点数据忽然因某种原因失效了，譬如由于超期而失效，此时又有多个针对该数据的请求同时发送过来，这些请求将全部未能命中缓存，到达真实数据源中，导致其压力剧增，这种现象被称为缓存击穿。要避免缓存击穿问题，通常会采取下面两种办法。

加锁同步，以请求该数据的Key值为锁，使得只有第一个请求可以流入真实的数据源中，对其他线程则采取阻塞或重试策略。如果是进程内缓存出现问题，施加普通互斥锁即可，如果是分布式缓存中出现问题，就施加分布式锁，这样数据源就不会同时收到大量针对同一个数据的请求了。
热点数据由代码来手动管理。缓存击穿是仅针对热点数据自动失效才引发的问题，对于这类数据，可以直接由开发者通过代码来有计划地完成更新、失效，避免由缓存的策略自动管理。

3.缓存雪崩

缓存击穿是针对单个热点数据失效，由大量请求击穿缓存而给真实数据源带来压力。还有一种可能更普遍的情况，即不是针对单个热点数据的大量请求，而是由于大批不同的数据在短时间内一起失效，导致这些数据的请求都击穿缓存到达数据源，同样令数据源在短时间内压力剧增。出现这种情况，往往是因为系统有专门的缓存预热功能，或者大量公共数据是由某一次冷操作加载的，使得由此载入缓存的大批数据具有相同的过期时间，在同一时刻一起失效；也可能是因为缓存服务由于某些原因崩溃后重启，造成大量数据同时失效。这种现象被称为缓存雪崩。要避免缓存雪崩问题，通常会采取下面三种办法。

提升缓存系统可用性，建设分布式缓存的集群
启用透明多级缓存，这样各个服务节点一级缓存中的数据通常会具有不一样的加载时间，也就分散了它们的过期时间。
将缓存的生存期从固定时间改为一个时间段内的随机时间，譬如原本是1h过期，在缓存不同数据时，可以设置生存期为55min到 65min之间的某个随机时间。

4.缓存污染

缓存污染是指缓存中的数据与真实数据源中的数据不一致的现象。这种情况通常是由于开发者在更新缓存时操作不规范造成的，可能导致数据的不一致性。虽然缓存通常不追求强一致性，但最终一致性仍然是必须的。

造成缓存污染的常见原因

更新缓存不规范：开发者从缓存中获得某个对象并更新其属性，但由于某些原因（如业务异常回滚），最终未能成功写入数据库，导致缓存中的数据是新的，但数据库中的数据是旧的。
操作顺序错误：如果更新操作的顺序不正确，例如先失效缓存后写数据源，可能会导致缓存和数据源的不一致。

提高缓存一致性的设计模式

为了尽可能地提高使用缓存时的一致性，以下几种常见的设计模式可以帮助管理缓存更新：

Cache Aside：
- 读数据：先读缓存，如果缓存中没有，再读数据源，然后将数据放入缓存，再响应请求。
- 写数据：先写数据源，然后失效缓存。
这种模式的关键在于：
- 先后顺序：必须先写数据源后失效缓存。如果先失效缓存后写数据源，可能在缓存失效和数据源更新之间存在时间窗口，此时新的查询请求会读到旧的数据并重新填充到缓存中，导致数据不一致。
- 失效缓存：而不是尝试更新缓存，因为更新过程中数据源可能会被其他请求再次修改，处理多次赋值的时序问题非常复杂。失效缓存可以避免这种情况，确保下次读取时自动回填最新的数据。
Read/Write Through：
- 读数据：先读缓存，如果没有，再读数据源，并将数据写入缓存。
- 写数据：先写缓存，再写数据源。
这种模式保证了缓存和数据源的一致性，但实现起来比较复杂，可能会带来性能开销。
Write Behind Caching：
- 读数据：先读缓存，如果没有，再读数据源，并将数据写入缓存。
- 写数据：先写缓存，然后异步地将数据写入数据源。
这种模式通过异步更新数据源，提高了写操作的性能，但在数据源更新的延迟期间，可能会导致数据不一致。

Cache Aside 模式的局限性

Cache Aside 模式虽然简洁且成本低，但依然不能完全保证一致性。例如，当某个从未被缓存的数据请求直接流到数据源，如果数据源的写操作发生在查询请求之后但回填到缓存之前，缓存中回填的内容可能与数据库的实际数据不一致。然而，这种情况的发生概率较低，Cache Aside 模式仍然是一个低成本且相对可靠的解决方案。

通过以上设计模式，可以在一定程度上减少缓存污染，确保缓存与数据源之间的一致性，但完全避免是不现实的，特别是在高并发和复杂业务场景下。