缓存问题“三件套“------- 雪崩，击穿与穿透

互联网应用的主要挑战就是在高并发情况下，大量的用户请求到达应用系统服务器，造成了巨大的计算压力。互联网应用的核心解决思路就是采用分布式架构，提供更多的服务器，从而提供更多的计算资源，以应对高并发带来的计算压力及资源消耗。除了通过提供更多的服务器，来分担压力，那么能不能通过减少到达服务器的并发请求，来减少服务器的压力呢？或者请求到达服务器后，有没有办法减少不必要的计算，降低服务器的计算资源消耗，尽快返回计算结果给用户呢？有，解决的核心就是缓存。

缓存是后端开发中，经常用到的一种技术，缓存的存储介质读写效率都比较高，使用缓存可以加快对数据的读写，使用缓存主要用来加速我业务处理：把一些计算过程比较繁琐的结果数据或者读写效率比较低的存储介质上的数据，放到缓存中，这样当再次使用这些数据的时候，就可以直接从缓存中获取了，而不用再通过复杂的重复计算了，可以大大提高请求的处理速度。应用系统中使用缓存的常用架构，如下图所示：

凡事有利有弊，引入了缓存后，系统可以处理的qps也会大幅度增加，可以处理的流量，远远超出了系统本身能承受的流量，因为绝大部分的请求都被缓存处理了。但是引入缓存后，会使系统变得更加的复杂，系统中，出现问题的地方也会变多。如果缓存出了问题，那么超出系统本身可以承载的流量，会直接打到系统中，系统因无法处理，而产生崩溃宕机等严重问题。

那么下面我们就以redis缓存为例，来看一下，缓存产生的哪些问题，会使系统承载的流量变大，导致系统崩溃。

一、缓存雪崩

1、什么是缓存雪崩

大量的应用请求在缓存中无法得到处理，然后这些请求发送到了数据库中。导致数据库压力瞬间激增，对于数据库来说，产生的影响像发生了"雪崩"一样，影响非常严重，甚至可以直接导致数据库崩溃。如下图所示：

2、产生的原因

1.缓存雪崩产生的主要原因是缓存系统中存在大量的key同时失效。
2.redis实例宕机，导致redis无法对外提供服务。

3、应对方案

1.如果产生雪崩的问题是大量key同时失效导致的，应对方案，可以分为事前预防和问题发生后的紧急处理：

事前的预防手段，在雪崩问题产生前，可以采用的防御措施：对key设置过期时间时，过期时间尽量不要设置的过于集中，在设置过期时间时，添加一个随机数，让key过期失效的时间点，尽量不一致。具体可以参考一下伪代码：

setRedis（Key，value，time + Math.random() * 10000）

事前的防御手段可以尽量避免问题的产生，但当问题真的产生后，该怎么处理呢，这时候，就需要事后的处理方案了。

当雪崩问题产生后对于数据库系统来说，来了大流量，在评估数据库无法完全处理这些流量时，这是有两种策略可以选择：

1.限流：可以实现对全部流量进行抽样，使真正进入到数据库的流量为全部流量中的一部分，这样数据库接受的流量就会变得很小了。给用户带来的体验就是：系统时好时坏。不过随着后端数据库对请求处理后，会将数据不断的加载到缓存中，数据库的压力也在不断变小，此时可以逐步调整限流采样的粒度，直至缓存正常提供服务，然后停止限流。
2.降级：降级主要是对流量进行分类，根据业务类型，把流量分成不同的优先级，让数据库系统，只处理优先级高的流量，对于优先级低的流量，不进行处理，或者只做默认处理，返回默认值，这样可以保证核心业务请求不受影响，当数据不断加载到缓存中后，数据库的压力也在不断的变小，被降级的流量也可以从降级变成限流，然后逐步降低限流的程度，直至缓存系统修复正常。

关于限流和降级的详细介绍可以参考啥？学习微服务，你竟然不知道什么是熔断，降级和限流

2.如果是redis实例宕机导致的缓存雪崩的情况，应对方案也可以分为事前的预防 和问题发生后的紧急处理。

1.缓存雪崩产生前：
可以调整redis实例架构，避免redis实例出现单点故障，使用主从结构，切片集群的方式，提高缓存的可用性。

2.缓存雪崩产生后：
因为缓存系统宕机，导致雪崩问题的产生，那么此时从数据库中读取的结果也无法加载缓存中，如果缓存系统，无法重启提供服务的话，那么降级，限流的方案，都无法使缓存系统的缓存能力慢慢恢复。针对这种情况，最重要的是如何快速的将缓存系统启动。

二、缓存击穿

1、什么是缓存击穿

缓存击穿：针对某个访问非常频繁的热点数据，突然在缓存中失效了。那么针对这个数据的请求流量会发送到数据库，导致数据库压力激增，就像一个水桶上凿出一个洞一样，好巧不巧，通过这个洞漏出的水，又特别急。如下图所示：

2、产生的原因

1.热点key在缓存系统中，到了过期时间，数据失效。

2.业务误操作，数据被删除。

3、解决方案

解决方案可以分为事前预发和事后处理两种方式：

1.对热点数据不设置过期时间，这样就可以保证这些数据永远有效。这种方式是一种事前预防的方案，可以避免该问题产生。

2.当缓存击穿问题产生后，常用的解决方案是采用限流，采用限流主要可以减少打进数据库请求流量，防止数据库被打死，同时通过对少量请求的处理，可以从数据库中将数据不断的加载到缓存中，使缓存击穿的问题得到解决，然后逐步撤销限流。

三、缓存穿透

1、什么是缓存穿透

缓存穿透：请求在缓存和数据库都无法进行处理，也就是请求的数据在缓存和数据库中都不存在的场景。重点强调的是"穿透"，这里的穿透是指穿透数据库。这里没有像缓存雪崩，缓存击穿这两种问题，会导致后端数据库产生较大的压力，但是会导致对该请求的处理效率比较低，而且每次请求都很慢。如下图所示：

2、产生的原因

产生缓存穿透的主要原因有两个：

1.业务层误删除，导致请求的数据在缓存和数据库中都不存在。

2.恶意攻击，蓄意访问数据库中不存在的数据。

3、解决方案

缓存穿透的解决方案也可以分为事前预防和事后处理两种方式：

1.使用布隆过滤器可以快速判断数据是否存在，避免数据不存在的请求直接发送到缓存系统，然后再传播到了数据库。布隆过滤器的主要原理是，计算每个请求的特征值，然后在布隆过滤器的存储模块中查询该特征值是否存在，由于特征值的计算通常采用的是hash散列的方式，会存在hash冲突，导致不同的数据，特征值相同的情况。体现在布隆过滤器上，就是数据验证不准确的问题，具体就是：布隆过滤器判断数据存在时，这个数据不一定存在，判定数据不存在时，数据一定不存在。当利用布隆过滤器判断数据存在的时候，应用程序还是需要在缓存中或者数据库中查询一下，经过查询可能存在数据查不到的情况，也就是缓存穿透，但是这种情况，经过过滤后，会变成是小概率事件，布隆过滤器会将大部分的"缓存穿透"情况过滤掉。

2.对于数据库中不存在的数据，可以在redis中针对某个key，缓存一个特殊值。这个特殊值，对于缓存而言：请求的数据可以得到处理，防止请求传递到后端数据库，对于请求方而言，当收到特殊值的响应，可以针对性的处理。

四、三者的差异

对于数据库而言，缓存击穿和缓存雪崩带来的影响相似，都会使数据库的压力激增。对于redis而言，两者都是因为数据不存在，无法处理对客户端请求。两者的差异在于：缓存失效的数据个数不同，缓存雪崩重点是：大量数据失效。缓存击穿重点是：访问频繁的热点数据失效。但是这两种问题，通常可以通过将数据库中的数据加载达到缓存中，来达到慢慢"自愈"效果。

而对于缓存穿透来说，其对数据库的影响，相比前两者更小一些，其主要的问题在于，要查询的数据在缓存和数据库中都不存在，每次请求都要对缓存和数据库进行查询，请求处理效率低，如果不对要查询的数据进行新增处理，那么缓存穿透问题将一直无法"自愈"。