缓存穿透与布隆过滤器（Bloom Filter）

缓存穿透

在高并发场景中，为了避免请求直接打到数据库上（会导致数据库出现性能问题，从而影响整个系统），常使用缓存来处理大部分请求，如memcached、ehcache、redis等。
但对于一些恶意请求，传统缓存机制却难以应对，如存在以下场景：

接口参数为String id，业务处理为获取此参数，执行sql: select * from user where id = ? limit 1;

正常用户请求参数为25，业务处理则为

select * from user where id = 25 limit 1;

正常返回所查询的user表中id为25的信息，然后将次数据放到缓存中，如redis中，设置key=25,value=user.toString(),再有查询id 为25的请求，可以直接返回redis中的数据，而不用反复查询数据库。

但是如果存在请求参数为-1，业务处理则为

select * from user where id = -1 limit 1;

一般情况下，数据库中不会存在id为-1的数据，返回结果为空，所以缓存中也不会存在数据。如果存在大量的此类请求，则全部会打到数据库上，导致性能问题，从而影响整个系统，缓存变成了摆设，没有起到处理重复请求的作用，此种情况叫做缓存穿透

解决方案

• 应对缓存穿透有多种办法，如建立无效请求的黑名单，查询参数在黑名单中的，可以直接被拦截；
• 前级放一个有效数据的集合，记录所有的key，根据集合来判断；
• 等等。

但上述方案都存在很大的弊端

• 需要一个无限大的空间来存储不存在的信息，不合理；
• 集合大小和数据库大小正相关，消耗严重；
• 需要跟着数据库来实时更新。

布隆过滤器（Bloom Filter）

1. 简介

• 是一个很长的二进制向量和一系列的随机映射函数

• 用于检测一个元素是否存在于某个集合中

• 空间效率和查询时间远优于一般算法

• 存在一定的误识别率并且无法删除元素

2. 算法介绍

①使用一系列的随机映射函数将元素映射到二进制向量的上（每一个函数可设置一个1），以16位向量举例，因此可以得到

1010101000101000

②在对元素进行检测判别时

③使用同样的映射函数完成映射，得到

0100101010000000

与上一步得到的向量按位进行或运算

        1010101000101000

        0100101010000000

----------------------------

        1110101010101000

得到的向量与原向量不相等，因此可以得出结论，此元素不存在于集合中。

3. 布隆过滤器的误判别

①按照上述过程生成二进制向量

②检测某个不存在的元素

得到二进制向量

0010100010100000

与上一步生成的二进制向量按位进行或运算

        1010101000101000

        0010100010100000

----------------------------

        1010101000101000

得到的二进制向量与原向量相等，因此会被误识别为“存在”。

注：布隆过滤器的误识别率与二进制向量的长度、存储元素个数有关系。

JAVA使用

guava.jar已对布隆过滤器进行封装，在pom文件中引入依赖包

		<dependency>
			<groupId>com.google.guava</groupId>
			<artifactId>guava</artifactId>
			<version>23.0</version>
		</dependency>

创建布隆过滤器

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), total, fpp)