Redis-缓存穿透/击穿/雪崩

1. 简介

如图所示，一个正常的请求

1. 客户端请求张铁牛的博客。
2. 服务首先会请求redis，查看请求的内容是否存在。
3. redis将请求结果返回给服务，若是返回的结果有数据则执行7；若是没有数据则会继续往下执行。
4. 服务从数据库中查询请求的数据。
5. 数据库将查询的结果返回给服务。
6. 若是数据库有返回数据，则将返回的结果添加到redis。
7. 将请求到的数据返回给客户端。

2. 缓存穿透

2.1描述

经过接口访问一个缓存和数据库都不存在的数据。

由于服务出于容错考虑，当请求从持久层查不到数据则不写入缓存，这将致使请求这个不存在的数据每次都要到持久层去查询，失去了缓存的意义。

此时，缓存起不到保护后端持久层的意义，就像被穿透了同样。致使数据库存在被打挂的风险。

2.2 解决方案

1. 接口请求参数的校验。对请求的接口进行鉴权，数据合法性的校验等；好比查询的userId不能是负值或者包含非法字符等。
2. 当数据库返回空值时，将空值缓存到redis，并设置合理的过时时间。
3. 布隆过滤器。使用布隆过滤器存储全部可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。

3. 缓存击穿

3.1 描述

某个热点 key，在缓存过时的一瞬间，同时有大量的请求打进来，因为此时缓存过时了，因此请求最终都会走到数据库，形成瞬时数据库请求量大、压力骤增，致使数据库存在被打挂的风险。

3.2 解决方案

1. 加互斥锁。当热点key过时后，大量的请求涌入时，只有第一个请求能获取锁并阻塞，此时该请求查询数据库，并将查询结果写入redis后释放锁。后续的请求直接走缓存。
2. 设置缓存不过时或者后台有线程一直给热点数据续期。

4. 缓存雪崩

4.1 描述

大量的热点数据过时时间相同，致使数据在同一时刻集体失效。形成瞬时数据库请求量大、压力骤增，引发雪崩，致使数据库存在被打挂的风险。

4.1 解决方案

1. 将热点数据的过时时间打散。给热点数据设置过时时间时加个随机值。

2. 加互斥锁。当热点key过时后，大量的请求涌入时，只有第一个请求能获取锁并阻塞，此时该请求查询数据库，并将查询结果写入redis后释放锁。后续的请求直接走缓存。

3. 设置缓存不过时或者后台有线程一直给热点数据续期。

5. 布隆过滤器

5.1 描述

布隆过滤器是防止缓存穿透的方案之一。布隆过滤器主要是解决大规模数据下不须要精确过滤的业务场景，如检查垃圾邮件地址，爬虫URL地址去重， 解决缓存穿透问题等。

布隆过滤器：在一个存在必定数量的集合中过滤一个对应的元素，判断该元素是否必定不在集合中或者可能在集合中。它的优势是空间效率和查询时间都比通常的算法要好的多，缺点是有必定的误识别率和删除困难。

5.2 数据结构

布隆过滤器是基于bitmap和若干个hash算法实现的。以下图所示：

1. 元素tie通过hash1，hash2，hash3运算出对应的三个值落到了数组下标为4，6，8的位置上，并将其位置的默认值0，修改为1。
2. 元素niu同理落到了数组下标为1，3，4的位置上，并将其位置的默认值0，修改为1。

此时bitmap中已经存储了tie，niu数据元素。

当请求想经过布隆过滤器判断tie元素在程序中是否存在时，经过hash运算结果到数组对应下标位置上发现值已经都被置为1，此时返回true。

5.3 “必定不在集合中”

如图所示：

​ 元素zhang经过布隆过滤器判断时，下标0，2都为0，则直接返回false。

也就是当判断不在bitmap中的元素时，通过hash运算获得的结果在bitmap中只要有一个为0，则该数据必定不存在。

5.4 “可能在集合中”

如图所示：

​ 元素shuaibi经过布隆过滤器判断时，hash运算的结果落到了下标1,3,8上，此时对应下标位置的值都为1，则直接返回true。

这下就尴尬了，由于实际程序中并无数据shuaibi，但布隆过滤器返回的结果显示有这个元素。这就是布隆过滤器的缺点，存在误判状况。

5.5 ”删除困难“

为何布隆过滤器删除困难呢，如图所示：

若是删除了“tie”元素，4号位被置为0，则会影响niu元素的判断，由于4号位为0，进行数据校验时返回0，则会认为程序中没有niu元素。

那小伙伴会问，4号位不置为0，行不行？

若是删除了元素，hash碰撞的数组下标不置为0，那么若是继续验证该元素的话，布隆过滤器会继续返回true，但实际上元素已经删除了。

因此布隆过滤器数据删除困难，若是要删除的话，能够参考Counting Bloom Filter。

5.6 为何不使用HashMap呢？

若是用HashSet或Hashmap存储的话，每个用户ID都要存成int，占4个字节即32bit。而一个用户在bitmap中只须要1个bit，内存节省了32倍。

而且大数据量会产生大量的hash冲突，结果就是产生hash冲突的数据，仍然会进行遍历挨个比对（即便转成红黑树），这样对内存空间和查询效率的提高，仍然是有限的。

固然：数据量不大时，尽管使用。并且hashmap方便进行CRUD😂