java redis缓存使用-redis用作缓存，扛并发；改善方案

Redis我们一般是用作缓存，扛并发；或者用于某些特定的业务场景，比如前面说到redis各种数据类型的使用场景以及redis的哨兵和集群模式。

这里主要整理了下 redis用作缓存，存在的一些问题，以及改善方案。

简单的流程就像这个样子，一般请先到缓存区获取，如果缓存没有再到后端的数据库去查询。

1. 缓存穿透

缓存穿透是指，是指查询一个根本不存在数据，这样缓存层里面没有，就会去访问后面的存储层了。如果有大量的这种恶意请求过来，都打向后面的存储层。显然我们的存储层是扛不住这样的压力。这样缓存就失去了保护后面存储的意义了。

解决方案：

1.缓存空对象

对于缓存穿透，可以采用缓存空对象，第一次进来缓存和 DB都没有，就存个空对象到缓存里面。但是如果大批量的恶意请求过来，这样做就会导致缓存的key暴增，显然不是一个很好的方案。

2. 布隆过滤器

对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在； 但是 它说不存在时，那就肯定不存在。布隆过滤器是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的hash值算得比较均匀 。向布隆过滤器中添加 key 时，会使用多个hash 函数对key进行hash分别算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个hash函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就 完成了 add 操作。

向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为1，只要有一个位为0，那么说明布隆过滤器中这个key 肯定 不存在。 但是 都是 1，这并不能说明这个key就一定存在，只是极有可能存在，因为这些位被置为1可能是因为其它的key存在所致。

guvua包 布隆过滤器的使用，导包

        
            com.google.guava
            guava
        

伪代码：

    public void bloomFilterTest() {
        BloomFilter bloomFilter = BloomFilter.create(
                Funnels.stringFunnel(Charset.forName("UTF-8")),
                1000, //期望存入的数据个数
                0.001);//误差率
        //添加到布隆过滤器
        String[] keys = new String[1000];
        for (String key: keys) {
            bloomFilter.put(key);
        }
        String key = "key";
        boolean exist = bloomFilter.mightContain(key);
        if (!exist) {
            return;
        }
        //todo 存在才去缓存获取
    }

可以看到这个类里面有很多的hash算法：com.google.common.hash.Hashing

redisson也有布隆过滤器的实现。

2.缓存失效

由于大批量的 key同时失效，导致，大量的请求同时打向数据库，造成数据库压力过大，甚至直接挂掉。我们在批量写入缓存的时候，设置超时时间，可以是一个固定时间+随机时间方式来生成，这样就可以错开失效时间。

3.缓存雪崩

缓存雪崩是指缓存层挂掉之后，所有请求都打向数据库，数据库扛不住，也可能挂掉，就导致对应的服务也挂掉，也会影响上游的调用服务。这样的级联问题。就像雪崩最开始一小片，然后越来越大，导致整个服务崩溃。

解决方案：

1.保证缓存层的高可用性，比如 redis哨兵或者redis集群。

2.各依赖服务之间做限流，熔断，降级等，比如 Hystri，阿里的sentinel

4.缓存一致性

引入缓存之后，随之而来的问题就是当DB数据更新时，缓存中的数据就会与db数据不一致。所以数据修改时是先更新缓存还是先更新DB？

如果先更新缓存，然后更新DB失败，那么下一个请求过来读取的缓存数据不是最新的。而我们实际上最终数据肯定都是以DB为准的。

先更新db 在更新缓存，这是在更新DB的时候来的请求读取的数据也是不是最新的

淘汰缓存——更新DB——重新刷进缓存，在更新db是来的请求在缓存没有数据，就会去请求DB，如果并发 可能操作多各请求去写DB，那么就需要加锁了

加锁——淘汰缓存——更新DB——重新刷进缓存，这样相对而言就比较保险了

5.bigkey问题

Bigkey是什么？在redis中，一个字符串最大512MB；hash，list，set，zset可以存储2^31 - 1 个元素。

一般来说字符串超过 10kb，其他的几种元素个数不要超过5000个。

可以使用 src/redis-cli --bigkeys 来查看bigkeyjava redis缓存使用，我这里设置了一个30多K的字符串，看下扫描结果，扫除了一个字符串类型的bigkey，4084字节。

Bigkey有哪些危害。一是删除时阻塞其他请求，比如一个bigkey，平时都没什么，但是设置了过期时间，到期了删除时，可能就会阻塞其他请求，4.0之后可以开启lazyfree-lazy- expire yes来异步删除；二是造成网络拥堵，比如一个key数据量达到1MB，假设并发量1000，这个时候获取它就会产生1000MB的流量java redis缓存使用，千兆网卡，峰值的速率也才128MB/S,并不是扛不住并发，而是会占用大量网络带宽。

对于很大 list，set这些，我们可以将数据拆分，生成一个系列的的key去存放数据。如果是redis集群这些key自然就可以分到不同的小主从上面去，如果是单机，那么可以自己实现一个路由算法，来如何获取这一系列key中的某一个。

6. 客户端使用

1.避免多个服务使用一个 redis实例，如果实在有，可以看下将业务拆分，把这些公共数据服务化。

2.使用连接池，控制有效连接，同时也提高效率。连接池重要参数设置：

1 maxActive 资源池中最大连接数 默认值 8

2 maxIdle 资源池允许最大空闲 的连接数 默认值 8

3 minIdle 资源池确保最少空闲 的连接数 默认值 0

4 blockWhenExhausted 当资源池用尽后，调用者是否要等待。只有当为true时，下面的maxWaitMillis才会生效 ，默认值 true 建议使用默认值

5 maxWaitMillis 当资源池连接用尽后，调用者的最大等待时间(单位为毫秒) -1：表示永不超时 不建议使用默认值

6 testOnBorrow 向资源池借用连接时是否做连接有效性检测(ping)，无效连接会被移除 默认值 false 业务量很大时候建议 设置为false(多一次 ping的开销)。

7 testOnReturn 向资源池归还连接时是否做连接有效性检测(ping)，无效连接会被移除 默认值 false 业务量很大时候建议 设置为false(多一次 ping的开销)。

8 jmxEnabled 是否开启jmx监控，可用于监控 默认值 true 建议开启，但应用本身也要开启

前面三个参数相对而言更重要，单独拎出来再说下：

最大连接数 maxActive ：

可以从业务希望的并发量，客户端执行时间， redis资源设置（应用个数（集群部署多少个实例） * maxActive