大牛举例教你如何用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

Long lock= jedis.setnx(key,value); 
if(lock>0){ 
//执行业务逻辑 
} 
复制代码

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

致使死锁发生。为了不这种状况，请看下面的代码

错误例子2

Long lock= jedis.setnx(key,value); 
if(lock>0){ 
 jedis.expire(key,expireTime); 
} 
复制代码

和上面的例子相似，惟一不一样的是这里多了一步设置key过时时间的操做。若是在del的时候系统宕机，等过时时间一到，Redis会删除这个key。

其余线程能够再次获取锁。这样就能够万无一失了吗?这里有一个问题，若是在第一步setnx成功后，忽然网络闪断，expire命令执行失败，一样也有死锁的风险。这两步并不具有原子性，不保证所有成功或所有失败。

顺便给你们推荐一个Java技术交流群： 710373545里面会分享一些资深架构师录制的视频资料：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多！

正确的构建方式

public static boolean getDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) { 
 String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime); 
 if (LOCK_SUCCESS.equals(result)) { 
return true; 
 } 
return false; 
} 
复制代码

参数解释：

key：键

value：值

nx：若是当前key存在，则set失败，不然成功

ex：设置key的过时时间

expireTime：key的过时时间，时间到了，Redis会自动删除key和value。

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

解锁方式：

错误例子1：

jedis.del(key); 
复制代码

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

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

错误例子2：

if(value==jedis.get(key)){ 
 jedis.del(key); 
} 
复制代码

咱们在加锁的时候，能够将value设置成惟一标识当前线程的一个值，这个值能够是一个UUID，当释放锁的时间，判断value是否和set时的值相同，若是相同，则说明加锁和释放锁是同一个线程，容许释放。不然释放锁失败。

这样就能够绝对安全了吗??答案固然是否认的。这步操做，一样不具有原子性。若是ThreadA在执行value==jedis.get(key)返回true后的瞬间，del命令还没来的及执行，key过时了，而此时ThreadB获取到锁，以后ThreadA执行del命令，把ThreadB的锁释放掉了。

因此要保证两部操做的原子性，咱们不得不利用简单的Lua脚本。

正确的解锁姿式：

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

Redis在2.6后内部内嵌Lua脚本解释器，因此咱们能够经过简单的Lua脚原本保证上述操做的原子性。代码中的Lua脚本的的意思是：咱们把LockKey赋值给KEYS[1]，把RequestId赋值给ARGV[1]，若是key中的值等于RequestId，返回true不然返回false。这样就保证了释放锁操做时原子的，而且当前客户端只会释放当前客户端的锁。

原文连接：http://stor.51cto.com/art/201906/597813.htm?utm_source=tuicool&utm_medium=referral