Redis入门(六)应用问题

xxyneymar

已于 2022-03-22 18:38:49 修改

阅读量495

点赞数

分类专栏： redis 文章标签： redis 缓存

于 2022-01-14 16:50:16 首次发布

本文链接：https://blog.csdn.net/xxyneymar/article/details/122493303

版权

redis 专栏收录该内容

6 篇文章 1 订阅

订阅专栏

13.4.5 优化之LUA脚本保证删除的原子性

第十三章 Redis应用问题解决

Redis在使用中，作为数据库的缓存进行使用。当一个请求过来，先在缓存中取数据，取到直接返回结果，取不到时从数据库中取；数据库取到数据会更新缓存，并返回结果，如果数据库也没有取到，直接返回空结果。

13.1 缓存穿透

13.1.1 问题描述

key对应的数据在数据库并不存在，每次针对此key的请求从缓存中获取不到(缓存redis的命中率突然降低)，请求都会进入数据库，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，这个请求就会一直访问数据库，最后可能压垮数据库。

13.1.2 解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

①对空值缓存：如果一个查询返回的数据为空(不管是数据是否不存在)，我们仍然把这个空结果(null)进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

②设置可访问的名单(白名单)：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

③采用布隆过滤器：布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数(哈希函数)。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

④进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

13.2 缓存击穿

13.2.1 问题描述

key对应的数据存在，但是某个时间在redis中过期，此时若有大量并发请求都要找这个key，此时redis中该key过期，那么这些请求都会从数据库中查找并更新到缓存中，但是这瞬间大并发的请求可能会把数据库压垮。

13.2.2 解决方案

key可能会在某些时间点被超高并发地访问，是一种非常"热点"的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题(某个热门key过期)。

①预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。

②实时调整：现场监控哪些数据热门，实时调整key的过期时长。

③使用锁：就是在缓存失效的时候(判断拿出来的值为空)，不是立即去访问数据库，先使用缓存工具的某些带成功操作返回值的操作(比如Redis的SETNX，key不存在会为key设定指定的值)去set一个mutex key，当操作返回成功时，再进行访问数据库的操作，并更新缓存,最后删除mutex key；当操作返回失败，证明有线程在访问数据库，当前线程睡眠一段时间再重试整个get缓存的方法。

13.3 缓存雪崩

13.3.1 问题描述

key对应的数据存在，但是某一时段大量key过期(与缓存击穿不同)，此时如果大量并发请求过来，都发现缓存过期了去访问数据库，此时过大的并发请求可能会压垮数据库。

13.3.2 解决方案

①构建多级缓存架构：nginx缓存 + redis缓存 + 其他缓存(ehcache等)。

②使用锁或队列：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况。

③设置过期标志更新缓存：记录缓存数据是否过期(设置提前量)，如果过期会触发通知另外的线程在后台去更新实际key的缓存。

④将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

13.4 分布式锁

13.4.1 问题描述

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。简而言之，就是一个锁要对集群中所有的物理机都有效。

实现方案：

①基于数据库实现

②基于缓存(redis等)实现

③基于Zookeeper实现

每一种分布式锁解决方案都有各自优缺点，redis性能最高，Zookeeper可靠性最高。

13.4.2 使用redis实现分布式锁

命令：

setnx <key> <value>：只有在key不存在时，设置key的value值。key存在不会覆盖原值。

多个客户端同时获取锁(setnx)，只有一个能获取成功，执行业务逻辑(从数据库获取数据，放入缓存)，执行完成后释放锁(del)，其他客户端在没有获得锁的情况下等待重试。

@GetMapping("testLock")
public void testLock(){
    //1获取锁，setnx
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        redisTemplate.delete("lock");

    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

13.4.3 优化之设置锁的过期时间

防止一个客户端长期占用锁，导致其他客户端一直处于等待重试的状态，给锁设置一个过期时间，让它自动释放。有两种方法：

①通过expire设置过期时间,但是缺乏原子性，如果在setnx和expire之间出现异常，锁也无法

释放。

②在set时指定过期时间，上锁的同时设置过期时间(推荐)。

set <key> <value> nx ex <time>

//设置过期时间
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111",3,TimeUnit.SECONDS);

13.4.4 优化之UUID防误删

设置过期时间后，还存在一个问题，误删锁的问题：

此时利用一个UUID来判断是不是自己的锁：

@GetMapping("testLock")
public void testLock(){
    //1获取锁，setnx
    String uuid = UUID.randomUUID().toString();//获取一个uuid
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid,3,TimeUnit.SECONDS);
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        if (uuid.equals((String)redisTemplate.opsForValue().get("lock"))){
            redisTemplate.delete("lock");
        }
    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

13.4.5 优化之LUA脚本保证删除的原子性

此时因为比较uuid的操作和删除锁的操作不具有原子性，因此右可能出现下面的情况：

使用LUA脚本来实现内嵌的原子操作：

 // 定义lua 脚本
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 使用redis执行lua执行
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
redisScript.setScriptText(script);
// 设置一下返回值类型 为Long
// 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
// 那么返回字符串与0 会有发生错误。
redisScript.setResultType(Long.class);
// 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);

13.4.6 总结

为了确保分布式锁可用，至少要确保锁的实现同时满足以下四个条件：

①互斥性。在任意时刻，只有一个客户端能持有锁。

②不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其

他客户端能加锁。

③加锁和解锁必须是同一客户端，客户端不能把别人加的锁给解了。

④加锁和解锁必须具有原子性。

第十四章 Redis6.0新功能

14.1 ACL

14.1.1 简介

ACL是Access Control List(访问控制列表)的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。

在Redis 5版本之前，Redis安全规则只有密码控制，还有通过rename来调整高危命令比如 flushdb，KEYS *，shutdown等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制：

①接入权限：用户名和密码

②可以执行的命令

③可以操作的key

14.1.2 命令

①使用acl list命令展现用户权限列表：

②使用acl cat命令：

查看添加权限指令类别：

加参数类型名可以查看类型下具体命令：

③使用acl whoami命令查看当前用户：

④使用aclsetuser命令创建和编辑用户ACL：

ACL规则
类型	参数	说明
启动和禁用用户	on	激活某用户账号
启动和禁用用户	off	禁用某用户账号。注意，已验证的连接仍然可以工作。如果默认用户被标记为off，则新连接将在未进行身份验证的情况下启动，并要求用户使用AUTH选项发送AUTH或HELLO，以便以某种方式进行身份验证。
权限的添加删除	+<command>	将指令添加到用户可以调用的指令列表中
	-<command>	从用户可执行指令列表移除指令
	+@<category>	添加该类别中用户要调用的所有指令，有效类别为@admin、@set、@sortedset…等，通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。
	-@<actegory>	从用户可调用指令中移除类别
	allcommands	+@all的别名
	nocommand	-@all的别名
可操作键的添加或删除	~<pattern>	添加可作为用户可操作的键的模式。例如~*允许所有的键

通过命令创建新用户默认权限：在示例中，我根本没有指定任何规则。如果用户不存在，这

将使用just created的默认属性来创建用户。如果用户已经存在，则上面的命令将不执行任何操

作。

设置有用户名、密码、ACL权限、并启用的用户：

切换用户，验证权限：

14.2 IO多线程

14.2.1 简介

IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

14.2.2 原理架构

Redis 6加入多线程,但跟Memcached这种从IO处理到数据访问多线程的实现模式有些差异。Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制key、lua、事务，LPUSH/LPOP等等的并发问题。整体的设计大体如下：

另外，多线程IO默认也是不开启的，需要再配置文件中配置：

17.3 工具支持Cluster

之前老版Redis想要搭集群需要单独安装ruby环境，Redis 5将redis-trib.rb的功能集成到redis-cli。另外官方redis-benchmark工具开始支持cluster模式了，通过多线程的方式对多个分片进行压测。

17.4 其他新功能

Redis6新功能还有：

①RESP3：新的Redis通信协议，优化服务端与客户端之间通信

②Client side caching客户端缓存：基于RESP3协议实现的客户端缓存功能。为了进一步提升

缓存的性能，将客户端经常访问的数据cache到客户端。减少TCP网络交互。

③Proxy集群代理模式：Proxy 功能，让Cluster拥有像单实例一样的接入方式，降低大家使用

cluster的门槛。不过需要注意的是代理不改变Cluster的功能限制，不支持的命令还是不会支

持，比如跨slot的多Key操作。

④Modules API：Redis 6中模块API开发进展非常大，因为Redis Labs为了开发复杂的功能，

从一开始就用上Redis模块。Redis可以变成一个框架，利用Modules来构建不同系统，而不

需要从头开始写然后还要BSD许可。Redis一开始就是一个向编写各种系统开放的平台。

PS：根据尚硅谷课程整理，如有侵权，联系删除。

xxyneymar

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Redis入门(六)应用问题

目录第十三章 Redis应用问题解决13.1 缓存穿透13.1.1 问题描述13.1.2 解决方案13.2 缓存击穿13.2.1 问题描述13.2.2 解决方案13.3 缓存雪崩13.3.1 问题描述13.3.2 解决方案13.4 分布式锁13.4.1 问题描述13.4.2 使用redis实现分布式锁13.4.3 优化之设置锁的过期时间13.4.4 优化之UUID防误删13.4.5 优化之LUA脚本保证删除的原子性13.4.6总结第十.
复制链接

扫一扫