如何巧用布隆过滤器减少90%的请求

使用布隆过滤器判断是否存在，减少大量无效请求

现在维护着一个用户标签服务，大概的功能，是每日定时统计符合某些标签的用户群组，保存到redis中，然后供前端展示广告，推送活动等做判断用
主要的操作就是判断用户是否属于指定的群组ID。

所以最简单的办法，就是把群组ID做key，用户ID做value，存进redis的set集合里，这样做群组间的交集差集，也非常方便。

一切都运行很好。。直到最近访问量突增，监控页面看到redis的IO有点高了，观察info命令发现，redis的miss的占比非常高，hit/miss 大约是1/8。这其实也好理解，毕竟满足某些标签的群组用户数量和总用户数相比确实算少的。这样大量的请求其实就是查询不到数据的，这时候就可以考虑布隆过滤器出场了。

简单介绍下布隆过滤器：
简单说就是一个bool数组，数组每个值是0或1，插入数据时，选择k个hash函数，计算k个位置，把数组的这k个位置设为1，查询是否插入过的时候，同样求k个hash，判断每一位是否为1。大家看完应该就想到了，这样的判断不是百分百准确的，查询时，如果有一位不是1，那可以100%确定没有插入过，但是如果全是1，也不能确定一定插入过，因为hash函数是可能有冲突的。要怎样提高判断准确率，这个和数组大小，hash函数个数k都有关系。直接给出结果：
n是要插入的元素个数，p是期望的错误率

数组长度 = -1 * n * Math.Log(p) / (Ln2 * Ln2)
hash函数个数 = Ln2 * this.BloomLength / n

照我们前面说的标签业务，正好是大部分用户不在群组里，所以布隆过滤器正合适。

接下来就是具体的实现，也很简单了。

布隆过滤器什么时候计算：定时任务生成群组的时候，顺便把群组的布隆过滤器计算了，也存在redis里。

从哪里读：我们用布隆过滤器本来就是为了减少redis的访问，所以我们不可能每次去redis查，因为布隆过滤器占用空间小的优点，我们可以把他缓存在服务器本地，这样就能过滤掉大量redis查询。

这样我们就通过使用布隆过滤器，既花费较少的空间，又过滤了大量的请求