JAVA分布式锁实现
1、背景
目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。
2、要求
排他性：在同一时间只会有一个客户端能获取到锁，其它客户端无法同时获取
避免死锁：这把锁在一段有限的时间之后，一定会被释放（正常释放或异常释放）
高可用：获取或释放锁的机制必须高可用且性能佳
3、实现方式：三种
3.1 基于数据库实现：数据库的乐观锁和悲观锁
3.1.1 乐观锁机制：在数据库表中引入一个版本号（version）字段来实现的。
当从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加 1，同时将新的数据与新的version更新到数据表中，且必须在更新的时候同时检查目前数据库里version值是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。
满足条件：
服务要有递增的版本号version；
每次更新数据的时候都必须先判断版本号对不对，然后再写入新的版本号
3.1.2 悲观锁机制：也叫作排它锁，在Mysql中是基于 for update 来实现加锁的
上面的示例中，user表中，id是主键，通过 for update 操作，数据库在查询的时候就会给这条记录加上排它锁，其它线程是无法操作这条记录的。
注：在InnoDB中只有字段加了索引的，才会是行级锁，否者是表级锁，所以这个id字段要加索引。
优点：直接借助数据库，操作简单。
缺点：操作数据库需要一定的开销，性能问题需要考虑，数据库的行级锁并不一定靠谱。
3.2 基于Redis实现：依赖redis自身的原子操作
SET user_key user_value NX PX 100
user_key：使用key来做锁，值唯一
user_value： UUID方法生成，确定唯一客户端操作，确保加锁和解锁使用同一客户端操作的，存货100ms
NX： 只在在key不存在时，才对key进行设置操作，SET key value NX 效果等同于 SETNX key value
PX：设置key的过期时间为millisecond毫秒，当超过这个时间后，设置的键会自动失效
为什么上面代码中命令可以帮我们实现锁机制呢：
这个命令是只有在某个key不存在的时候，才会执行成功。那么当多个进程同时并发的去设置同一个key的时候，就永远只会有一个进程成功。
当某个进程设置成功之后，就可以去执行业务逻辑了，等业务逻辑执行完毕之后，再去进行解锁。
解锁很简单，只需要删除这个key就可以了，不过删除之前需要判断，这个key对应的value是当初自己设置的那个。
另外，针对redis集群模式的分布式锁，可以采用redis的Redlock机制。
优点：性能好，实现起来较为方便。
缺点：失效时间（失效时间设置多长时间为好？如何设置的失效时间太短，方法没等执行完，锁就自动释放了，那么就会产生并发问题。如果设置的时间太长，其他获取锁的线程就可能要平白的多等一段时间）
3.3 基于ZooKeeper实现：用它的临时有序节点来实现的分布式锁
ZK：一般由多个节点构成（单数），采用 zab 一致性协议。因此可以将 zk 看成一个单点结构，对其修改数据其内部自动将所有节点数据进行修改而后才提供查询服务
zk 的数据以目录树的形式，每个目录称为 znode， znode 中可存储数据（一般不超过 1M），还可以在其中增加子节点。
子节点有三种类型。序列化节点，每在该节点下增加一个节点自动给该节点的名称上自增。临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除。最后就是普通节点。
Watch 机制，client 可以监控每个节点的变化，当产生变化会给 client 产生一个事件。
原理：当客户端要进行逻辑的加锁时，就在zookeeper上的某个指定节点的目录下，去生成一个唯一的临时有序节点， 然后判断自己是否是这些有序节点中序号最小的一个，是，则获取了锁。不是，则没有获取到锁，就要在序列中找到比自己小的那个节点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是，则获取锁，如果不是，则重复上述步骤。
如图上，locker是一个持久节点，node_1/node_2/…/node_n 就是上面说的临时节点，由客户端client去创建的。
client_1/client_2/…/clien_n 都是想去获取锁的客户端。以client_1为例，它想去获取分布式锁，则需要跑到locker下面去创建临时节点（假如是node_1）创建完毕后，看一下自己的节点序号是否是locker下面最小的，如果是，则获取了锁。如果不是，则去找到比自己小的那个节点（假如是node_2），找到后，就监听node_2，直到node_2被删除，那么就开始再次判断自己的node_1是不是序列中最小的，如果是，则获取锁，如果还不是，则继续找一下一个节点
Zookeeper解决前面问题：
锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁
非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
优点：有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。
缺点：性能上不如使用缓存实现分布式锁，动态创建、销毁临时节点来实现锁功能。