Redis高级结构-布隆过滤器

可以将布隆过滤器看成一个set，但是这个set可能不太准，当你使用它的contains方法判断时，他可能会误判。但只要设置的参数合理，精确度还是非常高的。当布隆过滤器说某个值存在的时候，那这个值可能不存在。但是当其判断某个值不存在的时候，那么这个值就一定不存在。

使用场景

如短视频场景中，帮用户过滤掉已经看了的视频，那些用户没看过的视频，可能会被过滤掉（一小部分），但绝大多数都能准确识别。这样保证给用户推荐的视频是不重复的。

在爬虫系统中，我们爬过的URL就不在爬了，而URL很长，存储起来很浪费空间，此时就可以用布隆过滤器去重了。

布隆过滤器在NoSQL中使用也非常广泛，我们平时用到的HBase、Cassandra、LevelDB、RocksDB内部都有布隆过滤器，布隆过滤器可以显著降低数据库的IO请求。当想要查询某个row时，可以先通过内存中的布隆过滤器过滤掉大量不存在的row请求，然后再去磁盘查询。

邮箱系统的垃圾邮件过滤器也普遍应用到布隆过滤器，因为这个过滤器，所以平时也会有某些正常的邮件被放进垃圾目录中。

基本用法

1、两个基本指令 bf.add 和 bf.exists

bf.add用于添加元素，

bf.exists用于查询元素是否存在

如果想要一次性添加多个，那就用到了bf.madd指令，如果要同时查询多个元素是否存在，那就用到了bf.mexists。

//添加用户zayn
bf.add user zayn

//查询用户是否存在
bf.exists user zayn

//批量添加用户
bf.madd user zayn naill

//批量查询用户
bf.mexists user zayn naill

当你写程序，遍历10W条插入去查询这10W条时，你会发现，没有误判。这时因为布隆过滤器对于已经见过的元素不会误判，只会误判那些没有见过的元素。

2、自定义布隆过滤器

Redis其实可以提供自定义的布隆过滤器，需要我们在add之前使用bf.reserve指令显式创建。如果对应的key已经存在，那么bf.reserve会报错。bf.reserve有3个参数，分别是key、error_rate和initial_size。

error_rate越低，需要的空间越大；

initial_size表示预计放入的元素数量，当实际数量超过这个值时，误判率会上升，所以需要提前设置一个较大的数值避免超出导致误判率升高。

布隆过滤器的原理

每个布隆过滤器对应到Redis里的数据结构就是一个大型的位数组和几个不一样的无偏hash函数。

所谓的无偏就是能够把元素的hash值算的比较均匀，让元素被hash映射到数组中的位置比较随机。

向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash，算得一整数索引值，然后对位数组长度进行取模运算得到一个位置，每个 hash函数是会个不同的位置，再把位数组的这几个位置都置为1,就完成了add作。

向布隆过滤器询间 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为1，只要有一个位为0，那么说明布隆过滤器中这个 key 不存在。如果这几个位置都是1，并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为1可能是因为其他的 key 存在所致。如果这个位数组比较稀疏，判断正确的概率就会很大，如果这个位数组比较拥挤，判断正的概率就会降低。具体的概率计算公式比较复杂，感兴趣可以阅读相关的更深入研究的资料，不过非常烧脑。使用时不要让实际元素数量远大于初始化数量，当实际元素数量开始超出初始化数量时，应该对布隆过滤器进行重建，重新分配一个size更大的过滤器，再将所有的历史元素批量add进去。

空间占用估计

布隆过滤器有2个参数，一个是预计元素 数量n，另一个是错误率f，公式根据这2个输入得出2个输出，第一个输出是位数组长度l，也就是需要储存空间大小（bit），第二个输出是最佳数量k。

公式如下：

k = 0.7 *(l/n)

f = 0.6185^(l/n)

当错误率位0.1%的时候，一个元素需要的平均指纹空间位14.377bit，大约是15bit。那是否布隆过滤器的优势就没那么明显了？

需要明确的是，set中会存储每个元素的内容，而布隆过滤器仅仅是储存元素的指纹。元素的内容大小就是字符串的长度，一般会有多个字节，甚至几十个上百个字节，每个元素本身还需要一个指针被set集合引用，这个指针又会占用4个字节或8个字节，取决于OS是32位还是64位。指纹所需空间不足2字节，所以布隆过滤器的空间优势还是很明显的。