目录
文章内容来自：南京大学 / 星环科技课程，大数据理论与实践课程Ⅰ
高可用、高容错和高性能的分布式协调系统。
将复杂易错的分布式一致性服务封装起来，形成高效可靠的原语集，并提供简单易用的访问接口
为大型分布式系统提供关键、共性、高效和可靠的协调服务。
大数据开源技术体系的基础组件，无可替代。开源免费、简单易用、高可用、高容错、高性能。被HDFS、YARN、Kafka和HBase等技术高度依赖
最终一致性：保证数据在各节点的副本最终能够达到一致状态，这是ZK最重要的功能；
有限实时性：不能保证一定能读到最新数据，要想实时获取最新数据，应先调用sync()进行强制同步；
原子性：集群所有服务器或者都成功执行了某一事务，或者都没有，不存在第三种情况；
顺序性：从同一客户端发起的事务请求，最终会严格按照其发起顺序应用到ZK中；
可靠性：服务端一旦成功执行了事务，则该事务所引起的数据变更会被一直保留；
单一视图：无论客户端连接到哪一台服务器，所看到的数据模型都是一致的；
四种角色：Leader、Follower、Observer和Client。
Leader和Follwer遵循“Quorum仲裁机制（过半策略）”，参与事务处理和Leader选举的投票。
若Leader+Follwer的数量为m，则Quorum = m/2 + 1，只有投票数>=Quorum，事务和选举才判定成功。
Leader+Follwer的数量最好是奇数（2n+1），在不影响事务处理的前提下，最多可容忍n台宕机
例如：对于节点数为5和6的两个集群
①二者都最多容忍2台宕机，所以容灾能力相同（quorum5=3，quorum6=4，5-3=6-4=2台）；
②前者的Quorum数为3，后者为4，前者更小，事务处理和选举的效率更高
1，在不影响写性能的前提下，提升读操作的性能和吞吐量
2，提升集群的可扩展性，以及大规模访问的承载能力
3，跨中心部署Observer ，为本地读请求提供快速响应
ZK的最小数据单元
节点有数据存储功能（非数据库），大小不能超过1M
节点中的数据应尽可能小，数据过大会导致ZK性能明显下降
如果确实要存储较大的数据，可将其放在数据库中，而存储地址放在Znode中。以HBase为例，元数据放在RegionServer中，元数据的寻址入口放在ZK中。
Znode通过挂载子节点而形成的一个树状层次化命名空间，结构类似于Linux文件系统，但没有目录和文件，只有节点和子节点
绝对路径（非相对路径）作为节点名称，用于唯一标识节点（主节点挂掉，其余节点竞争创建znode，由于命名唯一，且只有一个节点可以创建成功，所以可以用来选主）
根节点为“/”，非根节点为不能以“/”结尾
客户端为实现Znode读写操作而与ZK服务器建立的TCP长连接，即会话
在SessionTimeout时间内，客户端会通过心跳检测（Ping）或发送读写请求来激活和保持会话。同样，服务器要是一直未收到客户端消息，就会判定超时并关闭会话
在某一会话中，客户端请求以FIFO方式顺序执行
1，持久节点（PERSISTENT）
2，临时节点（EPHEMERAL）
3，顺序节点（SEQUENTIAL）
4，持久顺序节点（PERSISTENT_SEQUENTIAL）
5，临时顺序节点（EPHEMERAL_SEQUENTIAL）
Znode版本是形如0,1,2,…,N的单调递增数字，不是形如v1.2.1的软件版本
1，dataVersion（数据版本）
2，cVersion（子节点版本）
3，aclVersion（ACL版本）
4，利用版本确保分布式事务操作的原子性
Zookeeper Atomic Broadcast，ZK原子广播协议。
基于该协议，ZK实现了Master/Slave架构下集群各节点副本数据的最终一致性。
包括两种模式：正常运行时的消息广播模式、Leader故障时的崩溃恢复模式。
SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
1，Follwer接收客户端写请求，并将其转发给Leader
2，Leader接收写请求，为其分配一个全局唯一的事务ID，Zxid（64位/单调递增）
3，Leader生成一个形如(Zxid, data)的事务提案Proposal（data是事务体），并将其放入各Follower对应的FIFO（顺序性）队列中（通过TCP协议实现），再按照FIFO策略把Proposal广播出去
4，Follower接收Proposal后，先以事务日志的形式落盘，再向Leader发送ack
5，当Leader接收到超过半数的ack之后（包括Leader自己），会向Follower发送commit命令，要求提交事务，同时自己在本地commit
6，Follower收到commit命令后提交事务，同时向客户端反馈结果
（1）当Leader无法提供服务时，快速选举出一个新Leader
（2）Follower与新Leader同步数据
客户端直接从Follower或Observer读取数据
如果要确保读到最新数据，应该先调用sync()进行强制同步
LOOKING：寻找Leader状态，表示当前集群没有Leader，需要进行选举
LEADING：领导者状态，当前角色为Leader
FOLLOWING：跟随者状态，Leader选举已完成，当前角色为Follower
OBSERVING：观察者状态，当前角色为Observer，不参与选举和写事务
参考@尚硅谷教育【源码级图文详解Zookeeper选举机制_大数据培训】
1，服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
2，服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid（SID）比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
3，服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
4，服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
5，服务器5启动，同4一样当小弟。
当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：
而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：
以下部分内容参考@Jayicee【Zookeeper中的Watcher机制到底是啥？】
watcher机制是观察者模式在分布式场景下的实现，是zookeeper一个非常核心的机制，zookeeper提供的发布/订阅，监听节点变化（如节点的删除，内容的变化，或者子节点状态的变化）等核心功能都是基于watcher机制来是是实现的。
watcher机制涉及状态的监听，而这一状态其实包含了两种：
1，注册Watcher监听器：客户端向ZK的某个Znode注册一个Watcher监听器
2，存储Watcher对象：客户端把Watcher对象存储到本地的WatchManager中
3，处理Watcher事件：当服务端的指定事件触发了Watcher，会向客户端发送事件通知
4，回调Watcher对象：客户端根据通知状态和事件类型回调WatchManager中的Watcher对象，执行相应的业务逻辑
1，依据
2，步骤
3，缺点
1，依据
2，步骤
服务统一命名
全局唯一ID
分布式环境下的配置信息同步
利用Znode和Watcher实现统一配置管理
实时掌握分布式系统中各节点的状态是集群管理的前提和基础
利用Znode和Watcher实现集群管理
1，将节点的状态信息写入Znode，利用Watcher监听Znode，以获取节点的实时状态变化
2，节点上下线动态监测
3，Master选举（ZooKeeper提供的选举机制，和ZooKeeper本身的选举机制不同）
