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的集群一般不会太大 越大一致性越难保证