从原理到实战：如何通过布隆过滤器防止缓存击穿

最新推荐文章于 2024-04-12 12:59:13 发布

我有一头小花驴

最新推荐文章于 2024-04-12 12:59:13 发布

阅读量248

点赞数

分类专栏：计算机程序员程序人生文章标签：缓存数据库

本文链接：https://blog.csdn.net/x275920/article/details/130910032

版权

为什么引入

我们的业务中经常会遇到穿库的问题，通常可以通过缓存解决。如果数据维度比较多，结果数据集合比较大时，缓存的效果就不明显了。

因此为了解决穿库的问题，我们引入Bloom Filter。

适合的场景

数据库防止穿库 Google Bigtable，Apache HBase和Apache Cassandra以及Postgresql 使用BloomFilter来减少不存在的行或列的磁盘查找。避免代价高昂的磁盘查找会大大提高数据库查询操作的性能。如同一开始的业务场景。如果数据量较大，不方便放在缓存中。需要对请求做拦截防止穿库。
缓存宕机缓存宕机的场景，使用布隆过滤器会造成一定程度的误判。原因是除了Bloom Filter 本身有误判率，宕机之前的缓存不一定能覆盖到所有DB中的数据，当宕机后用户请求了一个以前从未请求的数据，这个时候就会产生误判。当然，缓存宕机时使用布隆过滤器作为应急的方式，这种情况应该也是可以忍受的。
WEB拦截器相同请求拦截防止被攻击。用户第一次请求，将请求参数放入BloomFilter中，当第二次请求时，先判断请求参数是否被BloomFilter命中。可以提高缓存命中率
恶意地址检测 chrome 浏览器检查是否是恶意地址。首先针对本地BloomFilter检查任何URL，并且仅当BloomFilter返回肯定结果时才对所执行的URL进行全面检查（并且用户警告，如果它也返回肯定结果）。
比特币加速 bitcoin 使用BloomFilter来加速钱包同步。

开源项目地址： https://github.com/luw2007/bloomfilter

我们先看看一般业务缓存流程：

编辑

添加图片注释，不超过 140 字（可选）

先查询缓存，缓存不命中再查询数据库。然后将查询结果放在缓存中即使数据不存在，也需要创建一个缓存，用来防止穿库。

这里需要区分一下数据是否存在。如果数据不存在，缓存时间可以设置相对较短，防止因为主从同步等问题，导致问题被放大。

这个流程中存在薄弱的问题是，当用户量太大时，我们会缓存大量数据空数据，并且一旦来一波冷用户，会造成雪崩效应。

对于这种情况，我们产生第二个版本流程:redis过滤冷用户缓存流程

编辑切换为居中

添加图片注释，不超过 140 字（可选）

我们将数据库里面中命中的用户放在redis的set类型中，设置不过期。这样相当把redis当作数据库的索引，只要查询redis，就可以知道是否数据存在。

redis中不存在就可以直接返回结果。如果存在就按照上面提到一般业务缓存流程处理。

聪明的你肯定会想到更多的问题：

问题1需要区分业务场景，结果数据少，我们是可以直接使用redis作为缓存，直接返回数据。结果比较大就不太适合用redis存放了。比如ugc内容，一个评论里面可能存在上万字，业务字段多。

redis使用有很多技巧。bigkey 危害比较大，无论是扩容或缩容带来的内存申请释放，还是查询命令使用不当导致大量数据返回，都会影响redis的稳定。这里就不细谈原因及危害了。

解决bigkey 方法很简单。我们可以使用hash函数来分桶，将数据分散到多个key中。减少单个key的大小，同时不影响查询效率。

问题3是redis存储占用内存太大。因此我们需要减少内存使用。重新思考一下引入redis的目的。redis像一个集合，整个业务就是验证请求的参数是否在集合中。

编辑

添加图片注释，不超过 140 字（可选）

这个结构就像洗澡的时候用的双向阀门：左边热水，右边冷水。

大部分的编程语言都内置了filter。拿python举例，filter函数用于过滤序列，过滤掉不符合条件的元素，返回由符合条件元素组成的列表。

我们看个例子：

</

关注