1月17日总结

对于小猫来讲，最近的一段日子是不好过的，纵使听着再有节拍的音乐，也换不起他对生活的热情。由于上一次“幂等事件”躺枪，他已经有几天没有休息好了。他感觉人生到了低谷。

当接手这个商城项目之后，他感觉他一直没有好过。他的内心彷徨，在工位上边写着事故报告，边嘀咕着“今年到底是犯了啥冲...为什么...”

然而屋漏又遭连夜雨，船破偏遇当头风，好像坏事儿又找上了他。

坐他旁边的哥们在一旁抱怨，“啥情况，我就想给公司助助力，买点咱自家公司的产品，咋商详页咋点来点去进不了，你看看你的呢？”。

“你自己手机不行了吧，你瞧你那老破烂也该换了，iphone15 pmax搞起...” 旁边的老六开涮道。

然而却触动了小猫的神经，他赶紧打开app，发现自己的也进不去了。他赶紧打开Grafana，脸色苍白，口干舌燥....数据库连接全部打满。

不到一会组长的电话也收到了客服反馈的客诉，组长向小猫投来质疑的目光。

小猫无辜而又无奈：“我真的没有动过代码......”。

经过一轮彻彻底底的摸排，事情的原因也终于水落石出。

大概如下图这么回事儿：

流程

上次A公司对接商城服务之后开始在他们商城平台推拼团售卖活动，活动中的几个商品的缓存被删除之后没有恢复，原因是因为第三方对接的API商品大量推送，队列有堆积，导致redis缓存并没有及时更新。大批量的用户在进行购买活动商品的时候，请求全部打到了DB上。

反正也不晓得是哪个挨千刀的设计的技术方案，缓存到redis中的时候用的居然是异步消息队列。商品发布量小，访问量小的时候可能没有什么问题。

但是偏偏各种巧合发生在了一起就产生了这样一个事故，这可能就是所谓的墨菲定律吧。

小猫已经走到了绝望的边缘......（下次就不说小猫踩坑了，让他缓几天，哈哈）
聊聊缓存击穿

在此我们对小猫表示同情，但是这是一个很好的例子，老猫还是和大家一起聊聊缓存击穿雪崩的话题。

咱们就从以下几个方面聊聊缓存雪崩击穿的问题。

概览图

在上图中可以看见，我们会对布隆过滤器做一个重点的介绍，因为这个也是比较常用的方式缓存击穿的方式。
什么是缓存击穿？是什么原因导致的？

从上面小猫的案例中，其实就已经很明了了，所谓缓存击穿就是原本由于缓存组件抗住的流量结果全部打到了数据库层，给数据库带来了巨大的压力，甚至严重的情况下直接把数据库干跨。导致缓存失效的原因也是很显然易见的，由于缓存在一个无法预期的一个场景下缓存失效了。

在小猫的案例中可以看到是热卖的商品在redis中Key值全部同时失效导致的。当然这是一种常见的技术方案有问题导致的。
那么还有一种导致缓存失效的原因就是缓存中间件直接宕机。这种情况是运维层面需要解决的，可能要求对缓存中间件做好高可用，如何做高可用，我们在此不做深究。

下面是咱们的缓存用法，大家可以看一下下面的流程。

缓存流程

从上述的流程图中我们可以看到，当有请求过来的时候，首先会尝试从缓存中去读取，当缓存中没有读到的时候，这个时候咱们就会回源到数据库再次查找，当查到相关商品数据之后返回给客户端，之后并将该数据继续缓存到数据库中。

接下来咱们来看一下发生雪崩之后的解决方案。
无效key值处理

这种情况其实很简单了，既然由于没有在缓存数据库中找到数据，那么咱们也不应该直接将redis中那些Key值直接删除，这样找不到key的话，肯定还是会打到数据库，所以我们只要避免请求去查数据库就可以了。所以我们就把无效的Key也保存到redis中即可。这种值的话，我们都保存成“null”。这样的话redis中的key一定就是全量的了，客户端查询数据的时候顶多也就是查不到。

这种方案可能会影响到用户体验，我们对这个方案其实也可以做一下改造，就是利用异步定时任务重新检测缓存中为null的数据，异步去刷新数据到redis中。但是还是没有从根本解决客户体验的问题，只是尽量降低客户的不满意度。大概流程如下。

无效key+定时任务

这种方案的缺点就是存在用户体验问题。

另外的这种方案还有一个缺点，大家思考一下，我们将失效的key以null值的形式缓存到redis中，但是如果有个恶意攻击的行为，专门挑一些随机的key去攻击我们的接口的时候，请求是不是还是最终会打到数据库，所以这种方案不是万无一失的也不是最好的，提到的布隆过滤器则不会存在这样的问题，后面我们再看。
互斥锁方案

我们看到导致数据库雪崩是由于请求太大穿透到数据库，那么我们可以在访问数据库的时候动动脑筋。我们可以在访问数据这个环节中加锁，虽然影响性能，但是对于系统来说是安全的。这种方案和无效key方案进行组合之后其实可以用来作为兜底方案，搭配使用其实效果也不错的。我们来看下图。

缓存回源加锁