zk的应用场景
用监听机制监听自身的znode的变化
1）命名服务：
全局统一命名服务
同一个文件3个副本 修改文件名 怎么保证3个副本文件名一样
将全局统一的命名放在zk的znode的节点的存储内容上
哪一个客户端对这个感兴趣就可以添加监听
2）配置文件管理
安装hadoop集群的时候 集群中的每一个节点配置文件统一
zk管理配置文件的时候
1）配置文件的内容是否修改
2）配置文件是否新添加了
3）配置文件是否删除了
3）集群管理
1）集群中的节点的上下线的问题
namenode监控datanode的下线需要630s 10min 30s
让namenode可以立即感知datanode的下线
当有一个节点上线的时候就会在zk上创建一个临时节点
只要datanode节点下线 这个时候相当于zk的客户端断开
这个时候就会将这个客户端创建的临时节点删除
2）集群的选主
zk内部自带了一套完善的选主机制
4）锁管理：
读锁：共享锁 所有客户端都可以获取锁
在zk上创建的一个临时的有编号的节点
写锁：排他锁 只能允许一个客户端获取锁
在zk上创建的一个临时的无编号的节点
时序锁：
在zk上创建的一个临时的有编号的节点 根据编号的大小控制锁
5）队列管理：
秒杀案例
10万部
zk的临时有编号节点
zk的相关理论
zk的角色：
leader：主节点
处理客户端的读写请求 主要处理的写请求
公布最终的决议
follower：从节点
只能处理客户端的读请求 不能处理写请求
如果接受到写请求 将请求转发给leader
在集群中发现leader没有了 可以发起投票选举的
有选举权和被选举权的
observer：被剥夺政治权利的follower
配置：
server.4=hadoop04:2888:3888:observer
对于zk集群来说 读>>>>>写
当zk集群中的读的压力过大的时候 可以配置observer
帮助zk集群减轻数据读取的压力
zk的状态：
1）looking 观望
2）leader---leading 领导
3）follower---following 跟随
4）observer---observing
zk集群的选主：
1）全新集群的选主
刚搭建的时候的集群
根据启动顺序 和id进行选主的
hadoop04---hadoop01---hadoop02--hadoop03---hadoop05
2)非全新集群的选主
集群已经运行了一段时间 集群中存储了一些数据了
选主的依据：
paxos
1）逻辑时钟 标识投票的轮数的
正常情况下所有节点的投票的逻辑时钟应该是一致的
如果有不一致的 这个时候要将这个投票驳回
让这个节点重新投票
最终做到所有节点的逻辑时钟同一
2）数据版本 zxid zxid越大的证明数据版本越新
3）id
选主过程
1）先根据逻辑时钟 如果逻辑时钟不统一 先同一逻辑时钟
2）逻辑时钟同一之后 再根据数据版本 数据版本大的胜出
数据全的胜出
3）在在数据版本（具有最新数据版本的）相同的节点中
根据id进行最后选举 id大的胜出
最终选取的leader肯定是数据最新的节点
zk的数据同步：
集群重新选主之后 必然做的事情 就是做数据同步
follower和leader的数据同步
流程：
1）follower连接leader 并发送自己最大的zxid
2）leader进行对比 将自己的最大的zxid和follower的发送的
zxid进行对比，如果leader的大于follower的 则通知follower
进行数据同步
3）follower发送数据同步的请求
4）leader确定当前follower的数据同步点
5）follower开始进行数据同步 这个过程是不对外提供读写服务的
6）follower同步完成 发送消息给leader
leader就会修改当前的follower的状态为update 这个时候follower
就可以接受客户端的读写请求 但是只能处理读请求 写请求要转发leader
zk的写数据的流程：
create set delete rmr
客户端如果发送写数据的请求 这个请求最终被leader处理
leader会先写入数据 写入完成之后 通知follower进行数据同步
follower就会开始进行数据同步 （并行的）
每一个follower只要数据同步完成就会发消息给leader
leader接受到过半的节点的写入成功的返回信息 则认为这次写入成功
其他节点慢慢进行同步 在数据同步的过程中 是不对外提供服务的
生产中zk的集群一般不会太大 越大一致性越难保证