不知道从什么时候开始，本来默默无闻的布隆过滤器一下子名声大燥，仿佛身在互联网，做着开发的，无人不知，无人不晓，哪怕对技术不是很关心的小伙伴也听过它的名号。我也花了不少时间去研究布隆过滤器，看了不少博客，无奈不是科班出身，又没有那么聪明的头脑，又比较懒...经过“放弃，拿起，放弃，拿起”的无限轮回，应该算是了解了布隆过滤器的核心思想，所以想给大家分享下。

布隆过滤器的应用

我们先来看下布隆过滤器的应用场景，让大家知道神奇的布隆过滤器到底能做什么。

缓存穿透

我们经常会把一部分数据放在Redis等缓存，比如产品详情。这样有查询请求进来，我们可以根据产品Id直接去缓存中取数据，而不用读取数据库，这是提升性能最简单，最普遍，也是最有效的做法。一般的查询请求流程是这样的：先查缓存，有缓存的话直接返回，如果缓存中没有，再去数据库查询，然后再把数据库取出来的数据放入缓存，一切看起来很美好。但是如果现在有大量请求进来，而且都在请求一个不存在的产品Id，会发生什么？既然产品Id都不存在，那么肯定没有缓存，没有缓存，那么大量的请求都怼到数据库，数据库的压力一下子就上来了，还有可能把数据库打死。
虽然有很多办法都可以解决这问题，但是我们的主角是“布隆过滤器”，没错，“布隆过滤器”就可以解决（缓解）缓存穿透问题。至于为什么说是“缓解”，看下去你就明白了。

大量数据，判断给定的是否在其中

现在有大量的数据，而这些数据的大小已经远远超出了服务器的内存，现在再给你一个数据，如何判断给你的数据在不在其中。如果服务器的内存足够大，那么用HashMap是一个不错的解决方案，理论上的时间复杂度可以达到O(1)，但是现在数据的大小已经远远超出了服务器的内存，所以无法使用HashMap，这个时候就可以使用“布隆过滤器”来解决这个问题。但是还是同样的，会有一定的“误判率”。

什么是布隆过滤器

布隆过滤器是一个叫“布隆”的人提出的，它本身是一个很长的二进制向量，既然是二进制的向量，那么显而易见的，存放的不是0，就是1。

现在我们新建一个长度为16的布隆过滤器，默认值都是0，就像下面这样：

现在需要添加一个数据：

我们通过某种计算方式，比如Hash1，计算出了Hash1(数据)=5，我们就把下标为5的格子改成1，就像下面这样：

我们又通过某种计算方式，比如Hash2，计算出了Hash2(数据)=9，我们就把下标为9的格子改成1，就像下面这样：

还是通过某种计算方式，比如Hash3，计算出了Hash3(数据)=2，我们就把下标为2的格子改成1，就像下面这样：

这样，刚才添加的数据就占据了布隆过滤器“5”，“9”，“2”三个格子。

可以看出，仅仅从布隆过滤器本身而言，根本没有存放完整的数据，只是运用一系列随机映射函数计算出位置，然后填充二进制向量。

这有什么用呢？比如现在再给你一个数据，你要判断这个数据是否重复，你怎么做？

你只需利用上面的三种固定的计算方式，计算出这个数据占据哪些格子，然后看看这些格子里面放置的是否都是1，如果有一个格子不为1，那么就代表这个数字不在其中。这很好理解吧，比如现在又给你了刚才你添加进去的数据，你通过三种固定的计算方式，算出的结果肯定和上面的是一模一样的，也是占据了布隆过滤器“5”，“9”，“2”三个格子。

但是有一个问题需要注意，如果这些格子里面放置的都是1，不一定代表给定的数据一定重复，也许其他数据经过三种固定的计算方式算出来的结果也是相同的。这也很好理解吧，比如我们需要判断对象是否相等，是不可以仅仅判断他们的哈希值是否相等的。

也就是说布隆过滤器只能判断数据是否一定不存在，而无法判断数据是否一定存在。

按理来说，介绍完了新增、查询的流程，就要介绍删除的流程了，但是很遗憾的是布隆过滤器是很难做到删除数据的，为什么？你想想，比如你要删除刚才给你的数据，你把“5”，“9”，“2”三个格子都改成了0，但是可能其他的数据也映射到了“5”，“9”，“2”三个格子啊，这不就乱套了吗？

相信经过我这么一介绍，大家对布隆过滤器应该有一个浅显的认识了，至少你应该清楚布隆过滤器的优缺点了：

• 优点：由于存放的不是完整的数据，所以占用的内存很少，而且新增，查询速度够快；
• 缺点： 随着数据的增加，误判率随之增加；无法做到删除数据；只能判断数据是否一定不存在，而无法判断数据是否一定存在。

可以看到，布隆过滤器的优点和缺点一样明显。

在上文中，我举的例子二进制向量长度为16，由三个随机映射函数计算位置，在实际开发中，如果你要添加大量的数据，仅仅16位是远远不够的，为了让误判率降低，我们还可以用更多的随机映射函数、更长的二进制向量去计算位置。

guava实现布隆过滤器

现在相信你对布隆过滤器应该有一个比较感性的认识了，布隆过滤器核心思想其实并不难，难的在于如何设计随机映射函数，到底映射几次，二进制向量的长度设置为多少比较好，这可能就不是一般的开发可以驾驭的了，好在Google大佬给我们提供了开箱即用的组件，来帮助我们实现布隆过滤器，现在就让我们看看怎么Google大佬送给我们的“礼物”吧。

首先在pom引入“礼物”：

        <dependency><groupId>com.google.guava</groupId><artifactId>guava</artifactId><version>19.0</version></dependency>

然后就可以测试啦：

    private static int size = 1000000;//预计要插入多少数据private static double fpp = 0.01;//期望的误判率private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, fpp);public static void main(String[] args) {//插入数据for (int i = 0; i < 1000000; i++) {bloomFilter.put(i);}int count = 0;for (int i = 1000000; i < 2000000; i++) {if (bloomFilter.mightContain(i)) {count++;System.out.println(i + "误判了");}}System.out.println("总共的误判数:" + count);}

代码简单分析：
我们定义了一个布隆过滤器，有两个重要的参数，分别是 我们预计要插入多少数据，我们所期望的误判率，误判率不能为0。
我向布隆过滤器插入了0-1000000，然后用1000000-2000000来测试误判率。

运行结果：

1999501误判了
1999567误判了
1999640误判了
1999697误判了
1999827误判了
1999942误判了
总共的误判数:10314

现在总共有100万数据是不存在的，误判了10314次，我们计算下误判率

和我们定义的期望误判率0.01相差无几。

redis实现布隆过滤器

上面使用guava实现布隆过滤器是把数据放在本地内存中，无法实现布隆过滤器的共享，我们还可以把数据放在redis中，用 redis来实现布隆过滤器，我们要使用的数据结构是bitmap，你可能会有疑问，redis支持五种数据结构：String，List，Hash，Set，ZSet，没有bitmap呀。没错，实际上bitmap的本质还是String。

可能有小伙伴会说，纳尼，布隆过滤器还没介绍完，怎么又出来一个bitmap，没事，你可以把bitmap就理解为一个二进制向量。

要用redis来实现布隆过滤器，我们需要自己设计映射函数，自己度量二进制向量的长度，这对我来说，无疑是一个不可能完成的任务，只能借助搜索引擎，下面直接放出代码把。

public class RedisMain {static final int expectedInsertions = 1000;//要插入多少数据static final double fpp = 0.01;//期望的误判率//bit数组长度private static long numBits;//hash函数数量private static int numHashFunctions;static {numBits = optimalNumOfBits(expectedInsertions, fpp);numHashFunctions = optimalNumOfHashFunctions(expectedInsertions, numBits);}public static void main(String[] args) {Jedis jedis = new Jedis("localhost", 6379);for (int i = 0; i < 1000; i++) {long[] indexArray = getIndexArray(String.valueOf(i));for (long index : indexArray) {jedis.setbit("codebear:bloom", index, true);}}int num = 0;for (int i = 1000; i < 2000; i++) {long[] indexArray = getIndexArray(String.valueOf(i));for (long index : indexArray) {if (!jedis.getbit("codebear:bloom", index)) {System.out.println(i + "一定不存在");num++;break;}}}System.out.println("一定不存在的有" + num + "个");}/*** 根据key获取bitmap下标*/private static long[] getIndexArray(String key) {long hash1 = hash(key);long hash2 = hash1 >>> 16;long[] result = new long[numHashFunctions];for (int i = 0; i < numHashFunctions; i++) {long combinedHash = hash1 + i * hash2;if (combinedHash < 0) {combinedHash = ~combinedHash;}result[i] = combinedHash % numBits;}return result;}private static long hash(String key) {return Hashing.MURMUR_HASH.hash(key);}//计算hash函数个数private static int optimalNumOfHashFunctions(long n, long m) {return Math.max(1, (int) Math.round((double) m / n * Math.log(2)));}//计算bit数组长度private static long optimalNumOfBits(long n, double p) {if (p == 0) {p = Double.MIN_VALUE;}return (long) (-n * Math.log(p) / (Math.log(2) * Math.log(2)));}
}

运行结果：

1997一定不存在
1998一定不存在
1999一定不存在
一定不存在的有989个

最佳实践
常见的适用常见有，利用布隆过滤器减少磁盘 IO 或者网络请求，因为一旦一个值必定不存在的话，我们可以不用进行后续昂贵的查询请求。

另外，既然你使用布隆过滤器来加速查找和判断是否存在，那么性能很低的哈希函数不是个好选择，推荐 MurmurHash、Fnv 这些。

大Value拆分
Redis 因其支持 setbit 和 getbit 操作，且纯内存性能高等特点，因此天然就可以作为布隆过滤器来使用。但是布隆过滤器的不当使用极易产生大 Value，增加 Redis 阻塞风险，因此生成环境中建议对体积庞大的布隆过滤器进行拆分。

拆分的形式方法多种多样，但是本质是不要将 Hash(Key) 之后的请求分散在多个节点的多个小 bitmap 上，而是应该拆分成多个小 bitmap 之后，对一个 Key 的所有哈希函数都落在这一个小 bitmap 上。

总结
布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

3.布隆过滤器使用场景
3.1 学习Redis时，在某种情况下，可能会出现缓存雪崩和缓存穿透。
缓存穿透：大量请求访问时，Redis没有命中数据，导致请求绕过了Redis缓存，直接去访问数据库了。数据库难以承受大量的请求。
此时便可以使用布隆过滤器来解决。
请求到来时，先用布隆过滤器判断数据是否有效，布隆过滤器可以判断元素一定不存在和可能存在，对于一定不存在的数据，则可以直接丢弃请求。对可能存在的请求，再去访问Redis获取数据，Redis没有时，再去访问数据库。
3.2 邮箱的垃圾邮件过滤、黑名单等。
3.3 去重，：比如爬给定网址的时候对已经爬取过的 URL 去重。

参考：

https://www.cnblogs.com/CodeBear/p/10911177.html

https://blog.csdn.net/CrankZ/article/details/84928562?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

https://blog.csdn.net/chen_kkw/article/details/82190859?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

https://blog.csdn.net/DuoDuoPPP/article/details/104873732