缓存穿透、缓存击穿、缓存雪崩看这篇就够了，文末还送福利哦！

码农神说

修改于 2020-08-09 09:01:05

6430

修改于 2020-08-09 09:01:05

文章被收录于专栏：码农神说

当我们进行架构设计时，缓存是提高高性能的最重要也是最常用的组件之一。数据库的瓶颈在于磁盘I/O，虽然现如今关系数据库的部分应用场景采用了NoSQL作为替代，但依然没能摆脱磁盘I/O的性能问题。缓存的妙处就是在提高性能的同时，也保护了下游数据库，避免I/O压力过大导致宕机。

常用的缓存有单机版的EhCache、分布式版的Memcache和Redis，都属于K-V类型的存储，Key与Value一一对应。当然如果较真的话他们也属于NoSQL范畴，比如Redis弥补了关系数据不能存储结构数据的缺憾。虽然这些缓存中间件已经非常成熟和稳定，也得到了广泛的应用，但设计一个良好的缓存系统还是会遇到很多问题需要解决、方案也需要取舍。

缓存的应用场景

每一个技术或中间件都有自己的应用场景，在这些场景中可以发挥它最大的优势。如果不熟悉他们的应用场景，愣是生搬硬套，只会事倍功半，南辕北辙。缓存的应用场景有如下几种：

高频访问的数据：限于磁盘I/O的瓶颈，对于高频访问的数据，需要缓存起来提高性能，降低下游数据库的压力冲击；
复杂运算的结果：对于需要耗费CPU、经过复杂运算才能获得的结果，需要缓存来，做到“一劳长时间逸"，如count(id)统计论坛在线人数；
读多写少：每次读都需要select甚至join很多表，数据库压力大，由于写得少，容易做到数据的一致性，非常适合缓存的应用；
一致性要求低：由于缓存的数据来源于数据库，在高并发时数据不一致性就比较凸显，不一致的问题可以解决但代价不菲；

本篇主要来讲讲架构设计中的缓存穿透、缓存击穿、缓存雪崩产生的原因和缓解措施，技术来不得半点含糊，要知其然知其所以然。

缓存穿透 Cache Penetration

缓存穿透是指数据库中没有符合条件的数据，缓存服务器中也就没有缓存数据，导致业务系统每次都绕过缓存服务器查询下游的数据库，缓存服务器完全失去了其应用的作用。如果黑客试图发起针对该key的大量访问攻击，数据库将不堪重负，最终可能导致崩溃宕机。从上图可以看出直接穿过缓存到达下游数据库，大致业务流程如下

可采取的缓解措施

1.存储空值/默认值

虽然数据库中没有符合条件的数据，可以考虑缓存空值或适合业务的默认值，来缓解这种情况。为了降低数据的不一致需要注意两点：1. 缓存的过期时间需要设置的比较短；2. 当数据库数据更新时也需要及时更新缓存中对应的数据。

2.布隆过滤器(Bloom Filter)

布隆过滤器是一种比较巧妙的概率性数据结构，它可以告诉你数据一定不存在或可能存在，相比Map、Set、List等传统数据结构它占用内存少、结构更高效。比如有一个下面这样的数据结构，每个存储位存储的都是一个big，即0或1

当我们向缓存中插入key为name的缓存数据时，先使用N种不同的hash函数做N次hash得到N个哈希值，在上面的数据结构中找到对应哈希值的下标，并把存储数据设置为1。假如N=3，我们可以使用hash1、hash2、hash3分别计算出了哈希值为8，15和13，则将其对应下标的数据设置为1，如下图

此时你如果想判断一个缓存key是否存在，就采用同样的l流程：3次hash、根据哈希值寻找下标、取出存储的数据。如果存储的数据不全都是1，也就意味着缓存中不存在此key，但都是1也只表示可能存在。不过没关系，我们只需要否定的意图就能达到目标了(O ^ ~ ^ O)。

以上两种缓解措施在不同的应用场景可以做些适当的选择：如果访问量大可以使用第一种方案简单粗暴；如果访问量低但涉及的key比较多，则可采用第二种方案。

缓存击穿 Cache Breakdown

缓存击穿是指当某一key的缓存过期时大并发量的请求同时访问此key，瞬间击穿缓存服务器直接访问数据库，让数据库处于负载的情况。

缓存击穿一般发生在高并发的互联网应用场景，可采用的如下的缓解措施

1.锁更新

可以使用(分布式)锁，只让一个线程更新key，其他线程等待，直到缓存更新释放锁。比如简单粗暴的synchronized关键字

public synchronized String getCacheData() {
  String cacheData = "";
  //Read redis
  cacheData = getDataFromRedis();
  if (cacheData.isEmpty()) {
    //Read database
    cacheData = getDataFromDB();
    //Write redis
    setDataToCache(cacheData);
  }
  return cacheData;
}

但synchronized这个锁太宽泛，会造成大量的请求阻塞，性能极低，进一步优化缩小锁的范围

static Object lock = new Object();

public String getCacheData() {
  String cacheData = "";
  //Read redis
  cacheData = getDataFromRedis();
  if (cacheData.isEmpty()) {
    synchronized (lock) {
      //Read database
      cacheData = getDataFromDB();
      //Write redis
      setDataToCache(cacheData);
    }
  }
  return cacheData;
}

学无止境，还可以继续优化，使用互斥锁 (✧◡✧)：得到锁的线程就读数据写缓存，没得到锁的线程可以不用阻塞，继续从缓存中读数据，如果没有读到数据就休息会再来试试。

public String getCacheData(){
  String result = "";
  //Read redis
  result = getDataFromRedis();
  if (result.isEmpty()) {
    if (reenLock.tryLock()) {
      try {
        //Read database
        result = getDataFromDB();
        //Write redis
        setDataToCache(result);
      }catch(Exception e){
        //...
      }finally {
        reenLock.unlock (); // release lock
      }
    } else {
      //Note: this can be combined with the 
      // following double caching mechanism:

      //If you can't grab the lock, 
      // query the secondary cache

      //Read redis
      result = getDataFromRedis();
      if (result.isEmpty()) {
        try {
          Thread.sleep(100);
        } catch (InterruptedException e) {
          //...
        }
        return getCacheData();
      }
    }
  }
  return result;
}

2.异步更新

还有个可行的方案就是把缓存设置为永久不过期，异步定时更新缓存。比如后台有个值守线程专门定时更新缓存，但一般还要定时频繁地去检测缓存，一旦发现被踢掉(比如被缓存的失效策略FIFO、LFU、LRU等)需要立刻更新缓存，但这个“定时”的度是比较难掌握的，实现简单但用户体验一般。

异步更新机制还比较适合缓存预热，缓存预热是指系统上线后，将相关的缓存数据直接加载到缓存系统，避免在用户请求时才缓存数据，提高了性能。

缓存雪崩 Cache Avalanche