redis缓存击穿怎么办？

今天我们来聊一聊redis缓存穿透和击穿，首先上一张图，来演示redis缓存在实际业务场景的使用

用户端需要查询一个id=1的数据,发起查询请求到应用服务器，应用服务先到redis缓存中查询，如果redis缓存中没有，就会到数据库中查询,数据库中查询到了会保存到redis缓存中，再返回给应用服务器，最终返回到用户端。

      这里查询id=1的数据，就会有以下几种情况,一种情况是redis没有缓存id=1的数据，但是数据库中有，这样的查询就会先到redis中查询，发现没有就会发起到数据库的查询，这种情况叫做redis缓存击穿；还有一种情况就是redis中没有，数据库中也没有，这样每次查询就会先到 redis中查询，发现没有，又会到数据中发起情况，这种情况叫做缓存穿透。

      如果id=1在数据库没有，这样用户一直发起id=1的请求，这样每次都会查询数据库，请求量少还好，如果很多用户并发请求，这样对数据库来说就是一种考验了，对这种情况，有一种解决方案，叫做布隆过滤器。

接下来使用一个简单的实例来演示布隆过滤器的用法。

       首先把数字1到10000存入到bloom过滤器中，然后再用一个循环 j 从 size+10000即20000开始，到 size+20000即30000，判断bloom中是否可能存在这些值，按照正常的思路分析，bloom过滤器中存入的的是1到10000，if(bloom.mightContain(j))应该都会为false，进入不了 list.add(j)的代码，所以list的长度应该为0，但是我们看实际的执行结果：

       list的长度居然为100，这个是布隆过滤器存在误判了，查看上面代码的12行的最后一个参数0.01叫做匹配精度值（也叫容错率参数），值越小匹配的精度越高，当我们把这个参数改成0.001再运行程序，list的长度变为7，把参数调小，误判率就越低，需要的存储空间也越大，所以在实际使用过程中需要在误判率和存储空间之间做个权衡。

        布隆过滤器的原理

         bloom filter本质上由一个长度为m的比特向量组成，可以理解为一个数组，数组里的值默认都是0，当我们向这个数组存入数字1时，会对1做三种hash值的计算，得到三个值，假如其中一个hash值是20，就会在数组下标为20的位置的只由0改成1。

        那怎么证明1是否存在呢？同样的算法，对1做三种hash值的计算，得到的下标值，如果该下标对应的值为1，则证明1可能存在；同样，如果是查询4是否存在，对4做三种hash值的计算，得到三个下标，查询下标对应的值，如果三个下标对应的值都是0，则证明4肯定不存在。

      由于不同值的hash值计算可能发生碰撞，所以存在误判的情况。布隆过滤器的初始数组长度和容错率的参数设置有关，参数越大布隆过滤器的数组长度越短，反之越长，所以容错率参数设置越小，发生误判率越低。

    在实际应用中，我们需要根据业务数据量设置容错率的值，还需要维护业务数据到布隆过滤器中，这样在用户端发起查询时，先到布隆过滤器中查询，如果布隆过滤器中判断存在该业务数据，再到redis中，数据库中进行查询，避免缓存穿透。

       布隆过滤器的缺点：

1.存在误判，可能要查到的元素并没有在容器中，但是hash之后得到的k个位置上值都是1

2.删除困难。一个放入容器的元素映射到bit数组的k个位置上是1，

  删除的时候不能简单的直接置为0，可能会影响其他元素的判断。可以采用 Counting Bloom Filter