一张图弄清楚缓存架构设计中的经典问题及解决方案-技术圈

下面这张图非常形象的描述了缓存设计中几个容易混淆的概念：缓存击穿、缓存穿透、缓存雪崩，并给出了相应的解决方案。

Cache Penetration

概述

Cache penetration( 缓存穿透 ) ：缓存穿透是指大量请求查询系统中不存在的数据如通过不存在的 UID 访问用户，既然这些数据在系统中不存在，那么肯定在Redis缓存中也不存在这批数据，这样导致这些请求都会穿透到DB，导致系统崩溃。有些同学可能就会问了，既然系统中都没这些数据，为什么还会存在这样的请求了？别忘了，这个世界上还有一群计算机破坏分子，他们可能基于各种目的，伪造这样的请求去攻击你的系统。

解决方案

方案一： 缓存不存在的key，即使key对应的数据系统中不存在，也将该key缓存下，只不过这个 key 对应的 value 是一个特殊设置的值。这样即使访问不存在的key时也会命中缓存返回，不会再去DB中获取了。

该方案缺陷：如果访问的是大量不存在的key，很显然，为了缓存这些系统中不存的key，会占用大量的缓存空间，而我们知道缓存空间是有限的，无效key占用的空间多了，势必会将一些正常的key淘汰掉，这样就导致缓存命中率下降。

方案二： 构建一个 BloomFilter 过滤器，记录全量数据，这样访问数据时，可以直接通过 BloomFilter 判断这个key 是否存在，如果不存在直接返回即可（BloomFilter特性：如果判断不存在则一定不存在），根本无需查缓存和 DB。

该方案缺陷：BloomFilter 要缓存全量的 key，这就要求全量的 key数量不能太大，30亿条数据以内最佳（30亿条数据大约会占5GB左右）。

Cache Breakdown

概述

Cache Breakdown( 缓存击穿 )：缓存击穿是指一个热门缓存key突然失效，导致大量请求直接访问到DB,导致系统崩溃。与后面描述的缓存雪崩不同的是，缓存击穿通常是某个特定的缓存键失效。可以这样说：缓存击穿是某个或者少数几个key的行为，而缓存雪崩则是一群key的狂欢。

解决方案

方案： 对于一个缓存系统来说，热门key毕竟是少数，因此解决方法也比较直接，对于访问特别频繁的热点数据，我们干脆就不设置过期时间了。这样一来，对热点数据的访问请求，都可以在缓存中进行处理，

Cache Crash

概述

Cache Crash(缓存雪崩)：缓存雪崩是指缓存中的大量数据同时失效或者同时被删除，导致大量请求穿透到DB，造成系统崩溃。造成缓存中的大量数据同时失效或者同时被删除的原因主要有： 1、缓存服务器宕机。

2：缓存数据的过期时间设置不合理，导致大量数据在同一时间失效(对应图中Thunder Hurd Problem)。

解决方案

方案一： 避免给大量的数据设置相同的过期时间。如果业务层的确要求有些数据同时失效，你可以在用 EXPIRE 命令给每个数据设置过期时间时，给这些数据的过期时间增加一个较小的随机数，这样一来，不同数据的过期时间有所差别，但差别又不会太大，既避免了大量数据同时过期，同时也保证了这些数据基本在相近的时间失效，仍然能满足业务需求。

方案二： 对于非核心业务，通过服务降级，来应对缓存雪崩。如对业务 DB 的访问增加读写开关，当发现 DB 请求变慢、阻塞，慢请求超过阀值时，就会关闭读开关，不允许再访问数据库，直接返回预定义信息、空值或是错误信息；这样一来，只有部分过期数据的请求会发送到数据库，数据库的压力就没有那么大了。

方案三： 缓存集群高可用部署，同时对缓存集群进行实时监控，尽量做到缓存服务器少宕机或者宕机之后可以及时迅续恢复。

实际生产项目中，上述三种方案是同时并存，这样才能最大程度的保护系统。