详述分布式锁实现的方法与方案论证!

　　概述:

　　我们在实际的接口或者业务开发中，不管是服务器单点还是服务器集群，都会有分布式锁的使用场景。 比如最常见的接口重复提交(业务重复处理)、商品超卖等问题，通用的解决方案就是本文所使用的“分布式锁”， 在同一个业务中，其中一个请求获取到锁之后，其他请求只有在获取到锁的请求释放锁(或者锁失效)之后才能继续“争抢”锁， 没有获得锁的请求是没有执行业务的权限的。

　　方案论证

　　给大家讲讲，线程锁及进程锁的定义!首先要提到与分布式锁相对应的是线程锁、进程锁。

　　线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线

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

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

　　程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量(state)。

　　这里我们主要讨论两种方案：基于redis的分布式锁和基于zookeeper的分布式锁

　　基于redis的分布式锁

　　redis自身就提供了命令：SET key value NX PX expireTimeMs，专门用于处理分布式锁的场景，效率高且提供锁失效机制， 即使由于某种情况客户端没有发送解锁请求，也不会造成死锁。

　　但是如果redis跑在集群的情况下，由于redis集群之间采用异步的方式进行数据同步，因此在并发量大的情况下有可能遇到数据同步不及时造成多个请求同时获取到锁， 虽然业界有redlock算法以及redisson客户端实现能基本处理此类问题，也并不能完美解决这个问题，其算法逻辑实现还很复杂， 更有甚者有分布式的专家Martin写了一篇文章《How to do distributed locking》, 质疑redlock的正确性。Martin最后对redlock算法的形容是： neither fish nor fowl (非驴非马)。 本人觉得这篇文章(《基于Redis的分布式锁真的安全吗?》)，就redis集群分布式锁的安全问题就讲得非常好。

　　结论：

　　优点：性能好

　　缺点：存在集群数据同步不及时问题;锁失效时间不好控制

　　因此，要想使用redis分布式锁，最好使用redis单点模式，但是没有人能保证redis单点的高可用性。

　　基于zookeeper的分布式锁

　　zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是一个为分布式应用提供一致性服务的软件， 提供的功能包括：配置维护、域名服务、分布式同步、组服务等。zookeeper机制规定同一个节点下只能有一个唯一名称的节点， zookeeper上的一个znode看作是一把锁，所有客户端都去create同一个znode，最终成功创建的那个客户端也即拥有了这把锁。 zookeeper节点有两大类型：持久化节点和临时节点，客户端创建一个临时节点，当此客户端与zookeeper server断开后，该临时节点会自动删除。 由于zookeeper本身就强一致性的实现机制，因此不存在数据不一致的问题。

　　zookeeper提供了原生的API方式操作zookeeper，因为这个原生API使用起来并不是让人很舒服，于是出现了zkclient这种方式，以至到后来出现了Curator框架， Curator对zkclient做了进一步的封装，让人使用zookeeper更加方便。有一句话，Guava is to JAVA what Curator is to Zookeeper。 Curator实现zookeeper分布式锁的基本原理如下：

　　在zookeeper指定节点(${serviceLockName})下创建临时顺序节点node_n

　　获取${serviceLockName}下所有子节点children

　　对子节点按节点自增序号从小到大排序，判断本节点是不是第一个子节点

　　若是，则获取锁;若不是，则监听比该节点小的那个节点的删除事件

　　若监听事件生效，则回到第二步重新进行判断，直到获取到锁

　　若超过等待时间，则获取锁失败

　　就上面的Curator对分布式锁实现的算法还是挺复杂的，效率也不是太高，因为创建节点、获取所有子节点并排序等操作涉及到多个网络IO以及代码逻辑处理，所以效率上会打折扣， 还有释放锁的时候只会删除children节点，并不会删除${serviceLockName}节点，因此zookeeper server中有可能会出现大量的${serviceLockName}节点占用内存空间和Watcher。

　　因此，本人觉得Curator有些过于复杂了，可以直接利用zookeeper的特性(一个节点下只能有一个唯一名称的节点，客户端创建一个临时节点，当此客户端与zookeeper server断开后，该临时节点会自动删除)， 重复创建子节点会抛出KeeperException.NodeExistsException(节点已存在异常)来实现zookeeper分布式锁。

　　结论：

　　优点：不存在数据不一致问题;有效的解决单点问题;锁有效时间控制灵活

　　缺点：性能稍差，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能。并且创建和删除节点只能通过Leader服务器来执行，然后将数据同步到其他机器上。

　　因此，本文强烈推荐使用zookeeper来实现分布式锁，但是又会多引入组件，为项目增加了风险。以上是我对zookeeper的 理解了，以后我还会继续为大家更新新的技术请大家期待吧!!!

       原文出处:田心双木