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发送请求，判断是否一致，进行事务补全。补全过程中不参与对外服务。

sh zkServer.sh start 启动服务器
jps 查看状态, Quxxxx…main启动成功
sh zkServer.sh status 查看启动状态
sh zkCli.sh 启动客户端

---

补充

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

---

完全分布式搭建

搭建3个节点
在之前必须已经有java jdk 安装好。

关闭防火墙

关闭防火墙
]#  service ipables stop  
永久关闭防火墙
]#  chkconfig iptables off   

解压zookeeper.jar包

]# tar -xvf  zk.jar

修改zoo.cfg

]# cd conf 
]# cp zoo_sample.cfg  zoo.cfg  重命名

vim zoo.cfg

dataDir=/home/software/zookeeper-3.4.8/tmp
server.1=198.168.11.101:2888:3888
server.2=198.168.11.102:2888:3888
server.3=198.168.11.103:2888:3888

在zk目录啊，创建tmp文件，vim myid, 将当前节点编号写入

将zk文件夹拷贝给3个节点

 scp -r zookeeper-3.5 root@11.22.33.44:/home/bigdata/

然后就可以启动节点，查看状态

sh zkServer.sh start
sh zkServer.sh status

可以看到1个leader+ 2个follower