常见的缓存问题和解决方案

一、使用redis作为缓存

1、概述

缓存可以有效提高查询速度，但是由于缓存的时限以及非法的操作，导致缓存系统会出现三个问题
1、缓存穿透
2、缓存雪崩
3、缓存击穿
4、缓存预热

2、实际开发使用

大部分互联网应用当中，缓存的使用方式如下所示：

3、调用流程

1. 当业务系统发起某一个查询请求时，首先判断缓存中是否有该数据；
2. 如果缓存当中存在，则直接返回数据；
3. 如果缓存当中不存在，则查询数据库，将返回的结果保存到缓存当中，同时返回给业务系统

二、四大问题解析

一、缓存击穿

1、概念

我们一般都会给缓存数据设定一个失效时间，过了失效时间后，该数据会被缓存删除，从而在一定程度上保证了数据的实时性。
但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻会有大量请求落在了数据库上，从而可能会导致数据库崩溃。其过程如下图所示

如果某一个热点数据失效，那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是，从请求发往数据库，到该数据更新到缓存中的这段时间中，由于缓存中仍然没有该数据，因此这段时间内到达的查询请求都会落到数据库上，这将会对数据库造成巨大的压力。此外，当这些请求查询完成后，都会重复更新缓存。

2、解决方法

1、互斥锁

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。
当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。

当某一个热点数据失效后，只有第一个数据库查询请求发往数据库，其余所有的查询请求均被阻塞，从而保护了数据库。但是，由于采用了互斥锁，其他请求将会阻塞等待，此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。

互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题，而在实际业务中，往往会存在一批热点数据同时失效的场景。那么，对于这种场景该如何防止数据库过载呢？

设置不同的失效时间
当我们向缓存中存储这些数据的时候，可以将他们的缓存失效时间错开。这样能够避免同时失效。如：在一个基础时间上加/减一个随机数，从而将这些缓存的失效时间错开

2、永远不过期

永远不过期”包含两层意思： 
从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期。 
从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存

从实战看，此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。

3、方案对比

1. 互斥锁 (mutex key)：这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
2. ” 永远不过期 “：这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

二、缓存雪崩

1、概念

通过上文流程，我们可以知道，缓存其实扮演了一个保护数据库的角色，它帮助数据库抵挡了大量的查询操作，从而避免数据库的IO使用率提高到不可控程度，导致宕机。
如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会全部落在了数据库当中。这时候，如果数据库无法支撑这么大的查询请求压力，则有可能会导致数据宕机。
这就是缓存雪崩

2、解决方法

1、使用缓存集群，保证缓存高可用

如果缓存设计成高可用的，即使个别节点、个别机器、甚至时机房宕掉，也还是可以提供服务。只要集群当中还有集群在充当缓存的角色，那么系统还是可以正常运行。

2、使用Hystrix

Hystrix是一款开源的“防雪崩工具”，它通过 熔断、降级、限流三个手段来降低雪崩发生后的损失。
	Hystrix就是一个Java类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各
自的处理器。
	处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix将会拒绝随后该
服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。
	当经过一段时间后，Hystrix会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合
预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。
	而Hystrix向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。

三、缓存穿透

1、概念

业务系统要查询的数据根本不存在！当业务系统发起查询时，按照上输流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库钟查村。由于该数据根本上就不存在，因为数据库也返回空，这就是缓存穿透。
综上所述：业务系统访问呀本就不存在的数据，或者由于恶意伪造访问请求导致的业务系统异常请求，就成为缓存穿透

2、危害

如果存在海量请求查询压根就不存在的数据，那么就写海量请求都会落到数据库钟，导致数据库压力剧增，可能会导致系统崩溃。

3、为什么会发生缓存穿透

发生缓存穿透的原因有很多，一般为如下两种：

1. 恶意攻击，故意营造大量不存在的数据请求我们的服务，由于缓存中并不存在这些数据，因为海量请求均落在数据库中，从而可能会导致数据库崩溃。
2. 代码逻辑错误。这个是业务编码的问题。

4、缓存穿透的解决方案

下面来介绍几种防止缓存击出的手段

1、缓存空数据

之所以发生缓存穿透，是因为缓存当中没有存储这些控数据的key，导致这些请求全部落在了数据库上。
那么我们可以对缓存的业务代码进行改动，将数据库查询结果为空的key也存储在缓存当中。当后续又出现该key的查询请求时，缓存直接返回努力了，从而无需查询数据库

缓存空对象会有两个问题： 
第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。 
第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2、布隆过滤器

第二种避免缓存穿透的方式即使用BloomFilter

它需要在缓存之前再加一道判断逻辑，即将数据库当中存储的所有的key都存到BloomFilter当中。

当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。
这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。 

3、暴力解决方法

正常逻辑上，我们都是根据ID来作为key去数据库当中获取数据。而key的值范围一般都不会是负数。在业务代码当中事先判断id值的合法性。若是负数，则进行不进行后续操作即可。

5、前两种方法比对

这两种方案都能解决缓存穿透的问题，但使用场景却各不相同。

对于一些恶意攻击，查询的key往往各不相同，而且数据贼多。此时，第一种方案就显得提襟见肘了。因为它需要存储所有空数据的key，而这些恶意攻击的key往往各不相同，而且同一个key往往只请求一次。因此即使缓存了这些空数据的key，由于不再使用第二次，因此也起不了保护数据库的作用。
因此，对于空数据的key各不相同、key重复请求概率低的场景而言，应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言，应该选择第一种方案。

四、缓存预热

1、概念

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

2、方案借鉴

1. 直接写个缓存刷新页面，上线时手工操作下；
2. 数据量不大，可以在项目启动的时候自动进行加载；
3. 定时刷新缓存；

PS：图片直接从网络上摘取，如有侵权，请及时联系我。