故事
对于小猫来讲，最近的一段日子是不好过的，纵使听着再有节拍的音乐，也换不起他对生活的热情。由于上一次“幂等事件”躺枪，他已经有几天没有休息好了。他感觉人生到了低谷。
当接手这个商城项目之后，他感觉他一直没有好过。他的内心彷徨，在工位上边写着事故报告，边嘀咕着“今年到底是犯了啥冲...为什么...”
然而屋漏又遭连夜雨，船破偏遇当头风，好像坏事儿又找上了他。
坐他旁边的哥们在一旁抱怨，“啥情况，我就想给公司助助力，买点咱自家公司的产品，咋商详页咋点来点去进不了，你看看你的呢？”。
“你自己手机不行了吧，你瞧你那老破烂也该换了，iphone15 pmax搞起...” 旁边的老六开涮道。
然而却触动了小猫的神经，他赶紧打开app，发现自己的也进不去了。他赶紧打开Grafana，脸色苍白，口干舌燥....数据库连接全部打满。
不到一会组长的电话也收到了客服反馈的客诉，组长向小猫投来质疑的目光。
小猫无辜而又无奈：“我真的没有动过代码......”。
经过一轮彻彻底底地摸排，事情的原因也终于水落石出。
大概如下图这么回事儿：
流程
上次A公司对接商城服务之后开始在他们商城平台推拼团售卖活动，活动中的几个商品的缓存被删除之后没有恢复，原因是因为第三方对接的API商品大量推送，队列有堆积，导致redis缓存并没有及时更新。大批量的用户在进行购买活动商品的时候，请求全部打到了DB上。
反正也不晓得是哪个挨千刀的设计的技术方案，缓存到redis中的时候用的居然是异步消息队列。商品发布量小，访问量小的时候可能没有什么问题。
但是偏偏各种巧合发生在了一起就产生了这样一个事故，这可能就是所谓的墨菲定律吧。
小猫已经走到了绝望的边缘......（下次就不说小猫踩坑了，让他缓几天，哈哈）
二、聊聊缓存击穿
在此我们对小猫表示同情，但是这是一个很好的例子，老猫还是和大家一起聊聊缓存击穿雪崩的话题。
咱们就从以下几个方面聊聊缓存雪崩击穿的问题。
概览图
在上图中可以看见，我们会对布隆过滤器做一个重点的介绍，因为这个也是比较常用的方式缓存击穿的方式。
1.什么是缓存击穿？是什么原因导致的？
从上面小猫的案例中，其实就已经很明了了，所谓缓存击穿就是原本由于缓存组件抗住的流量结果全部打到了数据库层，给数据库带来了巨大的压力，甚至严重的情况下直接把数据库干跨。导致缓存失效的原因也是很显然易见的，由于缓存在一个无法预期的一个场景下缓存失效了。
在小猫的案例中可以看到是热卖的商品在redis中Key值全部同时失效导致的。当然这是一种常见的技术方案有问题导致的。那么还有一种导致缓存失效的原因就是缓存中间件直接宕机。这种情况是运维层面需要解决的，可能要求对缓存中间件做好高可用，如何做高可用，我们在此不做深究。
下面是咱们的缓存用法，大家可以看一下下面的流程。
缓存流程
从上述的流程图中我们可以看到，当有请求过来的时候，首先会尝试从缓存中去读取，当缓存中没有读到的时候，这个时候咱们就会回源到数据库再次查找，当查到相关商品数据之后返回给客户端，之后并将该数据继续缓存到数据库中。
接下来咱们来看一下发生雪崩之后的解决方案。
2.无效key值处理
这种情况其实很简单了，既然由于没有在缓存数据库中找到数据，那么咱们也不应该直接将redis中那些Key值直接删除，这样找不到key的话，肯定还是会打到数据库，所以我们只要避免请求去查数据库就可以了。所以我们就把无效的Key也保存到redis中即可。这种值的话，我们都保存成“null”。这样的话redis中的key一定就是全量的了，客户端查询数据的时候顶多也就是查不到。
这种方案可能会影响到用户体验，我们对这个方案其实也可以做一下改造，就是利用异步定时任务重新检测缓存中为null的数据，异步去刷新数据到redis中。但是还是没有从根本解决客户体验的问题，只是尽量降低客户的不满意度。大概流程如下。
无效key+定时任务
这种方案的缺点就是存在用户体验问题。
另外的这种方案还有一个缺点，大家思考一下，我们将失效的key以null值的形式缓存到redis中，但是如果有个恶意攻击的行为，专门挑一些随机的key去攻击我们的接口的时候，请求是不是还是最终会打到数据库，所以这种方案不是万无一失的也不是最好的，提到的布隆过滤器则不会存在这样的问题，后面我们再看。
3.互斥锁方案
我们看到导致数据库雪崩是由于请求太大穿透到数据库，那么我们可以在访问数据库的时候动动脑筋。我们可以在访问数据这个环节中加锁，虽然影响性能，但是对于系统来说是安全的。这种方案和无效key方案进行组合之后其实可以用来作为兜底方案，搭配使用其实效果也不错的。我们来看下图。
缓存回源加锁
这种情况就是在上面的标准缓存流程中回溯数据库的地方利用redis的特性 setNx加了一把互斥锁，这样的话，咱们能够尽量保证少量的请求打到数据库中。
大白话可以这么理解，张三李四去同时去访问同一个商品的时候，他们两只有一个能成功，成功拒绝了并发时候针对同一个热门商品的访问。
4.热点数据限流访问
关于这个，我想其实可以不做太多展开，思路很简单，既然是由于请求量太大，导致不走缓存走到了DB，从而将DB打垮，那么咱们就限流量呗。请求量少了，那么自然不会打垮数据库了。关于限流的一些措施以及算法，其实老猫以前也写过文章进行介绍过。所以在此也不做赘述。
5.布隆过滤器
如果用上布隆过滤器的话，那么我们方案如下调整。
系统在初始化的时候将key初始化到布隆过滤器中。当查询的时候，把布隆过滤器放到查询redis缓存之前，如果发现存在Key在布隆过滤器中，那么就继续后续的流程，如果不存在则根本就连摸缓存的机会都没有，更别提数据库了，这样就成功避免了恶意采用无用的key值进行攻击。
6.什么是布隆过滤器
关于布隆过滤器，老猫在此也展开说一下，因为老猫觉得这个可能是这些防雪崩方案中最好的一种方案。那么咱们来看一下什么是布隆过滤器。
这种过滤器是一个叫做Bloom的哥们于1970年提出的，咱们可以把它看做由二进制向量（或者说位数组）和一系列随机映射函数（哈希函数）两部分组成的数据结构。位数组即（bit数组），bit是计算机中最小的单位，也就是我们常说的计算机中的0和1，这种就是用一个位来表示的。
Bit数组大概长的就是如下这样的。
bit数组
位数组中的每个元素都只占用 1 bit , 并且每个元素只能是0 或 1 。这样申请一个 100w 个元素的位数组只占用 1000000Bit / 8 = 125000 Byte = 125000 / 10214 kb ≈ 122kb 的空间。所以占用空间极小。
7.布隆过滤器原理
其基本原理是利用多个哈希函数，将一个元素映射成多个位，然后将这些位设置为 1。当查询一个元素时，如果这些位都被设置为 1，则认为元素可能存在于集合中，否则肯定不存在。所以，布隆过滤器可以准确的判断一个元素是否一定不存在，但是因为哈希冲突的存在，所以他没办法判断一个元素一定存在。只能判断可能存在。
如下图：
添加元素的流程：
- 针对相同的key通过不同的hash计算，算出不同的值。
- 分别更新数组中的数据值为1。
查询元素的流程。例如上图，当查询一个不存在的Key3的时候，调用hash1以及hash2函数，恰好命中了之前key1和key2的hash值，此处我们就有可能误判觉得Key3值也是存在的。这样的话也会打到后续流程中去做查询的业务动作。
8.手撸一个简单的java布隆过滤器
丐版的布隆过滤器的实现方式其实还是比较容易的。如下源码：
/**
* @author 公众号：程序员老猫
* @date 2024/1/18 23:30
*/
public class BloomFilter {
/**
* 初始化大小
*/
private static final int DEFAULT_SIZE = 2 >> 16));
}
/**
* 添加元素到位数组
*/
public void add(Object value) {
bits.set(hash(value), true);
}
/**
* 判断指定元素是否存在于位数组
*/
public boolean contains(Object value) {
return bits.get(hash(value));
}
}写个main函数测试一下：
/**
* @author 公众号：程序员老猫
* @date 2024/1/18 23:33
*/
public class Test {
public static void main(String[] args) {
String value1 = "https://blog.ktdaddy.com/";
String value2 = "kdaddy2";
BloomFilter filter = new BloomFilter();
System.out.println(filter.contains(value1));
System.out.println(filter.contains(value2));
filter.add(value1);
filter.add(value2);
System.out.println(filter.contains(value1));
System.out.println(filter.contains(value2));
}
}结果输出也很简单：
false
false
true
true9.其他第三方布隆过滤器
当然Java中还可以使用第三方库来实现布隆过滤器，常见的有Google Guava库和Apache Commons库以及Redis。关于这两种过滤器的用法，老猫在此就不做赘述了，篇幅过长，大家可能都会丧失读下去的欲望了，所以就到此打住，感兴趣的小伙伴可以自行去找一下相关的资料，然后写个demo玩玩。
写在最后
上述基于小猫的痛苦之上给大家分享了缓存击穿的一系列的解决方案，如果大家还有补充的话，也欢迎大家能够在评论区留言。有个问题想问一下大家，当你新接手一个你不熟悉的项目的时候，你做的第一件事情是什么？
先说一下老猫自己吧，我一般会将现有的业务模型梳理一下，即相关的表结构，然后将核心的流程画一画，继而通过一些列新的迭代慢慢熟悉整个系统，当然在此期间其实也会遇到小猫这样的各种各样的坑，无论是技术方案的坑还是说代码的坑。其实老猫还是比较喜欢“早发现早治疗”这种方式，发现问题，尽早解决掉，个人还是比较抵触现在网上比较流行的说法“防御式编程”。因为如果有问题等到真的爆发的时候，有可能就是灾难性的。
