zookeeper基础总结

zookeeper描述

分布式协调和管理的机制
中心化服务：配置信息，统一命名，提供组服务
树状结构，每个节点必须携带数据，临时节点不能挂载子节点。

单机模式
伪分布式
完全分布式

包含临时节点和持久节点。

选举机制

当集群启动时，会进入选举状态。每个节点都会选举自己当leader，向其他节点发送选举信息（最大事务Id, 选举id），互相之间比较得出leader，其他节点作为follower.
最大事务Id 最大的节点，则为leader,否则比较选举id最大的。且选举必须满足过半性。
若已经选举出leader,后来添加的节点都默认成为follower.

脑裂

网络波动不稳定，隔离出去的节点选举，出现多个leader。

ZAB协议

实现数据一致性，基于原子广播和崩溃恢复的协议。

原子广播

原子广播是基于2PC-二阶段算法设计，加入过半性改良。
原子广播的流程：
leader收到命令，记录Log,然后将请求加入队列发送给follower。
follower收到队列后，将请求取出记录log
记录成功则认为命令是否能执行，反馈给leader
若超过半数同意执行，则执行命令。否则不执行。将log记录删除（事务回滚）。

二阶段提交

“一票否决”-核心思想
在二阶段提交中，有几个状态，请求阶段：协调者收到请求，将请求发送给参与者，等待参与者反馈。执行阶段：参与者反馈YES给协调者，若全为YES则执行命令。中止阶段：若有一个为NO则中止命令。

崩溃恢复

leader宕机或者丢失，集群不会停止工作，而是选举新的leader，每个leader有一个递增的epochid，若宕机的leader恢复工作，则判断epochid大的为leader,小的自动变成follower.

基本特性

过半性 - 过半选举，过半执行
数据一致性 - 原子广播
可靠性 - 崩溃恢复
顺序性 - 顺序执行
原子性 - 都执行或者都不执行
实时性 -

操作命令

create /date ‘zb’
set /data ‘zb1’
create -e /data ‘zb’ 临时
create -s /data ‘zb’
每一个操作都记做一个事务，读操作是不记录的。

新节点连入集群，会判断最大事务ID，向leader发送请求，判断是否一致，进行事务补全。补全过程中不参与对外服务。

补充

原子广播中，记录失败的follower,在收到leader发来要执行的请求，会反复向leader发送请求，重新获取命令，直到执行成功。

本文地址：https://blog.csdn.net/zhouben12/article/details/107505862