作者丨我一定会有猫的
https://juejin.im/post/5b604b9ef265da0f62639001
1. 缓存来由
随着互联网系统发展的逐步完善，提高系统的qps，目前的绝大部分系统都增加了缓存机制从而避免请求过多的直接与数据库操作从而造成系统瓶颈，极大的提升了用户体验和系统稳定性。
2. 缓存问题
虽然使用缓存给系统带来了一定的质的提升，但同时也带来了一些需要注意的问题。
2.1 缓存穿透
缓存穿透是指查询一个一定不存在的数据，因为缓存中也无该数据的信息，则会直接去数据库层进行查询，从系统层面来看像是穿透了缓存层直接达到db，从而称为缓存穿透，没有了缓存层的保护，这种查询一定不存在的数据对系统来说可能是一种危险，如果有人恶意用这种一定不存在的数据来频繁请求系统，不，准确的说是攻击系统，请求都会到达数据库层导致db瘫痪从而引起系统故障。
2.2 解决方案
缓存穿透业内的解决方案已经比较成熟，主要常用的有以下几种：
bloom filter：类似于哈希表的一种算法，用所有可能的查询条件生成一个bitmap，在进行数据库查询之前会使用这个bitmap进行过滤，如果不在其中则直接过滤，从而减轻数据库层面的压力。guava中有实现BloomFilter算法
空值缓存：一种比较简单的解决办法，在第一次查询完不存在的数据后，将该key与对应的空值也放入缓存中，只不过设定为较短的失效时间，例如几分钟，这样则可以应对短时间的大量的该key攻击，设置为较短的失效时间是因为该值可能业务无关，存在意义不大，且该次的查询也未必是攻击者发起，无过久存储的必要，故可以早点失效。
2.3 缓存雪崩
在普通的缓存系统中一般例如redis、memcache等中，我们会给缓存设置一个失效时间，但是如果所有的缓存的失效时间相同，那么在同一时间失效时，所有系统的请求都会发送到数据库层，db可能无法承受如此大的压力导致系统崩溃。
2.4 解决方案
线程互斥：只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据才可以，每个时刻只有一个线程在执行请求，减轻了db的压力，但缺点也很明显，降低了系统的qps。
交错失效时间：这种方法时间比较简单粗暴，既然在同一时间失效会造成请求过多雪崩，那我们错开不同的失效时间即可从一定长度上避免这种问题，在缓存进行失效时间设置的时候，从某个适当的值域中随机一个时间作为失效时间即可。关注Java技术栈微信公众号，在后台回复关键字：缓存，可以获取更多栈长整理的缓存系列技术干货。
2.5 缓存击穿
缓存击穿实际上是缓存雪崩的一个特例，大家使用过微博的应该都知道，微博有一个热门话题的功能，用户对于热门话题的搜索量往往在一些时刻会大大的高于其他话题，这种我们成为系统的“热点“，由于系统中对这些热点的数据缓存也存在失效时间，在热点的缓存到达失效时间时，此时可能依然会有大量的请求到达系统，没有了缓存层的保护，这些请求同样的会到达db从而可能引起故障。击穿与雪崩的区别即在于击穿是对于特定的热点数据来说，而雪崩是全部数据。
2.6 解决方案
二级缓存：对于热点数据进行二级缓存，并对于不同级别的缓存设定不同的失效时间，则请求不会直接击穿缓存层到达数据库。
这里参考了阿里双11万亿流量的缓存击穿解决方案，解决此问题的关键在于热点访问。由于热点可能随着时间的变化而变化，针对固定的数据进行特殊缓存是不能起到治本作用的，结合LRU算法能够较好的帮我们解决这个问题。那么LRU是什么，下面粗略的介绍一下，有兴趣的可以点击上面的链接查看.
LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。最常见的实现是使用一个链表保存缓存数据，如下图所示
这个链表即是我们的缓存结构，缓存处理步骤为
首先将新数据放入链表的头部
在进行数据插入的过程中，如果检测到链表中有数据被再次访问也就是有请求再次访问这些数据，那么就其插入的链表的头部，因为它们相对其他数据来说可能是热点数据，具有保留时间更久的意义
最后当链表数据放满时将底部的数据淘汰，也就是不常访问的数据
LRU-K算法 ，其实上面的算法也是该算法的特例情况即LRU-1，上面的算法存在较多的不合理性，在实际的应用过程中采用该算法进行了改进，例如偶然的数据影响会造成命中率较低，比如某个数据即将到达底部即将被淘汰，但由于一次的请求又放入了头部，此后再无该数据的请求，那么该数据的继续存在其实是不合理的，针对这类情况LRU-K算法拥有更好的解决措施。结构图如下所示：
LRU-K需要多维护一个队列或者更多，用于记录所有缓存数据被访问的历史。只有当数据的访问次数达到K次的时候，才将数据放入缓存。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。关注Java技术栈微信公众号，在后台回复关键字：缓存，可以获取更多栈长整理的缓存系列技术干货。
第一步添加数据照样放入第一个队列的头部
如果数据在该队列里访问没有达到K次（该数值根据具体系统qps来定）则会继续到达链表底部直至淘汰；如果该数据在队列中时访问次数达到了K次，那么它会被加入到接下来的2级(具体需要几级结构也同样结合系统分析)链表中，按照时间顺序在2级链表中排列
接下来2级链表中的操作与上面算法相同，链表中的数据如果再次被访问则移到头部，链表满时，底部数据淘汰
相比LRU，LRU-K需要多维护一个队列，用于记录所有缓存数据被访问的历史，所以需要更多的内存空间来用来构建缓存，但优点也很明显，较好的降低了数据的污染率提高了缓存的命中率，对于系统来说可以用一定的硬件成本来换取系统性能也不失为一种办法。当然还有更为复杂的缓存结构算法，点击LRU算法即可学习，例如Two Queues和Mutil Queues等等，本文不过多赘述，只为读者提供一种解决思路。
关注Java技术栈微信公众号，在后台回复关键字：缓存，可以获取更多栈长整理的缓存系列技术干货。
缓存的设计包含很多技巧，设计不当将会导致严重的后果。本文将介绍缓存使用中常见的三大问题，并给出相应的解决方案。
- 缓存穿透
- 缓存雪崩
- 缓存击穿
1. 缓存穿透
在大多数互联网应用中，缓存的使用方式如下图所示：
当业务系统发起某一个查询请求时，首先判断缓存中是否有该数据；
如果缓存中存在，则直接返回数据；
如果缓存中不存在，则再查询数据库，然后返回数据。
了解了上述过程后，下面说说缓存穿透。
1.1 什么是缓存穿透？
业务系统要查询的数据根本就存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。
综上所述：业务系统访问压根就不存在的数据，就称为缓存穿透。
1.2 缓存穿透的危害
如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃（你要知道，目前业务系统中最脆弱的就是IO，稍微来点压力它就会崩溃，所以我们要想种种办法保护它）。
1.3 为什么会发生缓存穿透？
发生缓存穿透的原因有很多，一般为如下两种：
恶意攻击，故意营造大量不存在的数据请求我们的服务，由于缓存中并不存在这些数据，因此海量请求均落在数据库中，从而可能会导致数据库崩溃。
代码逻辑错误。这是程序员的锅，没啥好讲的，开发中一定要避免！
1.4 缓存穿透的解决方案
下面来介绍两种防止缓存穿透的手段。
1.4.1 缓存空数据
之所以发生缓存穿透，是因为缓存中没有存储这些空数据的key，导致这些请求全都打到数据库上。
那么，我们可以稍微修改一下业务系统的代码，将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库。
缓存空对象会有两个问题：
第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
1.4.2 BloomFilter
第二种避免缓存穿透的方式即为使用BloomFilter。
它需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key，如下图所示：
当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。
这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。
1.4.3 两种方案的比较
这两种方案都能解决缓存穿透的问题，但使用场景却各不相同。
对于一些恶意攻击，查询的key往往各不相同，而且数据贼多。此时，第一种方案就显得提襟见肘了。因为它需要存储所有空数据的key，而这些恶意攻击的key往往各不相同，而且同一个key往往只请求一次。因此即使缓存了这些空数据的key，由于不再使用第二次，因此也起不了保护数据库的作用。
因此，对于空数据的key各不相同、key重复请求概率低的场景而言，应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言，应该选择第一种方案。
2. 缓存雪崩
2.1 什么是缓存雪崩？
通过上文可知，缓存其实扮演了一个保护数据库的角色。它帮数据库抵挡大量的查询请求，从而避免脆弱的数据库受到伤害。
如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。
这就是缓存雪崩。
2.2 如何避免缓存雪崩？
2.2.1 使用缓存集群，保证缓存高可用
和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2.2.2 使用Hystrix
Hystrix是一款开源的“防雪崩工具”，它通过 熔断、降级、限流三个手段来降低雪崩发生后的损失。
Hystrix就是一个Java类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix将会拒绝随后该服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后，Hystrix会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。
3. 缓存击穿（热点数据集中失效）
3.1 什么是热点数据集中失效？
我们一般都会给缓存设定一个失效时间，过了失效时间后，该数据库会被缓存直接删除，从而一定程度上保证数据的实时性。
但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。其过程如下图所示：
如果某一个热点数据失效，那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是，从请求发往数据库，到该数据更新到缓存中的这段时间中，由于缓存中仍然没有该数据，因此这段时间内到达的查询请求都会落到数据库上，这将会对数据库造成巨大的压力。此外，当这些请求查询完成后，都会重复更新缓存。
3.2 解决方案
3.2.1 互斥锁
此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可，整个过程如图 :
当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。
当某一个热点数据失效后，只有第一个数据库查询请求发往数据库，其余所有的查询请求均被阻塞，从而保护了数据库。但是，由于采用了互斥锁，其他请求将会阻塞等待，此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。
互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题，而在实际业务中，往往会存在一批热点数据同时失效的场景。那么，对于这种场景该如何防止数据库过载呢？
设置不同的失效时间
当我们向缓存中存储这些数据的时候，可以将他们的缓存失效时间错开。这样能够避免同时失效。如：在一个基础时间上加/减一个随机数，从而将这些缓存的失效时间错开
3.3.2 永远不过期
“永远不过期”包含两层意思：
从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期。
从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。
整个过程如下图所示：
从实战看，此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。
3.3.3 两种方案的比较
互斥锁 (mutex key)：这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
” 永远不过期 “：这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。