redis 解决并发 java
1、为什么要使用分布式锁
如果在一个分布式系统中,我们从数据库中读取一个数据,然后修改保存,这种情况很容易遇到并发问题。因为读取和更新保存不是一个原子操作,在并发时就会导致数据的不正确。这种场景其实并不少见,比如电商秒杀活动,库存数量的更新就会遇到。如果是单机应用,直接使用本地锁就可以避免。如果是分布式应用,本地锁派不上用场,这时就需要引入分布式锁来解决。
由此可见分布式锁的目的其实很简单,就是为了保证多台服务器在执行某一段代码时保证只有一台服务器执行。
2、为了保证分布式锁的可用性,至少要确保锁的实现要同时满足以下几点:
互斥性。在任何时刻,保证只有一个客户端持有锁。
不能出现死锁。如果在一个客户端持有锁的期间,这个客户端崩溃了,也要保证后续的其他客户端可以上锁。
保证上锁和解锁都是同一个客户端。
3、一般来说,实现分布式锁的方式有以下几种:
使用MySQL,基于唯一索引。
使用ZooKeeper,基于临时有序节点。
使用Redis,基于set命令(2.6.12 版本开始)。
本篇文章主要讲解Redis的实现方式。
4、用到的redis命令
锁的实现主要基于redis的SET命令(SET详细解释参考这里),我们来看SET的解释:
SET key value [EX seconds] [PX milliseconds] [NX|XX]
将字符串值 value 关联到 key 。
如果 key 已经持有其他值, SET 就覆写旧值,无视类型。
对于某个原本带有生存时间(TTL)的键来说, 当 SET 命令成功在这个键上执行时, 这个键原有的 TTL 将被清除。
可选参数
从 Redis 2.6.12 版本开始, SET 命令的行为可以通过一系列参数来修改:
EX second :设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
PX millisecond :设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
NX :只在键不存在时,才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
XX :只在键已经存在时,才对键进行设置操作。
加锁:使用SET key value [PX milliseconds] [NX]命令,如果key不存在,设置value,并设置过期时间(加锁成功)。如果已经存在lock(也就是有客户端持有锁了),则设置失败(加锁失败)。
解锁:使用del命令,通过删除键值释放锁。释放锁之后,其他客户端可以通过set命令进行加锁。
5、上面第二项,说了分布式锁,要考虑的问题,下面讲解一下
5.1、互斥性。在任何时刻,保证只有一个客户端持有锁
redis命令是原子性的,只要客户端调用redis的命令SET key value [PX milliseconds] [NX] 执行成功,就算加锁成功了
5.2、不能出现死锁。如果在一个客户端持有锁的期间,这个客户端崩溃了,也要保证后续的其他客户端可以上锁。
set命令px设置了过期时间,key过期失效了,就能避免死锁了
5.3保证上锁和解锁都是同一个客户端。
释放锁(删除key)的时候,只要确保是当前客户端设置的value才去删除key即可,采用lua脚本来实现
在Redis中,执行Lua语言是原子性,也就是说Redis执行Lua的时候是不会被中断的,具备原子性,这个特性有助于Redis对并发数据一致性的支持。
6、java代码实现
先把需要的jar包引入
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.9.3</version> </dependency>
加锁设置参数的实体类
import lombok.Data;//加锁设置的参数
redis分布式具体代码实现
import lombok.extern.slf4j.Slf4j;import redis.clients.jedis.Jedis;import java.util.Collections;import java.util.UUID;/**
* redis分布式锁
*/
redis分布式锁使用
import lombok.extern.slf4j.Slf4j;
这是代码在执行过程中,通过redis可视化工具看到的效果,可以参考一下~

控制台日志打印结果
15:02:28.569 [main] INFO com.test.test - 下面测试两个线程同时,抢占锁的结果15:02:28.645 [我是线程2] INFO com.test.test - 加锁结果:true15:02:30.618 [我是线程1] INFO com.test.test - 加锁结果:false15:02:30.620 [我是线程1] INFO com.test.test - 释放锁结果:false15:02:33.652 [我是线程2] INFO com.test.test - 释放锁结果:true15:02:48.614 [main] INFO com.test.test - -----------------我是一条分割线----------------15:02:48.614 [main] INFO com.test.test -
15:02:48.614 [main] INFO com.test.test -
15:02:48.614 [main] INFO com.test.test -
15:02:48.614 [main] INFO com.test.test - 下面是测试 一个线程获取锁成功后,由于业务执行时间超过了设置持有锁的时间,是否会把其他线程持有的锁给释放掉15:02:48.616 [我是线程3] INFO com.test.test - 加锁结果:true15:02:50.645 [我是线程4] INFO com.test.test - 加锁结果:true15:02:55.647 [我是线程4] INFO com.test.test - 释放锁结果:true15:02:58.621 [我是线程3] INFO com.test.test - 释放锁结果:false
可以看到多个线程竞争一把锁的时候,保证了只有一个线程持有锁
分割线下面的日志也能看出,一个线程持有了锁,由于处理业务代码时间,超过了设置持有锁的时间,通过lua脚本释放锁的时候,也不会把其他线程持有的锁给释放掉,保证了安全释放了锁
7、分布式锁 实际使用中需要注意的一些问题
假设有这样一个场景: 有一个修改订单状态的接口,订单状态修改为失败,就不允许在修改为其他状态了;
在单台机器上,在代码方法上加了synchronized来做并发控制,由于代码逻辑比较复杂,现在它的TPS是1,一秒就只能处理一个订单。
后面对这个系统做集群,部署了一百台,那么这个接口性能就提升了100倍了。
但是synchronized是进程级别的锁,在集群环境下synchronized没办法控制其他服务器下线程并发访问 临界代码了,后面就采用了分布式锁来做并发控制。
7.1、那么使用分布锁要注意什么了?
7.1.1、锁粒度
如果分布式锁的key 设置的是 redisLock:updateOrderStatus 相当于集群下对这个接口加了相同的一把大锁,按照上面那个场景TPS就变成1了,集群部署就浪费了。
7.1.2、那么如何控制锁粒度了?
平常我们修改订单的时候都有订单号,那么分布式的key可以设置为:redisLock:updateOrderStatus:{orderCode} ,{orderCode}执行的时候动态的替换成订单编号,那么锁粒度就控制到这条订单了,就跟数据库从表锁 变成了行锁一样,接口支持更高的并发了。
7.1.3、获取锁时间
如果时间设置的太长:用户就会等待太久才能得到响应结果
太短:频繁获取锁失败,用户体验性也不好
只能按照不同的业务代码,由开发人员来衡量设置多长的时间
7.1.4、持有锁时间:
如果锁粒度比较小,时间可以设置长一点,就算执行比较慢,影响面比较小可以接受
7.1.5、难道每次想使用分布式锁的时候都需要下面流程一样,在编码一次?有什么办法能优化吗?
1、先创建一个 分布式锁对象;RedisLock redisLock = new RedisLock(lockParam);
2、加锁;Boolean lockFlag = redisLock.lock();
3、finally 解锁;redisLock.unlock();
链接:https://www.dianjilingqu.com/628686.html