CP模式（ZK）的分布式锁分析

JAVA的锁

锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源。在线程级别中我们可以通过代码的方式来实现锁的功能，例如Lock接口和synchronized关键字，在并发场景中充斥这大量的锁问题（线程锁、数据库锁、进程锁）。

死锁

所谓死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
java 死锁产生的四个必要条件：

• 互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
• 不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
• 请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
• 循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

PS：死锁的概念是百度抄的，轻喷

分布式锁

在以前的开发中，我们是把所有的代码部署在一台服务器中，只有一个jvm虚拟机，所有的请求都是线程级别的，因此我们只需要通过java的锁即可实现线程安全。
在现在的分布式场景下，我们是将一个系统或者是一个功能模块部署在多台服务器中，即一个服务有多个节点。一个请求访问你的系统时，我们的Nginx或者网关会把请求分发给不同的节点中，这时候如果有共享的资源就会出现竞争问题（线程不安全），此时jvm的线程锁无法解决进程间的资源竞争问题，这样分布式锁就出现了。

CP模型的分布式锁

CP模型是保证了在分布式系统中的一致性。CP模型的分布式锁是基于zk或者Etcd来实现的，适用于需要保证数据一致性的场景中。无论是zk还是Etcd本身就是支持分布式场景的组件，在集群有相互同步数据的机制，选择CP模式的分布式锁会牺牲一些系统的性能来保证数据的一致性，CP模式的分布式锁会在主宕机的情况下变的不可用（需要重新选主），即无法保证可用性。

zk分布式锁的原理

zk的分布式锁实现主要是基于zk的节点。zk的节点一共是分为持久节点（PERSISTENT），持久顺序节点（PERSISTENT_SEQUENTIAL），临时节点（EPHEMERAL），临时顺序节点（EPHEMERAL_SEQUENTIAL）四种。持久节点的特点是节点创建之后会一直存在，用户不做删除操作节点不会消失。临时节点的特点是节点会与客户端的会话绑定，客户端的会话结束节点会自动消失。因此zk的分布式锁是基于zk的临时顺序节点来实现。当多个进程访问我们的共享资源时，会先在zk上创建一个临时的顺序节点，并监听上一个节点，在进入业务代码前判断当前创建的节点是否为最小值，如果是最小值则才能做后续的操作，否则不做操作，继续等待。

zk节点操作

创建持久节点：
create /path value
创建顺序持久节点：
create -s /path value
创建临时节点：
create -e /path value
创建顺序临时节点：
create -e -s /path value

zk分布式锁代码实现

代码比较简单做了一个切面，用的是一个zk的jar包中实现的zk锁。如下：

CP模式分布式锁总结

以上是我对zk实现的分布式锁的一些介绍。zk可以很好的保证数据的一直性，不会因为节点宕机而导致数据的丢失，在对数据一致性要求较高的场景中使用即可。但是zk并不是一个专门来做存储的组件，在正式的生产环境中多数是扮演了一个注册中心的角色，是整个系统的协调者，如果让zk来承担较多的数据存储从而实现分布式锁并不是一个很好的方案，因此大多数情况下我们会用Etcd来实现CP模式的分布式锁，Etcd的CAS机制对于分布式锁的存储更友好，后续再写一篇Etcd的分布式锁吧，如有不足望大家指正。