Redis使用指南

2019/04/10 10:10
阅读数 28

原文链接

能坚持别人不能坚持的,才能拥有别人未曾拥有的。
关注编程大道公众号,让我们一同坚持心中所想,一起成长!!

设置过期时间、释放资源

使用Redis做K-V存储,一定要注意过期时间的把控,任何K-V的存储都要设置过期时间,不管多长时间。一般在封装Redis操作工具类时提供默认使用系统公共超时时间的操作API,避免新手在使用时不设置过期时间,导致内存的浪费。另外,通过连接池 Jedis jedis = JedisPool.getResource(); 这样获取Redis连接最好使用try/finally块,并且在finally块中调用 jedis.close(); 将连接归还给连接池,否则将会一直持有连接,很有可能导致在将来的某一时刻报拿不到连接的错。这也是之前某一个同事犯过的错导致生产bug!

缓存穿透

你以为Redis做缓存就万无一失吗?就单纯的遵循那种经典操作吗?(即:请求来了,先看缓存有没有,有直接返回,没有就查数据库,数据库有的话先存缓存,然后返回,数据库没有就返回空)这样就是Redis缓存的正确姿势吗?如果你这样做,很可能疏忽一点,那就是缓存穿透。如之前在项目中做的一个需求-页面广告可配置化自动上下线(我在之前专门写过一篇文章介绍这个需求的一步步演进过程,对Redis新手很有帮助,感兴趣的可以去看看),简单的提一下吧,就是比如在支付完成的页面大家都应该见过吧,比如支付完成后的结果页,可能会弹出来一个红包什么的,页面下方的广告位等,就是类似的这样一个需求。因为这个页面访问量很大,进这个页面就查这个广告位的数据,当运营最近不想配置广告了,这边查到的是不是就是是空啊?数据库也是空的,缓存也没有数据,那很多请求都来,这样就平白无故的造成了数据库的压力呀,多么的浪费!如果是别的其他业务,黑客钻了空子,专门请求你系统根本不存在的数据,请求多了,都打到数据库,是很有可能把你数据库打死的。如果你在做需求的时候没想到这一点,那后续出了问题,你就等着背锅了。

怎么避免呢?

好办,可以将数据库也不存在的数据存个null值或一个空json(总之你自己约定好就行),也给放到Redis里,设置个较短的过期时间,下次再来取的时候看到是空就直接返回。另外,可以使用布隆过滤器做一层系统级的防护,专门去拦截系统中根本不存在的key。

缓存雪崩

刚说完缓存穿透,再聊聊缓存雪崩。比如你将用户数据放到缓存里,当某一时刻这些数据全部都过期了,大量请求都过来,发现缓存无法命中,不就都去数据库了吗,数据库一下子来这么多请求不就搞挂了吗?解决办法就是尽量是key的过期时间分散开,不要集中。在一个固定的过期时间上+一个随机值,比如你设置的过期时间是5小时,你可以加一个0-600秒的随机值。

缓存并发

缓存失效时多个请求同时请求同一个key,都发现缓存中空了,都去查数据库,这不是浪费吗,正常一个去查就行了,查完放缓存别的请求直接从缓存拿就行了。这就是缓存并发问题。当请求非常的多的时候,会对数据库造成很大的冲击,也是有可能把数据库搞挂的吧?怎么解决,可以对更新缓存的操作加锁,使用synchronized吗?不行,因为生产上是分布式部署的,需要使用redis分布式锁。

例如,当缓存数据失效的时候,某一线程使用资源ID作为key尝试加分布式锁,加锁成功的线程执行更新缓存的操作将查到的数据放入缓存缓存中,其他线程就可以直接使用缓存数据了。

分布式锁

正如上面所说,在集群部署的情况下synchronized就失效了,所以分布式锁就派上用场了。常见的分布式锁的实现方式有三种:基于数据库,基于Redis,基于Zookeeper。

Redis分布式锁需要特别注意的点就是锁的过期时间,如,使用redis的setnx命令,设置成功即表示拿到锁,然后设置过期时间,命令执行失败的线程表示获取锁失败。一定要注意锁的过期时间的设置,有加锁的操作,也要有解锁的操作。如之前我们项目的一个临时性的一个组团竞走的活动,10人成团竞走PK的活动,在组团阶段,用户可以邀请朋友加入自己的团。我们的团数据是存放在Redis中的,包括每个团的人数。当用户发起入团操作时,后台逻辑会从redis取该团的现有成员数,如果小于10才能继续走下面的逻辑。当并发场景下,如团长分享给很多人入团邀请,这些人的入团请求并发执行的情况下很有可能能造成组团人数超过10人的情况。因为在并发场景下,执行获取当前团成员数的这行代码会被多个请求获取到,比如临界的时候,团成员已经有了9个,同时来了俩入团请求,如果不加控制,同时执行读取现有团成员个数时都读到的是9,然后都执行入团操作,就会造成团成员超过10人的bug。

所以在入团请求的逻辑上,要加分布式锁,获取到锁才能执行后续逻辑。因为获取锁的操作是使用setnx命令,并没有等待锁的机制,我们需要在获取锁的逻辑加一个自旋,每隔一定时间尝试一次获取,超过一定时间后返回加锁失败。

public boolean tryLock(String lockKey,long expireTime){
    long waitTime = 0;
    //setIfAbsent使用的是redis的setnx方法
    boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey,"jingzouLock",
            expireTime,TimeUnit.MILLISECONDS);
    if(success==true){
        return success;
    }else{
        while(success==false && waitTime <50000L){
            success = redisTemplate.opsForValue().setIfAbsent(lockKey,"jingzouLock",
                    expireTime, TimeUnit.MILLISECONDS);
            try{
                Thread.sleep(100);
            }catch(Exception e){}
            waitTime+=100L;
        }
    }
    return success;
}

另外,还需要遵循“解铃还须系铃人”的原则,谁加的锁谁解,不然自己加的锁,被别人解了也是会造成问题的。例如,用户A,请求入团,拿到分布式锁,如果A因为某些原因在锁超时时间内没有执行完代码,锁就过期自动释放了,如果此时B请求加入同一个团,拿到了分布式锁,如果此时A请求执行完了,释放锁了,但是释放的是B的锁,这样也有可能造成团人数超过10的bug。所以,设置分布式锁时的value可以设置成不同的值,如A请求是用户ID为12的用户,设置分布式锁的时候就value就可以用这个唯一的元素,当解锁的时候再验证value是12时才能执行解锁操作。

如上加锁代码,我们增加一个参数String value传入动态值,在上述场景中可以用用户ID,代替我们写死的"jingzouLock"。然后在释放锁的方法里,我们先判断value值,相同再执行删除。

public void releaseLock(String lockKey,String value){
    String valueInRedis = redisTemplate.get(lockKey);
    if(value.equals(valueInRedis)){
        redisTemplate.delete(lockKey);
    }
}

还有一种场景需要考虑。当Redis master发生故障,主备切换时往往会造成数据丢失,包括分布式锁的Key-Value。这样就会导致锁间接的被释放了,假如操作还没执行完,锁被其他请求拿到了,分布式锁就起不到作用了。

考虑到这方面的问题,Redis官方提供了Redlock算法,以及相应的开源实现Redisson。用到分布式锁的场景,大家可以直接使用 Redisson,非常方便,后期可能会写一写Redisson的技术干货。

原文地址:https://mp.weixin.qq.com/s/2sXEkRsrC9b9RBJns3fnnw

另外,如果系统对可靠性要求很高,如需用到分布式锁,建议使用分布式锁的另外实现方式,如:Zookeeper,etcd等。

好了,今天就分享到这。如果感觉本文对您有帮助,有劳点下在看,把知识分享给更多的人哦

你可能感兴趣的文章:

觉得好看,请点赞哦~

 

关注公众号 编程大道 ,第一时间获文章推送。

觉得好看,请 点赞、关注、转发 哦~

原文出处:https://www.cnblogs.com/ibigboy/p/12498129.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部