|
|
51CTO旗下网站
|
|
移动端

用Redis构建一把高性能的锁

学过JAVA多线程的朋友都知道,为了防止多个线程同时执行同一段代码,可以用synchronized关键字或JAVA API中ReentrantLock类来控制。

作者:刘莅来源:OutOfMemoryErro|2019-06-12 15:20

【大咖·来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

背景:

笔者所在的公司,上周末经历了一场大促活动后,系统暴露出这样一个问题:分布式锁使用的zk锁,由于当天大促用户量比较多,系统疯狂的加锁释放锁,***zk承受不住这么大的压力宕机。由于马上就要618,为了避免再次发生这样的事情,公司决定把所有系统的zk锁都替换为高性能的Redis锁。

在这里简单的提一下,zk锁性能比redis低的原因:zk中的角色分为leader,flower,每次写请求只能请求leader,leader会把写请求广播到所有flower,如果flower都成功才会提交给leader,其实这里相当于一个2PC的过程。在加锁的时候是一个写请求,当写请求很多时,zk会有很大的压力,***导致服务器响应很慢。

正题:

什么情况下需要加锁?

当多个线程、用户同时竞争同一个资源时,需要加锁。比如,下订单减库存,抢票,选课,抢红包等。如果在此处没有锁的控制,会导致很严重的问题,下订单减库存的时候不加锁,会导致商品超卖;抢票的时候不加锁,会导致两个人抢到同一个位置;选课的时候没有锁的控制,导致选课成功的人数大于教室的座位数;抢红包时没有锁的控制,抢到红包的金额大于红包的实际金额。

什么是分布式锁?

学过JAVA多线程的朋友都知道,为了防止多个线程同时执行同一段代码,可以用synchronized关键字或JAVA API中ReentrantLock类来控制。

但是目前几乎任何一个系统都往往部署多台机器的,单机部署的应用很少,synchronized和ReentrantLock发挥不出任何作用,此时就需要一把全局的锁,来代替JAVA中的synchronized和ReentrantLock。

当Thread1线程获取到锁,执行锁中的代码,其他线程或其他机器再次请求该锁,发现锁被Thread1占用,加锁失败。当Thread1释放锁,其他线程则可以获取到锁并执行相应的操作。

我们可以用Jedis中是setnx命令来构建这把锁,首先,我列举一些错误的构建锁的方式:

错误例子1

  1. Long lock= jedis.setnx(key,value); 
  2. if(lock>0){ 
  3. //执行业务逻辑 

通过setnx命令创建一个key、value,如果key不存在,则加锁成功。这样做有什么问题呢?如果执行加锁操作成功,在释放锁的时候,系统宕机,导致这个key永远不会被del掉,也就是说其他线程一直获取不到锁,

导致死锁发生。为了避免这种情况,请看下面的代码

错误例子2

  1. Long lock= jedis.setnx(key,value); 
  2. if(lock>0){ 
  3.    jedis.expire(key,expireTime); 

和上面的例子类似,唯一不同的是这里多了一步设置key过期时间的操作。如果在del的时候系统宕机,等过期时间一到,Redis会删除这个key。

其他线程可以再次获取锁。这样就可以万无一失了吗?这里有一个问题,如果在***步setnx成功后,突然网络闪断,expire命令执行失败,同样也有死锁的风险。这两步并不具备原子性,不保证全部成功或全部失败。

正确的构建方式

  1. public static boolean getDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) { 
  2.     String result = jedis.set(lockKey, requestId, "NX""EX", expireTime); 
  3.     if (LOCK_SUCCESS.equals(result)) { 
  4. return true
  5.      } 
  6. return false

参数解释:

key:键

value:值

nx:如果当前key存在,则set失败,否则成功

ex:设置key的过期时间

expireTime:key的过期时间,时间到了,Redis会自动删除key和value。

这个命令,将上面的错误例子2中的两个操作合为一个原子操作,保证了同时成功或同时失败。

解锁方式:

错误例子1:

  1. jedis.del(key); 

执行这个操作的线程,不去判断锁的拥有者就删除锁。

还记的set命令可以设置value吗?在获取锁的操作时,主要是判断key是否存在,那么value有什么用呢??如果在删除锁的时候,不去判断当前锁的拥有者,任何线程都可以释放锁。这个时候,value值就起到作用了。

错误例子2:

  1. if(value==jedis.get(key)){ 
  2.     jedis.del(key); 

我们在加锁的时候,可以将value设置成唯一标识当前线程的一个值,这个值可以是一个UUID,当释放锁的时间,判断value是否和set时的值相同,如果相同,则说明加锁和释放锁是同一个线程,允许释放。否则释放锁失败。

这样就可以绝对安全了吗??答案当然是否定的。这步操作,同样不具备原子性。如果ThreadA在执行value==jedis.get(key)返回true后的瞬间,del命令还没来的及执行,key过期了,而此时ThreadB获取到锁,之后ThreadA执行del命令,把ThreadB的锁释放掉了。

所以要保证两部操作的原子性,我们不得不利用简单的Lua脚本。

正确的解锁姿势:

  1. public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) { 
  2. String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"
  3.     Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId)); 
  4.     if (RELEASE_SUCCESS.equals(result)) { 
  5.         return true
  6.     } 
  7.     return false

Redis在2.6后内部内嵌Lua脚本解释器,所以我们可以通过简单的Lua脚本来保证上述操作的原子性。代码中的Lua脚本的的意思是:我们把LockKey赋值给KEYS[1],把RequestId赋值给ARGV[1],如果key中的值等于RequestId,返回true否则返回false。这样就保证了释放锁操作时原子的,并且当前客户端只会释放当前客户端的锁。

【编辑推荐】

  1. 有效避免数据丢失!Redis持久化方案选择详解
  2. Redis高可用原理,这下能看懂了吧!
  3. 详解Redis的持久化机制--RDB和AOF
  4. 搭建高可用的Redis服务,需要注意这些方面!
  5. 一般哪些数据需要Redis缓存
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

111人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

755人订阅学习

读 书 +更多

Scrum敏捷项目管理

本书详细描述如何在复杂技术项目中使用Scrum,并结合真实的Scrum案例及专家洞识,在简明及高度概括的理论之上更侧重于实践,并不断强调Scru...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微