Zookeeper

Zookeeper

ZAB协议

Zxid（Transaction id）类似于 RDBMS 中的事务 ID，用于标识一次更新操作的 Proposal（提议）ID。为了保证顺序性，该 zkid 必须单调递增。

模式

恢复模式（选主）

广播模式（同步）

ZAB协议四阶段

Leader election（选举阶段-选出准 Leader）:节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。

Discovery（发现阶段）：在这个阶段，followers跟准leader进行通信，同步 followers 最近接收的事务提议。

Synchronization（同步阶段）：同步阶段主要是利用 leader前一阶段获得的最新提议历史， 同步集群中所有的副本。

Broadcast（广播阶段）：到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。

角色

Leader

所有的写操作必须要通过 Leader完成再由 Leader将写操作广播给其它服务器

只要有超过半数节点（不包括 observeer节点）写入成功，该写请求就会被提交

Follower

Follower可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理

负责在 Leader处理写请求时对请求进行投票

Observer

Zookeeper需保证高可用和强一致性，为了支持更多的客户端，需要增加更多 Server；Server 增多，投票阶段延迟增大，影响性能；引入 Observer

角色与 Follower 类似，但是无投票权

Observers 接受客户端的连接，并将写请求转发给 leader节点

集群启动领导选举

第一步:每个Server发出一个投票

集群刚启动时，所有服务器的zxid都为0。各服务器初始化后，都投票给自己，并将自己的一票存入自己的票箱

第二步:接收来自各个服务器的投票

第三步:PK选票并更新选票

2.如果ZXID相同的话，比较myid，myid较大的服务器作为Leader服务器

注释

myid:服务器ID，用来标识一台Zookeeper集群中的机器，每台机器不能重复

ZXID:事务ID

第四步:统计投票

统计所有选票，判断是否有过半机器接收到相同的投票信息

第五步:改变服务器状态

一旦确定Leader，每个服务器更新自己的状态

zookeeper集群存在的问题

假死

由于心跳超时（网络原因导致的）认为master死了，但其实master还存活着。

脑裂

由于假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，  

导致出现了两个master ，有的客户端连接到老的master 有的客户端链接到新的master。

解决方式

Quorums（法定人数）

只有集群中超过半数节点投票才能选举出Leader

应用场景

发布订阅

一个节点的变更并在变更发生时执行我们预先设置好的回调函数

命名服务

使用了命名空间和顺序节点解决唯一标志符的问题

分布式锁

1.通过 getChildren 获取当前等待锁的全部节点

2.如果当前节点是所有节点中序号最小的就得到了当前资源的使用权限，在对资源进行处理后，就可以通过删除 /resource/lock-xxx 来释放锁

3.如果当前节点不是最小值，就会注册一个 Watcher 等待 /resource 子节点的变化直到当前节点的序列号成为最小值。

协调分布式事务

1.当前节点作为协调者在每次发起分布式事务时都会创建一个 /transfer/tx 的持久顺序节点

2.然后为几个事务的参与者创建几个空白的节点，事务的参与者在收到事务时会向这些空白的节点中写入信息并监听这些节点中的内容