内存崩溃了?其实你只需要换一种方式
在上一篇 Java 多线程爬虫及分布式爬虫架构探索 中,我们使用了 JDK 自带的 Set 集合来进行 URL 去重,看上去效果不错,但是这种做法有一个致命了缺陷,就是随着采集的 URL 增多,你需要的内存越来越大,最终会导致你的内存崩溃。那我们在不使用数据库的情况下有没有解决办法呢?还记得我们在上一篇文章中提到的布隆过滤器吗?它就可以完美解决这个问题,布隆过滤器有什么特殊的地方呢?接下来就一起来学习一下布隆过滤器。 什么是布隆过滤器 布隆过滤器是一种数据结构,比较巧妙的概率型数据结构,它是在 1970 年由一个名叫布隆提出的,它实际上是由一个很长的二进制向量和一系列随机映射函数组成,这点跟哈希表有些相同,但是相对哈希表来说布隆过滤器它更高效、占用空间更少,布隆过滤器有一个缺点那就是有一定的误识别率和删除困难。布隆过滤器只能告诉你某个元素一定不存在或者可能存在在集合中, 所以布隆过滤器经常用来处理可以忍受判断失误的业务,比如爬虫 URL 去重。 布隆过滤器原理 在说布隆过滤器原理之前,我们先来复习一下哈希表,在上一篇文章中,我们利用的是 Set 来进行 URL 去重,我们来看看 Set 的存储模型 Set url 去重 URL 经过一个哈希函数后,将 URL 存入了数组里,这样查询时也是非常高效的,但是由于数组里存入的是 URL,随着 URL 的增多,需要的数组越来越大,意味着你需要更多的内存,比如我们采集了几亿的 URL,那么可能就需要上百G 的内存,这是条件不允许的,因为内存特别的昂贵,所以这个在 url 去重中是不可取的,占内存更小的布隆过滤器就是一种不错的选择。 布隆过滤器实质上由长度为 m 的位向量或位列表(仅包含 0 或 1 位值的列表)组成,最初所有值均设置为 0,如下所示。 布隆过滤器 因为底层是 bit 数组,所以意味着数组只有 0、1 两个值,跟哈希表一样,我们将 URL 通过 K 个函数映射 bit 数组里,并且将指向的 Bit 数组对应的值改成 1 。我们以 /nba/2492297.html 为例,如下图所示。 布隆过滤器 /nba/2492297.html经过三个哈希函数分别映射到了 1、4、9 的位置,这三个 bit 数组的值就变成了 1,我们再存入一个 /nba/2492298.html,此时 bit 数组就变成下面这样: 布隆过滤器 /nba/2492298.html被映射到了 0、4、11 的位置,所以此时 bit 数组上有 5 个位置的值为 1,本应该是有 6 个值为 1 的,但是因为在 4 这个位置重复了,所以会覆盖。 布隆过滤器是如何判断某个值一定不存在或者可能存在呢?通过判断哈希函数映射到对应数组的值,如果都为 1,说明可能存在,如果有一个不为 1,说明一定不存在。对于一定不存在好理解,但是都为 1 时,为什么说可能存在呢?这跟哈希表一样,哈希函数会产生哈希冲突,也就是说两个不同的值经过哈希函数都会得到同一个数组下标,布隆过滤器也是一样的。我们以判断 /nba/2492299.html 是否已经采集过为例,经过哈希函数映射的 bit 数组上的位置如下图所示: 布隆过滤器 /nba/2492299.html 被哈希函数映射到了 4、9、11 的位置,而这几个位置的值都为 1 ,所以布隆过滤器就认为 /nba/2492299.html 被采集过了,实际上是没有采集过的,这就说明了布隆过滤器存在误判,这也是我们业务允许的。布隆过滤器的误判率跟 bit 数组的大小和哈希函数的个数有关系,如果 bit 数组过小,哈希函数过多,那么 bit 数组的值很快都会变成 1,这样误判率就会越来越高,bit 数组过大,就会浪费更多的内存,所以就要平衡好 bit 数组的大小和哈希函数的个数,关于如何平衡这两个的关系,不是我们这篇文章的重点。 布隆过滤器的原理我们已经了解了,为了加深对布隆过滤器的理解,我们用 Java 来实现一个简易版的布隆过滤器,代码如下:
(编辑:ASP站长网) |