龙空技术网

Spring Boot 整合 Redis 正确地实现分布式锁

尚硅谷教育 845

前言:

此时各位老铁们对“js多线程锁”大约比较关心,你们都想要分析一些“js多线程锁”的相关知识。那么小编在网摘上网罗了一些关于“js多线程锁””的相关内容,希望兄弟们能喜欢,我们一起来学习一下吧!

理论

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。是为了解决分布式系统中,不同的系统或是同一个系统的不同主机共享同一个资源的问题,它通常会采用互斥来保证程序的一致性

通常的实现方式有三种:

基于 MySQL 的悲观锁来实现分布式锁,这种方式使用的最少,这种实现方式的性能不好,且容易造成死锁,并且MySQL本来业务压力就很大了,再做锁也不太合适

基于 Redis 实现分布式锁,单机版可用setnx实现,多机版建议用Radission

基于 ZooKeeper 实现分布式锁,利用 ZooKeeper 顺序临时节点来实现

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

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

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

具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。

解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。

本文就使用的是Redis的setnx实现,如果Redis是多机版的可以去了解下Radssion,封装的就特别的好,也是官方推荐的

代码

1. 加依赖

引入Spring Boot和Redis整合的快速使用依赖

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency>

2. 加配置

application.properties中加入Redis连接相关配置

spring.redis.host=xxx

spring.redis.port=6379

spring.redis.database=0

spring.redis.password=xxx

spring.redis.timeout=10000

# 设置jedis连接池

spring.redis.jedis.pool.max-active=50

spring.redis.jedis.pool.min-idle=20

3. 重写Redis的序列化规则

默认使用的JDK的序列化,不自己设置一下Redis中的数据是看不懂的

/*** @author Chkl* @create 2020/6/7* @since 1.0.0*/@Componentpublic class RedisConfig {/*** 改造RedisTemplate,重写序列化规则,避免存入序列化内容看不懂* @param connectionFactory* @return*/@Beanpublic RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory connectionFactory) {RedisTemplate redisTemplate = new RedisTemplate();redisTemplate.setConnectionFactory(connectionFactory);// 设置key和value的序列化规则redisTemplate.setValueSerializer(new Jackson2JsonRedisSerializer(Object.class));redisTemplate.setKeySerializer(new StringRedisSerializer());return redisTemplate;}}

4. 如何正确地上锁

直接上代码

@Componentpublic class RedisLock {@Autowiredprivate StringRedisTemplate redisTemplate;private long timeout = 3000;/*** 上锁* @param key 锁标识* @param value 线程标识* @return 上锁状态*/public boolean lock(String key, String value) {long start = System.currentTimeMillis();while (true) {//检测是否超时if (System.currentTimeMillis() - start > timeout) {return false;}//执行set命令Boolean absent = redisTemplate.opsForValue().setIfAbsent(key, value, timeout, TimeUnit.MILLISECONDS);//1//是否成功获取锁if (absent) {return true;}return false;}}}

核心代码就是

Boolean absent = redisTemplate.opsForValue().setIfAbsent(key, value, timeout, TimeUnit.MILLISECONDS);

setIfAbsent方法就相当于命令行下的Setnx方法,指定的 key 不存在时,为 key 设置指定的值

参数分别是key、value、超时时间和时间单位

key,表示针对于这段资源的唯一标识

value,表示针对于这个线程的唯一标识。为什么有了key了还需要设置value呢,就是为了满足四个条件的最后一个:解铃还须系铃人。只有通过key和value的组合才能保证解锁时是同一个线程来解锁

超时时间,必须和setnx一起进行操作,不能再setnx结束后再执行。如果加锁成功了,还没有设置过期时间就宕机了,锁就永远不会过期,变成死锁

5. 如何正确解锁

@Componentpublic class RedisLock {@Autowiredprivate StringRedisTemplate redisTemplate;@Autowiredprivate DefaultRedisScript<Long> redisScript;private static final Long RELEASE_SUCCESS = 1L;/*** 解锁* @param key 锁标识* @param value 线程标识* @return 解锁状态*/public boolean unlock(String key, String value) {//使用Lua脚本:先判断是否是自己设置的锁,再执行删除Long result = redisTemplate.execute(redisScript, Arrays.asList(key,value));//返回最终结果return RELEASE_SUCCESS.equals(result);}/*** @return lua脚本*/@Beanpublic DefaultRedisScript<Long> defaultRedisScript() {DefaultRedisScript<Long> defaultRedisScript = new DefaultRedisScript<>();defaultRedisScript.setResultType(Long.class);defaultRedisScript.setScriptText("if redis.call('get', KEYS[1]) == KEYS[2] then return redis.call('del', KEYS[1]) else return 0 end");return defaultRedisScript;}}

解锁过程需要两步操作

判断操作线程是否是加锁的线程

如果是加锁线程,执行解锁操作

这两步操作也需要原子的进行操作,但是Redis不支持这两步的合并的操作,所以,就只有使用lua脚本实现来保证原子性咯

如果在判断是加锁的线程之后,并且执行解锁之前,锁到期了,被其他线程获得锁了,这时候再进行解锁就会解掉其他线程的锁,使得不满足解铃还须系铃人

6. 实际应用

没有使用分布式锁时的保存文件分块的代码

/*** 保存文件分块编号到redis* @param chunkNumber 分块号* @param identifier 文件唯一编号* @return 文件分块的大小*/@Overridepublic Integer saveChunk(Integer chunkNumber, String identifier) {//从Redis获取已经存在的分块编号集合Set<Integer> oldChunkNumber = (Set<Integer>) JSON.parseObject(redisOperator.get("chunkNumberList_"+identifier),Set.class);//如果不存在分块集合,创建一个集合if (Objects.isNull(oldChunkNumber)) {Set<Integer> newChunkNumber = new HashSet<>();newChunkNumber.add(chunkNumber);redisOperator.set("chunkNumberList_"+identifier, JSON.toJSONString(newChunkNumber),36000);return newChunkNumber.size();//如果分块集合已经存在了,就添加一个编号} else {oldChunkNumber.add(chunkNumber);redisOperator.set("chunkNumberList_"+identifier, JSON.toJSONString(oldChunkNumber),36000);return oldChunkNumber.size();}}

存在的问题是:当并发的请求进来之后,可能获取同一个状态的集合进行修改,修改后直接写入,造成同一个状态获得的集合操作线程覆盖写的现象

使用分布式锁保证同时只能有一个线程能获取到集合并进行修改,避免了覆盖写现象

使用分布式锁代码

/*** 保存文件分块编号到redis* @param chunkNumber 分块号* @param identifier 文件唯一编号* @return 文件分块的大小*/@Overridepublic Integer saveChunk(Integer chunkNumber, String identifier) {//通过UUID生成一个请求线程识别标志作为锁的valueString threadUUID = CoreUtil.getUUID();//上锁,以共享资源标识:文件唯一编号,作为key,以线程标识UUID作为valueredisLock.lock(identifier,threadUUID);//从Redis获取已经存在的分块编号集合Set<Integer> oldChunkNumber = (Set<Integer>) JSON.parseObject(redisOperator.get("chunkNumberList_"+identifier),Set.class);//如果不存在分块集合,创建一个集合if (Objects.isNull(oldChunkNumber)) {Set<Integer> newChunkNumber = new HashSet<>();newChunkNumber.add(chunkNumber);redisOperator.set("chunkNumberList_"+identifier, JSON.toJSONString(newChunkNumber),36000);//解锁redisLock.unlock(identifier,threadUUID);return newChunkNumber.size();//如果分块集合已经存在了,就添加一个编号} else {oldChunkNumber.add(chunkNumber);redisOperator.set("chunkNumberList_"+identifier, JSON.toJSONString(oldChunkNumber),36000);//解锁redisLock.unlock(identifier,threadUUID);return oldChunkNumber.size();}}

代码中使用的共享资源标识是文件唯一编号identifier,它能标识加锁代码段中的唯一资源,即key为"chunkNumberList_"+identifier的集合

代码中使用的线程唯一标识是UUID,能保证加锁和解锁时获取的标识不会重复

Java 的抽象类是什么

java之数据格式化

javaweb内容js\java中json的使用

java技术事务的传播行为

Java 数据结构都有哪些

标签: #js多线程锁