优缺点

优：

  1. 内存空间消耗小
  2. 较小的误差率判定元素是否在集合内

缺点：

  1. 不支持删除元素
  2. 如果要删除元素， 只能拿全量元素重新构建bloom

数据查询的三种方法：

  1. 方法1: 查询redis， 再查DB
  2. 方法2: 查询redis， 再redis bloom 过滤有效查询， 再查DB
  3. 方法3: redis bloom过滤有效查询，再查redis， 再D查B

方法2,3 都可以。方法3时， bloom 不光过滤了查询DB的无效流量， 也过滤了查询redis的无效流量。 如果大部分都是有效查询场景下， 就会导致每次查询都要一次bloom， 一次redis，浪费了redis资源。

为什么要用bloom fliter

  1. 当有大量无效穿透查询的场景下， redis bloom的查询成本比DB的成本低很多， 能支撑的QPS更高。 可以最大程度的保护DB。
  2. 如果是单机部署场景下，可以考虑内存实现bloom。但是要考虑宕机或者重新部署时， bloom filter没了，要重新构建的问题。
  3. bloom filter 的核心优势就是内存消耗低， 1000万的数据， 采用google guava的hash计算方式， 在0.001的误差范围内， 消耗内存在10MB左右，放在redis中实现非常合适
  4. 分布式环境下，也可以采用本地内存来实现bloom， 属于典型的local cache 问题；如果想要保持一致性， 可以通过数据变更时， 群发MQ消息的方式让应用服务器实例更新。
  • 这个方案在数据变更频次很低而访接口QPS极高时， 可以尝试
  • 否则当有实例 bloom filter数据未及时更新时， 在未更新这个时间间隔内， 用户请求路由到不同应用实例， 就会出现一下能查到，一下查不到奇怪现象
  • 如果数据变更频次很低时， 也可以考虑把bloom fliter 数据放到配置中心里， 让配置中心把数据推送到应用实例上