Zookeeper

Zookeeper
1:目录结构：
/ 下面

创建节点目录
create /test

在节点中放数据,节点叫做：zNode
Create /test abc
Get /test

Zk中的znode的类型
持久节点：会话结束之后，节点依然存在
持久序号节点：创建出的节点，会根据先后顺序在节点之后带上一个数值，后面值就越大，单调递增
临时节点：会话有效，关闭立即删除（轮训sessiion Id，失效就删除），注册中心与发现的实现原理



@ConfigurationProperties，

羊群效应：链式监听-第二位只需要关心第一位是否上锁，第三位只需哟关注第二位



主从节点：



Zookeeper选举概述
SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。

ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。

最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term，标识当前leader周期，每次选举一个新的Leader服务器后，会生成一个新的epoch

• 所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID（ZXID）。
• 如果发现别人的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。
• 每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

2. 发现阶段 Discovery

• 为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。
• Leader集思广益，接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。
• 各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

3. 同步阶段 Synchronization
   Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。



通信协议：
ZAB协议
ZAB协议是一种支持崩溃恢复的的原子广播协议，用于在Zookeeper之间传递消息，使所有的节点都保持同步。ZAB同时具有高性能、高可用的、容易上手、利于维护的特点，同时支持自动的故障恢复。

ZAB 协议包括两种基本的模式:崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障 导致不存在过
半的服务器与 Leader 服务器保持正常通信时，所有进程(服务 器)进入崩溃恢复模式，首 先选举产生新的 Leader 服务器，然后集群中 Follower 服务器开始与新的 Leader 服务器进 行数据同步，当集群中超过半数 机器与该 Leader 服务器完成数据同步之后，退出恢复模式 进入消息广播模 式，Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求 处理。

Zookeeper 的数据同步通常分为四类:
(1)直接差异化同步(DIFF 同步)
(2)先回滚再差异化同步(TRUNC+DIFF 同步)
(3)仅回滚同步(TRUNC 同步)
(4)全量同步(SNAP 同步)
在整个过程中，Zookeeper都处于不可用状态，直到数据同步完毕，Zookeeper才可以对外提供正常服务。

分布式集群中为什么会有 Master?
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的 机器可以共享 这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行 leader 选举。