深度探析Java分布式锁

3.1分布式锁简介

锁是一种用来解决多个执行线程访问共享资源错误或数据不一致问题的工具。

如果把一台服务器比作一个房子, 那么线程就好比里面的住户，当他们想要共同访问- -个共享资源，例如厕所的时候，如果厕所门上没有锁...更甚者厕所没装门..这是会出原则性的问题的装上了锁，大家用起来就安心多了，本质也就是同一时间只允许一个住户使用。

而随着互联网世界的发展，单体应用已经越来越无法满足复杂互联网的高并发需求，转而慢慢朝着分布式方向发展，慢慢进化成了更大一些的住户。 所以同样,我们需要引入分布式锁来解决分布式应用之间访问共享资源的并发问题。

为何需要分布式锁

一般情况下，我们使用分布式锁主要有两个场景:

1.避免不同节点重复相同的工作:比如用户执行了某个操作有可能不同节点会发送多封邮件;

2.避免破坏数据的正确性:如果两个节点在同-条数据上同时进行操作，可能会造成数据错误或不一致的情况出现;

Java中实现的常见方式

上面我们用简单的比喻说明了锁的本质:同- -时间只允许一个用户操作。 所以理论上,能够满足这个需求的工具我们都能够使用(就是其他应用能帮我们加锁的:

1.基于MySQL中的锁: MySQL 本身有自带的悲观锁for update 关键字，也可以自己实现悲观/乐观锁来达到目的;

2.基于Zookeeper有序节点: Zookeeper 允许临时创建有序的子节点，这样客户端获取节点列表时，就能够当前子节点列表中的序号判断是否能够获得锁;

3.基于Redis的单线程:由于Redis是单线程，所以命令会以串行的方式执行，并且本身提供了像SETNX(set if not exists) 这样的指令，本身具有互斥性;

每个方案都有各自的优缺点，例如MySQL虽然直观理解容易，但是实现起来却需要额外考虑锁超时、加事务等,并且性能局限于数据库，诸如此类我们在此不作讨论，重点关注Redis.

Redis分布式锁的问题

①.锁超时

假设现在我们有两台平行的服务AB,其中A服务在获取锁之后由于未知神秘力量突然挂了，那么B服务就永远无法获取到锁了:

 

所以我们需要额外设置一个超时时间，来保证服务的可用性。

但是另一个问题随即而来:如果在加锁和释放锁之间的逻辑执行得太长，以至于超出了锁的超时限制，

也会出现问题。因为这时候第-个线程持有锁过期了，而临界区的逻辑还没有执行完，与此同时第二个线程就提前拥有了这把锁，导致临界区的代码不能得到严格的串行执行。

为了避免这个问题，Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了问题,造成的数据小错乱可能就需要人工的干预。

有一个稍微安全一点的方案是 将锁的value值设置为-一个随机数，释放锁时先匹配随机数是否- -致,然后再删除key,这是为了确保当前线程占有的锁不会被其他线程释放，除非这个锁是因为过期了而被服务器自动释放的。

但是匹配value和删除key在Redis中并不是-个原子性的操作,也没有类似保证原子性的指令，所以可能需要使用像Lua这样的脚本来处理了，因为Lua脚本可以保证多个指令的原子性执行。延伸的讨论: GC可能引发的安全问题

Martin Kleppmann曾与Redis之父Antirez就Redis实现分布式锁的安全性问题进行过深入的讨论,其中有一个问题就涉及到GC.

熟悉Java的同学肯定对GC不陌生，在GC的时候会发生STW(Stop-The-World),这本身是为了保障垃圾回收器的正常执行，但可能会引发如下的问题:

 

服务A获取了锁并设置了超时时间，但是服务A出现了STW且时间较长，导致了分布式锁进行了超时释放，在这个期间服务B获取到了锁，待服务ASTW结束之后又恢复了锁，这就导致了服务A和服务B同时获取到了锁，这个时候分布式锁就不安全了。

不仅仅局限于Redis, Zookeeper 和MySQL有同样的问题。

②、单点/多点问题

如果Redis采用单机部署模式，那就意味着当Redis故障了，就会导致整个服务不可用。

而如果采用主从模式部署，我们想象一个这样的场景: 服务A申请到一把锁之后，如果作为主机的Redis宕机了，那么服务B在申请锁的时候就会从从机那里获取到这把锁，为了解决这个问题，Redis作者提出了一种RedLock红锁的算法(Redission同]edis):