缓存穿透？缓存雪崩？缓存击穿？布隆过滤器？我觉得我解释清除了

# 下载Rebloom插件
wget https://github.com/RedisLabsModules/rebloom/archive/v1.1.1.tar.gz

# 解压 编译安装
tar zxvf v1.1.1.tar.gz
cd rebloom-1.1.1
make

# 配置redis.conf，添加如下配置，保存退出
loadmodule /xxx/redis/redis-5.0.8/RedisBloom-2.2.2/redisbloom.so

# 重启redis服务
redis-server redis.conf

# 大家客户端
redis-cli -h 127.0.0.1 -p 6379

# 测试命令
bf.add test xxx
命令成功说明开启成功

大叔这里要给大家介绍另一个比较简单的体验方法：使用docker 直接在redis中体验布隆过滤器。

1、查找并下载镜像

$ docker search rebloom

$ docker pull redislabs/rebloom

2、检测下载好的镜像

$ docker images
REPOSITORY                                     TAG                   IMAGE ID            CREATED             SIZE
redislabs/rebloom                              latest                03841e395ca0        3 months ago        104MB

3、启动容器

$ docker run -d -p 6379:6379 --name bloomfilter redislabs/rebloom

4、体验布隆过滤器

$ docker exec -it bloomfilter redis-cli
127.0.0.1:6379> bf.add urls dashu
(integer) 1
127.0.0.1:6379> bf.exists urls dashu
(integer) 1
127.0.0.1:6379> bf.reserve test 0.01 100
OK
127.0.0.1:6379> bf.reserve urls 0.01 100
(error) ERR item exists
127.0.0.1:6379>

bf.add 添加元素到布隆过滤器中
bf.exists 判断某个元素是否存在过滤器中
bf.reserve 设置布隆过滤器允许的错误率以及可以存储元素的个数 【注意：执行这个命令之前过滤器的名字应该不存在，如果执行之前就存在会报错：(error) ERR item exists】

哈希函数个数和布隆过滤器长度

上面我们从布隆过滤器自身的属性来优化其准确性，实际上，影响布隆过滤器误报率的元素还有 哈希函数 和 布隆过滤器长度 。它们之间存在着以下关系：

k 为哈希函数个数，m 为布隆过滤器长度，n 为插入的元素个数，p 为误报率。

显然，过小的布隆过滤器很快所有的 bit 位均为 1，那么查询任何值都会返回“可能存在”，起不到过滤的目的了。布隆过滤器的长度会直接影响误报率，布隆过滤器越长其误报率越小。

另外，哈希函数的个数也需要权衡，个数越多则布隆过滤器 bit 位置为 1 的速度越快，且布隆过滤器的效率越低；但是如果太少的话，那我们的误报率会变高。

布隆过滤器只能插入数据判断是否存在，不能删除，而且只能保证【不存在】判断绝对准确

以上就是缓存穿透的相关内容，其中布隆过滤器的知识建议mark!

缓存雪崩

定义

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重，引起雪崩。

解决方案

可以给缓存设置过期时间时加上一个随机值时间，使得每个key的过期时间分布开来，不会集中在同一时刻失效。

缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常 “热点” 的数据。这个时候，缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

换句话说：一个存在的热点key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。

解决方案

1、使用分布式锁

简单地来说，就是在缓存失效的时候（判断拿出来的值为空），采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法，简单代码实现：

public String get(key) {

    String value = redis.get(key);

    if (value == null) { //代表缓存值过期
        //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
            sleep(50);
            get(key);  //重试
        }
    } else {
        return value;      
    }
}

2、“永远不过期” 这里的“永远不过期”包含两层意思：

从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期；
从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。

这种方式还是非常友好的，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据。

伪代码实现：

String get(final String key) {  
    V v = redis.get(key);  
    String value = v.getValue();  
    long timeout = v.getTimeout();  
    if (v.timeout <= System.currentTimeMillis()) {  
        // 异步更新后台异常执行  
          threadPool.execute(new Runnable() {  
              public void run() {  
                  String keyMutex = "mutex:" + key;  
                  if (redis.setnx(keyMutex, "1")) {  
                        // 3 min timeout to avoid mutex holder crash  
                        redis.expire(keyMutex, 3 * 60);  
                        String dbValue = db.get(key);  
                        redis.set(key, dbValue);  
                        redis.delete(keyMutex);  
                  }  
              }  
          });  
    }  
    return value;  
}

以上就是今天要跟大家分享的内容，欢迎留言交流～