一 zookeeper
Zookeeper
是一个开源的分布式协调服务框架 ，主要用来解决分布式集群中应用系统的
一致性问题和数据管理问题。
是一个分布式的应用协调、数据同步的框架，保证数据的一致性。
二 zk的应用协调/通知
Zookeeper中特有的Watcher注册与异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。
在绝大多数分布式系统中，系统机器间的通信无外乎
心跳检测、工作进度汇报和系统调
度
。
三 分布式锁
分布式锁用于控制
分布式系统之间同步访问共享资源的一种方式
，可以保证不同系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。
排它锁又称为写锁或独占锁
，若事务
T1
对数据对象
O1
加上了排它锁，那么在整个加锁期
间，只允许事务
T1
对
O1
进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任
何类型的操作，直到
T1
释放了排它锁
①
获取锁
，在需要获取排它锁时，所有客户端通过调用接口，在
/exclusive_lock
节点下创建
临时子节点
/exclusive_lock/lock
。
Zookeeper
可以保证只有一个客户端能够创建成功，没有成
功的客户端需要注册
/exclusive_lock
节点监听。
②
释放锁
，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此
时，所有在
/exclusive_lock
节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获
取。
共享锁又称为读锁
，若事务
T1
对数据对象
O1
加上共享锁，那么当前事务只能对
O1
进行读取操
作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。
在需要获取共享锁时，所有客户端都会到
/shared_lock
下面创建一个临时顺序节点 。
四 zk的架构
Zookeeper
集群是一个基于主从架构的高可用集群
| 角色 | 描述 |
| Leader |
- 负责调度：它会发起并维护与各 Follwer及Observer间的心跳。
- 处理事务性写操作请求：所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
- 参与投票，并负责投票选举。
|
| 学习者（learner）-跟随者（follower） |
- 接收客户端的请求，并向客户端返回结果。
- Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
3.参与集群投票 |
| 学习者（learner）-观察者（observer） | 1.接收客户端的请求，并向客户端返回结果。 2.Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。 3.不参与集群投票 |
| 客户端 | 请求发起方 |
五 zk的leader选举
Leader
选举是保证分布式
数据一致性
的关键所在。
1.服务器启动时期的
Leader
选举：
(1)
每个
Server
发出一个投票
。由于是初始情况，
Server1
和
Server2
都会将自己作为
Leader
服务器来进行投票，每次投票会包含所推举的服务器的
myid
和
ZXID
，使用
(myid, ZXID)
来表示，此时
Server1
的投票为
(1, 0)
，
Server2
的投票为
(2, 0)
，然后各自将这个投票发给集群中
其他机器。
(2)
接受来自各个服务器的投票
。集群的每个服务器收到投票后，首先判断该投票的有
效性，如检查是否是本轮投票、是否来自
LOOKING
状态的服务器。
(3)
处理投票
。针对每一个投票，服务器都需要将别人的投票和自己的投票进行
PK
，
PK
规则如下
·
优先检查
ZXID
。
ZXID
比较大的服务器优先作为
Leader
。
·
如果
ZXID
相同，那么就比较
myid
。
myid
较大的服务器作为
Leader
服务器。
对于
Server1
而言，它的投票是
(1, 0)
，接收
Server2
的投票为
(2, 0)
，首先会比较两者的
ZXID
，均为
0
，再比较
myid
，此时
Server2
的
myid
最大，于是更新自己的投票为
(2, 0)
，然后重
新投票，对于
Server2
而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次
投票信息即可。
(4)
统计投票
。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到
相同的投票信息，对于
Server1
、
Server2
而言，都统计出集群中已经有两台机器接受了
(2, 0)
的
投票信息，此时便认为已经选出了
Leader
。
(5)
改变服务器状态
。一旦确定了
Leader
，每个服务器就会更新自己的状态，如果是
Follower
，那么就变更为
FOLLOWING
，如果是
Leader
，就变更为
LEADING
。
2. 服务器运行时期的
Leader
选举
选举过程跟情况1相似。
按照上述初始化的情况，server3成为了leader，在运行期间处于leader的server3挂了，那么非Observer服务器server1、server2、server4、server5会将自己的节点状态变为LOOKING状态
1、开始进行leader选举。现在选举同样是根据myid和zxid来进行
2、首先每个server都会给自己投一票竞选leader。假设server1的zxid为123，server2的zxid为124，server4的zxid为169，server5的zxid为188
3、同样先是比较zxid再比较，server1、server2、server4比较server4根据优先条件选举为leader。然后server5还是跟随server4，即使server5的zxid最大，但是当选举到server4的时候，机器数已经过半。不再进行选举，跟随已经选举的leader
原文链接：https://blog.csdn.net/ypp91zr/article/details/89409707
六 zk的Java api （了解）
Zookeeper的JavaAPI使用的是一套zookeeper客户端框架
Curator ，解决了很多Zookeeper客户端非常底层的细节开发工作 。
Curator包含了几个包：
curator-framework：对zookeeper的底层api的一些封装
curator-recipes：封装了一些高级特性，如：Cache事件监听、选举、分布式锁、分布式计数器等
