缓存雪崩

缓存雪崩指的是 Redis 当中的大量缓存在同一时间全部失效，而假如恰巧这一段时间同时又有大量请求被发起，那么就会造成请求直接访问到数据库，可能会把数据库冲垮。

缓存雪崩一般形容的是缓存中没有而数据库中有的数据，而因为时间到期导致请求直达数据库。

解决方案

解决缓存雪崩的方法有很多：

• 1、加锁，保证单线程访问缓存。这样就不会有很多请求同时访问到数据库。

• 2、失效时间不要设置成一样。典型的就是初始化预热数据的时候，将数据存入缓存时可以采用随机时间来确保不会咋同一时间有大量缓存失效。

• 3、内存允许的情况下，可以将缓存设置为永不失效。

缓存击穿

缓存击穿和缓存雪崩很类似，区别就是缓存击穿一般指的是单个缓存失效，而同一时间又有很大的并发请求需要访问这个 key，从而造成了数据库的压力。

解决方案

解决缓存击穿的方法和解决缓存雪崩的方法很类似：

• 1、加锁，保证单线程访问缓存。这样第一个请求到达数据库后就会重新写入缓存，后续的请求就可以直接读取缓存。

• 2、内存允许的情况下，可以将缓存设置为永不失效。

缓存穿透

缓存穿透和上面两种现象的本质区别就是这时候访问的数据其在数据库中也不存在，那么既然数据库不存在，所以缓存里面肯定也不会存在，这样如果并发过大就会造成数据源源不断的到达数据库，给数据库造成极大压力。

解决方案

对于缓存穿透问题，加锁并不能起到很好地效果，因为本身 key 就是不存在，所以即使控制了线程的访问数，但是请求还是会源源不断的到达数据库。

解决缓存穿透问题一般可以采用以下方案配合使用：

• 1、接口层进行校验，发现非法的 key 直接返回。比如数据库中采用的是自增 id，那么如果来了一个非整型的 id 或者负数 id 可以直接返回，或者说如果采用的是 32 位 uuid，那么发现 id 长度不等于 32 位也可以直接返回。

• 2、将不存在的数据也进行缓存，可以直接缓存一个空或者其他约定好的无效 value。采用这种方案最好将 key 设置一个短期失效时间，否则大量不存在的 key 被存储到 Redis 中，也会占用大量内存。

布隆过滤器（Bloom Filter）

针对上面缓存穿透的解决方案，我们思考一下：假如一个 key 可以绕过第 1 种方法的校验，而此时有大量的不存在 key 被访问（如 1 亿个或者 10 亿个），那么这时候全部存储到缓存，会占用非常大的空间，会浪费大量服务器内存，导致内存不足。

那么有没有一种更好的解决方案呢？这就是我们接下来要介绍的布隆过滤器，布隆过滤器就可以最大程度的解决 key 值过多的这个问题。

什么是布隆过滤器

可能大部分人都知道有这么一个面试问题：如何在 10 亿的海量的无序的数据中快速判断一个元素是否存在？

要解决这个问题就需要用到布隆过滤器，否则大部分服务器的内存是无法存储这么大的数量级的数据的。

布隆过滤器（Bloom Filter）是由布隆在 1970 年提出的。它实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数）。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率而且删除困难。

位图（Bitmap）

Redis 当中有一种数据结构就是位图，布隆过滤器其中重要的实现就是位图的实现，也就是位数组，并且在这个数组中每一个位置只有 0 和 1 两种状态，每个位置只占用 1 个字节，其中 0 表示没有元素存在，1 表示有元素存在。如下图所示就是一个简单的布隆过滤器示例（一个 key 值经过哈希运算和位运算就可以得出应该落在哪个位置）：

哈希碰撞

上面我们发现，lonely 和 wolf 落在了同一个位置，这种不同的 key 值经过哈希运算后得到相同值的现象就称之为哈希碰撞。发生哈希碰撞之后再经过位运算，那么最后肯定会落在同一个位置。

如果发生过多的哈希碰撞，就会影响到判断的准确性，所以为了减少哈希碰撞，我们一般会综合考虑以下 2 个因素：

• 1、增大位图数组的大小（位图数组越大，占用的内存越大）。

• 2、增加哈希函数的次数（同一个 key 值经过 1 个函数相等了，那么经过 2 个或者更多个哈希函数的计算，都得到相等结果的概率就自然会降低了）。

上面两个方法我们需要综合考虑：比如增大位数组，那么就需要消耗更多的空间，而经过越多的哈希计算也会消耗 cpu 影响到最终的计算时间，所以位数组到底多大，哈希函数次数又到底需要计算多少次合适需要具体情况具体分析。

布隆过滤器的 2 大特点

下面这个就是一个经过了 2 次哈希函数得到的布隆过滤器，根据下图我们很容易看到，假如我们的 Redis 根本不存在，但是 Redis 经过 2 次哈希函数之后得到的两个位置已经是 1 了（一个是 wolf 通过 f2 得到，一个是 Nosql 通过 f1 得到）。

所以通过上面的现象，我们从布隆过滤器的角度可以得出布隆过滤器主要有 2 大特点：

• 1、如果布隆过滤器判断一个元素存在，那么这个元素可能存在。

• 2、如果布隆过滤器判断一个元素不存在，那么这个元素一定不存在。

而从元素的角度也可以得出 2 大特点：

• 1、如果元素实际存在，那么布隆过滤器一定会判断存在。

• 2、如果元素不存在，那么布隆过滤器可能会判断存在。

PS：需要注意的是，如果经过 N 次哈希函数，则需要得到的 N 个位置都是 1 才能判定存在，只要有一个是 0，就可以判定为元素不存在布隆过滤器中。

fpp

因为布隆过滤器中总是会存在误判率，因为哈希碰撞是不可能百分百避免的。布隆过滤器对这种误判率称之为假阳性概率，即：False Positive Probability，简称为 fpp。

在实践中使用布隆过滤器时可以自己定义一个 fpp，然后就可以根据布隆过滤器的理论计算出需要多少个哈希函数和多大的位数组空间。需要注意的是这个 fpp 不能定义为 100%，因为无法百分保证不发生哈希碰撞。

最后我们该如何学习？

1、看视频进行系统学习

这几年的 Crud 经历，让我明白自己真的算是菜鸡中的战斗机，也正因为 Crud，导致自己技术比较零散，也不够深入不够系统，所以重新进行学习是很有必要的。我差的是系统知识，差的结构框架和思路，所以通过视频来学习，效果更好，也更全面。关于视频学习，个人可以推荐去 B 站进行学习，B 站上有很多学习视频，唯一的缺点就是免费的容易过时。

另外，我自己也珍藏了好几套视频资料躺在网盘里，有需要的我也可以分享给你：

2、读源码，看实战笔记，学习大神思路

“编程语言是程序员的表达的方式，而架构是程序员对世界的认知”。所以，程序员要想快速认知并学习架构，读源码是必不可少的。阅读源码，是解决问题 + 理解事物，更重要的：看到源码背后的想法；程序员说：读万行源码，行万种实践。

Spring 源码深度解析：

Mybatis 3 源码深度解析：

Redis 学习笔记：

Spring Boot 核心技术-笔记：

3、面试前夕，刷题冲刺

面试的前一周时间内，就可以开始刷题冲刺了。请记住，刷题的时候，技术的优先，算法的看些基本的，比如排序等即可，而智力题，除非是校招，否则一般不怎么会问。

关于面试刷题，我个人也准备了一套系统的面试题，帮助你举一反三：

只有技术过硬，在哪儿都不愁就业，“万般带不去，唯有业随身”学习本来就不是在课堂那几年说了算，而是在人生的旅途中不间断的事情。

人生短暂，别稀里糊涂的活一辈子，不要将就。

资料领取方式：点击蓝色传送门免费领取上述资料

文章内容中涉及到的 Java 面试题、源码文档，技术笔记等学习资料，均可以免费分享给大家学习，只需你动动手多多支持即可！