Redis缓存穿透

缓存穿透：

缓存穿透说简单点就是⼤量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，
根本没有经过缓存这⼀层。举个例⼦：某个⿊客故意制造我们缓存中不存在的 key 发起⼤量
请求，导致⼤量请求落到数据库。
总结⼀下就是：

1. 缓存层不命中。
2. 存储层不命中，不将空结果写回缓存。
3. 返回空结果给客户端。
   ⼀般 MySQL 默认的最⼤连接数在 150 左右，这个可以通过 show variables like
   ‘%max_connections%’; 命令来查看。最⼤连接数⼀个还只是⼀个指标，cpu，内存，磁盘，⽹
   络等物理条件都是其运⾏指标，这些指标都会限制其并发能⼒！所以，⼀般 3000 的并发请
   求就能打死⼤部分数据库了。

解决方案：
最基本的就是⾸先做好参数校验，⼀些不合法的参数请求直接抛出异常信息返回给客户端。
⽐如查询的数据库 id 不能⼩于 0、传⼊的邮箱格式不对的时候直接返回错误消息给客户端
等等。
参数校验通过的情况还是会出现缓存穿透，我们还可以通过以下⼏个⽅案来解决这个问题：

1）缓存⽆效 key : 如果缓存和数据库都查不到某个 key 的数据就写⼀个到 redis 中去并设
置过期时间，具体命令如下： SET key value EX 10086 。这种⽅式可以解决请求的 key 变化
不频繁的情况，如何⿊客恶意攻击，每次构建的不同的请求 key，会导致 redis 中缓存⼤量
⽆效的 key 。很明显，这种⽅案并不能从根本上解决此问题。如果⾮要⽤这种⽅式来解决穿
透问题的话，尽量将⽆效的 key 的过期时间设置短⼀点⽐如 1 分钟。
另外，这⾥多说⼀嘴，⼀般情况下我们是这样设计 key 的： 表名：列名：主键名：主键值。

2）布隆过滤器： 布隆过滤器是⼀个⾮常神奇的数据结构，通过它我们可以⾮常⽅便地判断
⼀个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆
过滤器就是我们想要找的那个“⼈”。

布隆过滤器在针对海量数据去重或者验证数据合法性的时候⾮常有⽤。布隆过滤器的本质实
际上是 “位(bit)数组”，也就是说每⼀个存⼊布隆过滤器的数据都只占⼀位。相⽐于我们平
时常⽤的的 List、Map 、Set 等数据结构，它占⽤空间更少并且效率更⾼，但是缺点是其
返回的结果是概率性的，⽽不是⾮常准确的。
当⼀个元素加⼊布隆过滤器中的时候，会进⾏如下操作：
1. 使⽤布隆过滤器中的哈希函数对元素值进⾏计算，得到哈希值（有⼏个哈希函数得到⼏
个哈希值）。
2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。
当我们需要判断⼀个元素是否存在于布隆过滤器的时候，会进⾏如下操作：
1. 对给定元素再次进⾏相同的哈希计算；
2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布
隆过滤器中，如果存在⼀个值不为 1，说明该元素不在布隆过滤器中。
举个简单的例⼦：

如图所示，当字符串存储要加⼊到布隆过滤器中时，该字符串⾸先由多个哈希函数⽣成不同
的哈希值，然后在对应的位数组的下表的元素设置为 1（当位数组初始化时 ，所有位置均为
0）。当第⼆次存储相同字符串时，因为先前的对应位置已设置为 1，所以很容易知道此值
已经存在（去重⾮常⽅便）。
如果我们需要判断某个字符串是否在布隆过滤器中时，只需要对给定字符串再次进⾏相同的
哈希计算，得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个
值在布隆过滤器中，如果存在⼀个值不为 1，说明该元素不在布隆过滤器中。

不同的字符串可能哈希出来的位置相同，这种情况我们可以适当增加位数组⼤⼩或者调整我
们的哈希函数。

综上，我们可以得出：布隆过滤器说某个元素存在，⼩概率会误判。布隆过滤器说某个元素
不在，那么这个元素⼀定不在

把所有可能存在的请求的值都存放在布隆过滤器中，当⽤户请求过来，我会先判断⽤户发来的请求的
值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会
⾛下⾯的流程。