分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成“脏数据”的后果。
在这图中有三台机器，每台机器各跑一个应用程序。 然后我们将这三台机器通过网络将其连接起来，构成个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个分布式系统。
在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源， 然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个协调器， 来让他们有序的来访问这个资源。这个协调器就是我们经常提到的那个锁，比如说进程-1在使用该资源的时候，会先去获得锁，“进程1"获得锁以后会对该资源保持独占，这样其他进程就无法访问该资源，”进程1”用完该资源以后就将锁释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。这个分布式锁也就是我们分布式协调技术实现的核心内容。
为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术来对这些进程进行调度。而这个分布式协调技术的核心就是来实现这个分布式锁。
如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题，这就是分布式锁要解决的问题。
分布式锁实现的三个核心要素：
最简单的方法是使用setnx命令。key是锁的唯一标识，按业务来决定命名。比如想要给一种商品的秒杀活动加锁，可以给key命名为“lock_sale_商品ID”。而value设置成什么呢？我们可以姑且设置成1。加锁的伪代码如下：
setnx(lock_sale_商品ID，1)
当一个线程执行setnx返回1，说明key原本不存在，该线程成功得到了锁；当一个线程执行setnx返回0，说明key已经存在，该线程抢锁失败。
有加锁就得有解锁。当得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。释放锁的最简单方式是执行del指令，伪代码如下：
del(lock_sale_商品ID)
释放锁之后，其他线程就可以继续执行setnx命令来获得锁。
锁超时是什么意思呢？如果一个得到锁的线程在执行任务的过程中挂掉，来不及显示地释放锁，这块资源将会永远被锁住（死锁），别的线程再也别想进来。所以，setnx的key必须设置一个超时时间，以保证即使没有被显示释放，这把锁也要在一定时间后自动释放。setnx不支持超时参数，所以需要额外的指令，伪代码如下：
expire(lock_sale_商品ID, 30)
综合伪代码如下：
if(setnx(lock_sale_商品ID, 1) == 1){
exprie(lock_sale_商品ID, 30)
try{
do something ...
} finally {
del(lock_sale_商品ID)
}
}
以上伪代码存在三个致命问题
设想一个极端场景，当某线程执行setnx，成功得到了锁：
setnx刚执行成功，还未来得及执行expire指令，节点1挂掉了。
这样一来，这把锁就没有设置过期时间，变成死锁，别的线程再也无法获得锁了。
怎么解决呢？setnx指令本身是不支持传入超时时间的，set指令增加了可选参数，伪代码如下：
set(lock_sale_商品ID, 1, 30 , NX)
这样就可以取代setnx指令。
又是一个极端场景，加入某线程成功得到了锁，并且设置的超时时间是30秒。
如果某些原因导致线程A执行的很慢很慢，过了30秒都没执行完，这时候锁过期自动释放，线程B得到了锁。
随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。
怎么避免这种情况呢？可以在del释放锁之前做一个判断，验证当前的锁是不是自己加的锁。至于具体的实现，可以在加锁的时候把当前线程ID当做value，并在删除之前验证key对应对的value是不是自己线程的ID。
加锁：
String threadId = Thread.currentThread().getId()
set(key, threadId, 30, NX)
解锁：
if(threadId.equals(redisClient.get(key))){
del(key)
}
但是，这样做又隐含了一个新的问题，判断和释放锁是两个独立操作，不是原子性。
还是刚才第二点所描述的场景，虽然我们避免了线程A误删掉key的情况，但是同一时间有A，B两个线程在访问代码块，仍然是不完美的。怎么办呢？我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁“续命”。
当过去了29秒，线程A还没执行完，这时候守护线程会执行expire指令，为这把锁“续命”20秒。守护线程从第29秒开始执行，没20秒执行一次。
当线程A执行完任务，会显式关掉守护线程。
另一种情况，如果节点1忽然断电，由于线程A和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。
ZooKeeper是一种分布式协调服务， 用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper 允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
以下为Zookeeper的基本概念。
Zookeeper的数据模型是什么样子呢?它很像数据结构当中的树，也很像文件系统的目录。
树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做Znode
但是，不同于树的节点，Znode 的引|用方式是路径引用，类似于文件路径:
/动物/猫
/汽车/宝马
这样的层级结构，让每一个Znode节点拥有唯一的路径， 就像命名空间一样对不同信息作出清晰的隔离。
这里需要注意一点， Zookeeper 是为读多写少的场景所设计。Znode 并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。
创建节点：
create
删除节点：
delete
判断节点是否存在：
exists
获得一个节点的数据：
getData
设置一个节点的数据：
setData
获取节点下的所有子节点：
getChildren
这其中，exists，getData，getChildren属于读操作。Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。
我们可以把Watch理解成是注册在特定Znode上的触发器。当这个Znode发生改变，也就是调用了create，delete，setData方法的时候，将会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。
具体交互过程如下：
Zookeeper身为分布式系统协调服务，如果自身挂了如何处理呢？为了防止单机挂掉的情况，Zookeeper维护了一个集群。如下图：
Zookeeper Service集群是一主多从结构。
在更新数据时，首先更新到主节点(这里的节点是指服务器，不是Znode)，再同步到从节点。
在读取数据时，直接读取任意从节点。
为了保证主从节点的数据一致性，Zookeeper 采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。
Zookeeper Atomic Broadcast,有效解决了Zookeeper集群崩溃恢复，以及主从同步数据的问题。
最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch 是纪元的意思，相当于Raft算法选主时候的term。
假如Zookeeper当前的主节点挂掉了，集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:
Leader election
选举阶段，此时集群中的节点出于Looking状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器ID和最新事务ID（ZXID）。
接下来，节点会用自身的ZXID和从其他节点接收到的ZXID作比较，如果发现别人家的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
Discovery
发现阶段，用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢?
这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。
所以这一阶段，Leader 集思广益，接收所有Follower发来各自的最新epoch值。Leader 从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后，返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader 选出最大的ZXID,并更新自身历史日志。
Synchronization
同步阶段，把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。
自此，故障恢复正式完成。
Broadcast
ZAB的数据写入涉及到Broadcast阶段，简单来说，就是Zookeeper常规情况下更新数据的时候，由Leader广播到所有的Follower.其过程如下:
ZAB协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性（顺序一致性）。它依靠事务ID和版本号，保证了数据的更新和读取是有序的。
这是雅虎研究院设计Zookeeper的初衷。利用Zookeeper的临时顺序节点，可以轻松实现分布式锁。
利用Znode和Watch，可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和codis-proxy节点的元信息。同时codis-config发起的命令都会通过ZooKeeper同步到各个存活的codis-proxy.
此外，Kafka、 HBase、 Hadoop, 也都依靠Zookeeper同步节点信息，实现高可用。
Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。
Znode分为四种类型：
默认的节点类型。创建节点的客户端与Zookeeper断开连接后，该节点依旧存在。
所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号:
和持久节点相反，当创建节点的客户端与Zookeeper断开连接后，临时节点会被删除：
顾名思义，临时顺序节点结合临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与Zookeeper断开连接后，临时节点会被删除。
Zookeeper分布式锁恰恰应用了临时顺序节点。具体如何实现呢？详细步骤如下：
首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLcok这个节点下面创建一个临时顺序节点Lock1。
之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
这时候，如果再有一个客户端Client2前来获取锁，则在ParentLock下面再创建一个临时顺序节点Lock2。
Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。
于是，Client2向排序仅比它靠前的节点Lock1注册Watch，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下面再创建一个临时顺序节点Lock3。
Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最小的。
于是，Client3箱排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。
这样一来，Client 1 得到了锁，Client 2 监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列。
释放锁分为两种情况：
任务完成，客户端显式释放
当任务完成时，Client1 会显示调用删除节点Lock1的指令。
任务执行过程中，客户端崩溃
获得锁的Client1 在任务执行过程中，如果崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
Zookeeper部署有三种方式，单机模式、集群模式、伪集群模式，以下采用Docker的方式部署
注意： 集群为大于等于3的奇数，如3、5、7，不宜太多，集群机器多了选举和数据同步耗时长，不稳定。
version:'3.1'
service:
zoo1:
image:zookeeper
restart:always
hostname:zoo1
ports:
- 2181:2181
environment:
ZOO_MY_ID:1
ZOO_SERVERS:server.1=zoo1:2888:3888
docker exec -it zookeeper_zoo1 /bin/bash
准备3台Ubuntu Server系统，并分别配置Zookeeper
docker-compose.yml
version:'3.1'
services:
zoo1:
image:zookeeper
restart:always
environment:
ZOO_MY_ID:1
ZOO_SERVERS:server.1=192.168.75.130:2888:3888 server.2=192.168.75.134:2888:3888 server.3=192.168.75.135:2888:3888
network_mode:host
验证测试
docker-compose.yml
version:'3.1'
services:
zoo2:
image:zookeeper
restart:always
environment:
ZOO_MY_ID:2
ZOO_SERVERS:server.1=192.168.75.130:2888:3888 server.2=192.168.75.134:2888:3888 server.3=192.168.75.135:2888:3888
network_mode:host
验证测试
docker-compose.yml
version:'3.1'
services:
zoo1:
image:zookeeper
restart:always
environment:
ZOO_MY_ID:3
ZOO_SERVERS:server.1=192.168.75.130:2888:3888server.2=192.168.75.134:2888:3888 server.3=192.168.75.135:2888:3888
network_mode:host
验证测试
version:'3.1'
services:
zoo1:
image:zookeeper
restart:always
hostname:zoo1
ports:
- 2181:2181
environment:
ZOO_MY_ID:1
ZOO_SERVERS:server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
zoo2:
image:zookeeper
restart:always
hostname:zoo2
ports:
- 2181:2181
environment:
ZOO_MY_ID:2
ZOO_SERVERS:server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
zoo3:
image:zookeeper
restart:always
hostname:zoo3
ports:
- 2181:2181
environment:
ZOO_MY_ID:3
ZOO_SERVERS:server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
docker exec -it zookeeper_zoo1_1 /bin/bashdocker exec -it zookeeper_zoo2_1 /bin/bashdocker exec -it zookeeper_zoo3_1 /bin/bash
配置文件路径：/conf/zoo.cfg
clientPort=2181
dataDir=/data
dataLogDir=/datalog
tickTime=2000
配置文件路径：/conf/zoo.cfg
clientPort=2181
dataDir=/data
dataLogDir=/datalog
tickTime=2000
initLimit=5
syncLimit=2
autopurge.snapRetainCount=3
autopurge.purgeInterval=0
maxClientCnxns=60
server.1=192.168.0.1: 2888:3888
server.2=192.168.0.2: 2888:3888
server.3=192.168.0.3: 2888:3888
注意: server.A中的A是在dataDir配置的目录中创建一个名为myid的文件里的值(如: 1)
./zkServer.sh start
./zkServer.sh stop
./zkServer.sh restart
./zkServer.sh status
客户端连接服务器并进入Bash模式
./zkCli.sh -server <ip>:<port>
创建节点（Bash模式）
create /test "hello zookeeper"
查询节点（Bash模式）
get /test
删除节点（Bash模式）
delete /test