zookeeper 的原理 及 集群选主

zookeeper的典型应用场景：

`
配置文件管理
集群管理
锁管理
队列管理
`

配置文件管理：

场景：3台机器，都有公共的配置文件， 在config目录下，3台机器如何保证配置文件的一致性？
使用：监听器+文件系统 

集群管理：

1）集群选主
	hbase 选主机制，过半选举
2）节点的上下线
	目前的hadoop集群中，namenode 识别datanode宕机，需要630s 的时间，还是挺长的。
	如果有zookeeper的话，基本可以实时监控是否宕机

锁管理：

读锁：
	共享锁，实际上创建的是 临时有编号节点
写锁：
	排它锁，实际上创建的是 临时无编号节点

队列管理：

fifo： 先进先出
案例：抢购   实际上创建的是 临时有编号节点

命名服务：

一个节点的命名修改，其它节点可以迅速修改。（分布式，全局统一命名）

zookeeper的应用：

	1）选主机制
	2）利用监听器监听文件系统

zookeeper中的角色：

leader

leader :
	发起提议
	接受客户端的读写请求  主要处理写请求
	具有选举权 和 被选举权
	时刻具备最新数据

follower

follower
	接受客户端的读写请求  读请求可以自己处理  如果接受到客户端的写请求  将写请求转发给leader 
	具备选举权  和 被选举权

observer

observer 
	配置方式：  server.4=hadoop04:2888:3888：observer
	不具备选举权 和被选举权  的 follower 
	作用：分担集群的读数据的压力  接受到写请求  转发leader 
	95%读  5%写

整个写入数据过程中， leader最先写入， follower|observer 从leader进行数据同步。
如果follower|observer 数据更新过程中， leader宕机了， 则重新选主。
选主参考依据： 数据完整度

详解stat信息：

cZxid = 0x200000075
ctime = Mon Aug 05 23:52:15 CST 2019  节点创建时间
mZxid = 0x200000075
mtime = Mon Aug 05 23:52:15 CST 2019  节点修改时间
pZxid = 0x20000007e
cversion = 6  创建版本
dataVersion = 0  数据版本
aclVersion = 0  权限版本
ephemeralOwner = 0x0  节点的生命周期标识
	永久节点   0x0 
	ephemeralOwner = 0x16c5d8f0a950009  临时节点 
	sessionid = 0x16c5d8f0a950009   
dataLength = 0   数据长度
numChildren = 6  子节点个数

数据版本id 数据版本越大   数据越新  全局的
cZxid  创建节点事件id 
	创建节点  +1 
mZxid  修改节点事件id 
	修改节点内容 发生变化
pZxid	子节点变化的事件id 
	创建一个节点的子节点的时候   发生变化
	
cZxid   mZxid  pZxid  整体无论修改了哪一个  都会全局顺序递增
上面的3个id 共同标识  整个集群中的这个机器  数据更新程度
只要zxid 最大  这个机器中的数据最新的

集群选主

全新集群选主：

依据 id 和启动顺序。

当集群启动数量不到一半的时候：没有leader

当集群启动数量超过一半的时候，选取id比价大的为leader，其余为follower

非全新集群选主：

集群运行一段时间之后,如果leader宕机，则集群重新选主。
依据：
	1）myid 
	2）zxid 
	3）逻辑时钟  投票的轮数

选举规则：
1）先根据逻辑时钟，如果逻辑时钟不统一，先统一逻辑时钟。
2）统一完成逻辑时钟之后，按照zxid进行选择，  zxid大的胜出。
3）在zxid大的里面选myid， myid大的胜出
最终选的leader，数据版本是最新的。

数据同步过程：

选举新的leader之后，follower|observer 的数据需要和leader的数据保持一致。这就需要数据同步。数据同步过程如下：

	1、leader 等待 follower|observer 连接；
	2、follower|observer 连接 leader，将最大的 zxid 发送给 leader；
	3、leader 根据 follower 的 zxid 确定是否需要更新数据，如果follwer的   zxid < leader 的zxid，则需要数据同步，确定数据更新同步点；
	4、follower 进行数据更新，follower 将自己的状态切换为 update 状态，不再接受客户端的读数据请求；
	5、follower更新完成数据，将自己的状态改为updated ，又可以重新接受 client 的请求进行服务了。
	
	
	follwer   zxid == leader zxid  不需要更新数据
	follwer   zxid < leader zxid   需要更新数据
	需要更新的数据范围为：	follwer zixd + 1  ---> leader zxid 

注意：zookeeper节点在进行数据同步的过程中，是不对外提供服务的。

写数据过程：

1）客户端写入zk数据时候 请求最终被leader进行处理
2）leader进行数据写入。 
3）leader写入数据成功，不代表数据真的写入成功。  follower | observer 进行数据同步，同上面。
4）当过半的follower更新数据成功，   leader才将这条数据标记为真正的可读数据， 剩下的机器自己慢慢更新。