为什么要用分布式锁？在讨论这个问题之前，我们先来看一个业务场景：A系统是一个电商系统，目前部署在一台机器上。系统中有用户下单的接口，但用户在下单前必须查看库存。,确保库存充足后再为用户下单。由于系统有一定的并发性，商品的库存会提前保存在redis中，用户下单时会更新redis的库存。此时系统架构如下：但这会造成一个问题：如果在某个时刻，redis中的某个商品库存为1，此时两个请求同时过来，其中一个请求执行到上图中的第3步，Updatingtheinventoryofthedatabaseto0，但是第4步还没有执行。而另一个请求执行到第2步，发现库存还是1，继续执行第3步，结果卖出了2件，但实际上库存只有1件。显然错了！这是一个典型的库存超卖问题。这时候我们很容易想到一个解决办法：把步骤2、3、4用锁锁住，执行完后让另外一个线程进来执行步骤2。根据上图，在执行步骤2时，使用Java提供的synchronized或者ReentrantLock进行加锁，执行完步骤4后再释放锁。这样，2、3、4这三个步骤就被“锁定”了，多个线程只能串行执行。但是好景不长，整个系统的并发量飙升，一台机器都搞不定了。现在添加一台机器，如下图：添加机器后，系统变成如上图，天啊！假设两个用户的请求同时到达，但是落在了不同的机器上，这两个请求是不是可以同时执行，或者会不会出现库存超卖的问题。为什么？因为上图中的两个A系统运行在两个不同的JVM中，所以它们加的锁只对自己JVM中的线程有效，对其他JVM的线程无效。所以，这里的问题是：Java提供的原生锁机制在多机部署场景下失效了。这是因为两台机器加的锁不是同一把锁（两把锁在不同的JVM）。那么，只要保证两台机器加的锁是同一把锁，问题不就解决了吗？至此，分布式锁就该隆重登场了。分布式锁的思想是在整个系统中提供一个全局唯一的“东西”去获取锁，然后每个系统在需要加锁的时候都会去问这个“东西”。“物”获得一把锁，这样不同的系统就可以认为是同一把锁。至于这个“东西”，可以是Redis，也可以是Zookeeper，也可以是数据库。文字描述不是很直观，我们看下图：通过上面的分析，我们知道在分布式部署系统的情况下，使用Java原生的锁机制是不能保证线程安全的，所以需要使用分布式锁方案.那么，如何实现分布式锁呢？然后往下看！以上基于基于Redis的分布式锁的实现，分析了为什么要使用分布式锁。这里我们就具体看看分布式锁在实现的时候应该如何处理。延伸：Redisson是如何实现分布式锁的？最常见的解决方案是使用Redis作为分布式锁。使用Redis作为分布式锁的思路大概是这样的：在redis中设置一个值表示已经加了锁，然后在释放锁的时候删除key。具体代码如下：//获取锁//NX表示key不存在则成功，key存在则返回false。说明，这两条指令不是原子的//需要使用redis的lua脚本支持特性，redis执行lua脚本是原子的ifredis.call("get",KEYS[1])==ARGV[1]thenreturnredis.call("del",KEYS[1])elsereturn0end这个方法有几个关键点：一定要使用SET键值NXPX毫秒命令。如果没有，先设置值，再设置过期时间。这不是一个原子操作，有可能在设置过期时间之前崩溃，导致死锁（key永久存在）。该值必须是唯一的。这是因为在解锁的时候，在删除key之前需要验证value和被锁的key是否一致。这是为了避免一种情况：假设A获得了锁，过期时间为30s。此时35s后，锁已经自动释放，A去释放锁，但是此时B可能获取到了锁。客户端A无法删除B的锁。除了考虑客户端如何实现分布式锁，还需要考虑redis的部署。Redis有三种部署方式：单机模式主从+哨兵选举模式redis集群模式使用redis作为分布式锁。缺点是如果使用单机部署方式，会出现单点问题，只要redis失效。锁定将不起作用。使用主从模式，加锁时只有一个节点被加锁。即使通过Sentinel做高可用，如果master节点出现故障，发生主从切换，此时也可能出现锁丢失的问题。基于以上考虑，其实redis的作者也考虑过这个问题。他提出了一个RedLock算法。这个算法的意思大概是这样的：假设redis的部署方式是rediscluster，一共有5个master节点。通过以下步骤获取锁：获取当前时间戳，单位毫秒。尝试依次在每个主节点上创建锁。过期时间设置的比较短。一般在大多数节点上尝试加锁需要几十毫秒，比如5个节点。它需要3个节点(n/2+1)。客户端计算建立锁的时间。如果建立锁的时间小于超时时间，即使建立成功。如果加锁失败，只要有别人加锁，则依次删除锁。一旦获取了分布式锁，就必须不断轮询来尝试获取锁，但是这样的算法还是比较有争议的，可能还会有很多问题，并且不能保证加锁过程一定是正确的。另一种方式：Redisson另外要实现Redis的分布式锁，除了基于redis客户端的原生API实现之外，还可以使用一个开源的框架：RedissionRedisson是一个企业级开源的RedisClient，它还提供了分布式锁。支持。我也非常推荐大家使用，为什么呢？回想一下我上面说的，如果你自己写代码通过redis设置一个值，是通过下面的命令来设置的。SETanyLockunique_valueNXPX30000这里设置的超时时间为30s。如果我超过30s还没有完成业务逻辑，key就会过期，其他线程可能会获取到锁。这样一来，第一个线程还没有执行完业务逻辑，第二个线程进来的时候也会出现线程安全问题。所以还是要维护这个过期时间，太麻烦了~来看看redisson是怎么实现的吧？先感受下使用redission的爽快：Configconfig=newConfig();config.useClusterServers().addNodeAddress("redis://192.168.31.101:7001").addNodeAddress("redis://192.168.31.101:7002")。addNodeAddress("redis://192.168.31.101:7003").addNodeAddress("redis://192.168.31.102:7001").addNodeAddress("redis://192.168.31.102:7002").addNodeAddress("redis://192.168.31.102:7003");RedissonClientredisson=Redisson.create(config);RLocklock=redisson.getLock("anyLock");lock.lock();lock.unlock();就这么简单，我们只需要通过其api中的lock和unlock即可完成分布式锁。他帮我们考虑了很多细节：redisson的所有指令都是通过lua脚本执行的，redis支持lua脚本的原子执行。Redisson设置一个key的默认过期时间是30s，客户端持有锁超过30s怎么办？redisson中有一个watchdog的概念，翻译过来就是watchdog。获取锁后，它会帮你设置密钥的超时时间为每10秒30秒。在这种情况下，即使你一直拿着锁，钥匙也不会出现。它已经过期，其他线程已经获得了锁。Redisson的“看门狗”逻辑确保不会发生死锁。（如果机器宕机，看门狗也会宕机。此时key的过期时间不会延长，30s后会自动过期，其他线程可以获取锁）下面是一点实现代码：//加锁逻辑privateRFuturetryAcquireAsync(longleaseTime,TimeUnitunit,finallongthreadId){if(leaseTime!=-1){returntryLockInnerAsync(leaseTime,unit,threadId,RedisCommands.EVAL_LONG);}//调用lua脚本，设置一些key，过期时间RFuturettlRemainingFuture=tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),TimeUnit.MILLISECONDS,threadId,RedisCommands.EVAL_LONG);ttlRemainingFuture.addListener(newFutureListener(){@OverridepublicvoidoperationComplete(未来未来)throwsException{if(!future.isSuccess()){return;}LongttlRemaining=future.getNow();//lockacquiredif(ttlRemaining==null){//看门狗逻辑scheduleExpirationRenewal(threadId);}}});returnttlRemainingFuture;}RFuturetryLockInnerAsync(longleaseTime,TimeUnitunit,longthreadId,RedisStrictCommand命令){internalLockLeaseTime=unit.toMillis(leaseTime);returncommandExecutor.evalWriteAsync(getName(),LongCodec.INSTANCE,command,"if(redis.call('exists',KEYS[1])==0)then"+"redis.call('hset',KEYS[1],ARGV[2],1);"+"redis.call('pexpire',KEYS[1],ARGV[1]);"+"returnnil;"+"end;"+"if(redis.call('hexists',KEYS[1],ARGV[2])==1)then"+"redis.call('hincrby',KEYS[1],ARGV[2],1);"+"redis.call('pexpire',KEYS[1],ARGV[1]);"+"returnnil;"+"end;"+"returnredis.call('pttl',KEYS[1]);",Collections.
