这篇文章将为大家详细讲解有关Redis分布式锁如何实现，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。

线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。

进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。

分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

现在的业务场景越来越复杂，使用的架构也就越来越复杂，分布式、高并发已经是业务要求的常态。像腾讯系的不少服务，还有CDN优化、异地多备份等处理。

说到分布式，就必然涉及到分布式锁的概念，如何保证不同机器不同线程的分布式锁同步呢？

互斥性，同一时刻，智能有一个客户端持有锁。

防止死锁发生，如果持有锁的客户端崩溃没有主动释放锁，也要保证锁可以正常释放及其他客户端可以正常加锁。

加锁和释放锁必须是同一个客户端。

容错性，只有redis还有节点存活，就可以进行正常的加锁解锁操作。

错误方式一

保证互斥和防止死锁，首先想到的使用redis的setnx命令保证互斥，为了防止死锁，锁需要设置一个超时时间。

publicstaticvoidwrongLock(Jedisjedis,Stringkey,StringuniqueId,intexpireTime){Longresult=jedis.setnx(key,uniqueId);if(1==result){//如果该redis实例崩溃，那就无法设置过期时间了jedis.expire(key,expireTime);}}

在多线程并发环境下，任何非原子性的操作，都可能导致问题。这段代码中，如果设置过期时间时，redis实例崩溃，就无法设置过期时间。如果客户端没有正确的释放锁，那么该锁(永远不会过期)，就永远不会被释放。

错误方式二

比较容易想到的就是设置值和超时时间为原子原子操作就可以解决问题。那使用setnx命令，将value设置为过期时间不就ok了吗？

publicstaticbooleanwrongLock(Jedisjedis,Stringkey,intexpireTime){longexpireTs=System.currentTimeMillis()+expireTime;//锁不存在，当前线程加锁成果if(jedis.setnx(key,String.valueOf(expireTs))==1){returntrue;}Stringvalue=jedis.get(key);//如果当前锁存在,且锁已过期if(value!=null&&NumberUtils.toLong(value)<System.currentTimeMillis()){//锁过期，设置新的过期时间StringoldValue=jedis.getSet(key,String.valueOf(expireTs));if(oldValue!=null&&oldValue.equals(value)){//多线程并发下，只有一个线程会设置成功//设置成功的这个线程，key的旧值一定和设置之前的key的值一致returntrue;}}//其他情况，加锁失败returntrue;}

乍看之下，没有什么问题。但仔细分析，有如下问题：

value设置为过期时间，就要求各个客户端严格的时钟同步，这就需要使用到同步时钟。即使有同步时钟，分布式的服务器一般来说时间肯定是存在少许误差的。

锁过期时，使用 jedis.getSet虽然可以保证只有一个线程设置成功，但是不能保证加锁和解锁为同一个客户端，因为没有标志锁是哪个客户端设置的嘛。

解锁错误方式一

直接删除key

publicstaticvoidwrongReleaseLock(Jedisjedis,Stringkey){//不是自己加锁的key，也会被释放jedis.del(key);}

简单粗暴，直接解锁，但是不是自己加锁的，也会被删除，这好像有点太随意了吧！

解锁错误方式二

判断自己是不是锁的持有者，如果是，则只有持有者才可以释放锁。

publicstaticvoidwrongReleaseLock(Jedisjedis,Stringkey,StringuniqueId){if(uniqueId.equals(jedis.get(key))){//如果这时锁过期自动释放，又被其他线程加锁，该线程就会释放不属于自己的锁jedis.del(key);}}

看起来很完美啊，但是如果你判断的时候锁是自己持有的，这时锁超时自动释放了。然后又被其他客户端重新上锁，然后当前线程执行到jedis.del(key)，这样这个线程不就删除了其他线程上的锁嘛，好像有点乱套了哦！

基本上避免了以上几种错误方式之外，就是正确的方式了。要满足以下几个条件：

命令必须保证互斥

设置的key必须要有过期时间，防止崩溃时锁无法释放

value使用唯一id标志每个客户端，保证只有锁的持有者才可以释放锁

加锁直接使用set命令同时设置唯一id和过期时间；其中解锁稍微复杂些，加锁之后可以返回唯一id，标志此锁是该客户端锁拥有；释放锁时要先判断拥有者是否是自己，然后删除，这个需要redis的lua脚本保证两个命令的原子性执行。

下面是具体的加锁和释放锁的代码：

@Slf4jpublicclassRedisDistributedLock{privatestaticfinalStringLOCK_SUCCESS="OK";privatestaticfinalLongRELEASE_SUCCESS=1L;privatestaticfinalStringSET_IF_NOT_EXIST="NX";privatestaticfinalStringSET_WITH_EXPIRE_TIME="PX";//锁的超时时间privatestaticintEXPIRE_TIME=5*1000;//锁等待时间privatestaticintWAIT_TIME=1*1000;privateJedisjedis;privateStringkey;publicRedisDistributedLock(Jedisjedis,Stringkey){this.jedis=jedis;this.key=key;}//不断尝试加锁publicStringlock(){try{//超过等待时间，加锁失败longwaitEnd=System.currentTimeMillis()+WAIT_TIME;Stringvalue=UUID.randomUUID().toString();while(System.currentTimeMillis()<waitEnd){Stringresult=jedis.set(key,value,SET_IF_NOT_EXIST,SET_WITH_EXPIRE_TIME,EXPIRE_TIME);if(LOCK_SUCCESS.equals(result)){returnvalue;}try{Thread.sleep(10);}catch(InterruptedExceptione){Thread.currentThread().interrupt();}}}catch(Exceptionex){log.error("lockerror",ex);}returnnull;}publicbooleanrelease(Stringvalue){if(value==null){returnfalse;}//判断key存在并且删除key必须是一个原子操作//且谁拥有锁，谁释放Stringscript="ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])elsereturn0end";Objectresult=newObject();try{result=jedis.eval(script,Collections.singletonList(key),Collections.singletonList(value));if(RELEASE_SUCCESS.equals(result)){log.info("releaselocksuccess,value:{}",value);returntrue;}}catch(Exceptione){log.error("releaselockerror",e);}finally{if(jedis!=null){jedis.close();}}log.info("releaselockfailed,value:{},result:{}",value,result);returnfalse;}}

关于“Redis分布式锁如何实现”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。