主要服务于分布式系统,可用来做统一配置管理、统一命令服务、分布式锁、集群管理等
数据的发布订阅:由于大数据集群中节点过多,不可逐台进行修改,在设计时候采用统一的配置中心,之后只需要将新的配置发送到配置中心,所有节点都可自动下载更新命名服务:zk通过顺序节点的特性来生成全局唯一IDMaster选举:让所有服务节点去竞争性地创建用一个ZNode,必然只有一个服务节点能够创建成功分布式锁:集群管理:事务操作:
在zk集群启动时候,需要确定一台leader服务器。首先确保集群之间可以相互通信第一次选举:假如集群有五台服务器:服务器1启动时候,会投自己一票,此时不满半数,服务器1保持为looking服务器2启动时候,服务器1和服务器2交换信息,但服务器1发现服务器2的myid比自己大,所以将自己的票投给服务器2,此时服务器1有0票,服务器2有两票,不满半数,都为looking服务器3启动时候,重复上述步骤,拥有3个选票,超过半数,当选为leader,此时其他服务器状态为following
第二次选举:当集群中的leader挂掉之后,其他所有节点会把自己的状态设置为looking,此时的选举规则为①EPOCH大的直接胜出,②:EPOCH相同,事务id大的胜出,③:事务id相同,服务器id大的胜出SID:服务器ID。用来唯一标识一台 ZooKeeper集群中的机器,每台机器不能重复,和myid一致。ZXID:事务ID。ZXID是一个事务ID,用来 标识一次服务器状态的变更。在某一时刻, 集群中的每台机器的ZXID值不一定完全一 致,这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。Epoch:每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加
持久节点类型:节点在创建后,一直存在,直到主动来删除这个节点,不会因为客户端会话失效而消失持久顺序节点:和持久节点类似,临时节点:临时节点的生命周期和客户端会话绑定,如果客户端会话失效,该节点消失
在ZK集群中,建议部署奇数个节点,大多数情况下,三个就ok,节点数越多,节点间通信所需要的时间也越久,选举leader时候需要的时间也越久zk集群的容错数:在保证集群可用的前提下,最多允许挂掉的节点个数,也叫做zk集群的容错数,
原本是一个leader,现在变成了两个leader服务,一般zk集群中不会轻易出现脑裂问题,原因在于过半机制在zk中的过半机制是大于,而不是大于等于:为了防止脑裂假死:由于心跳超时,认为leader死了,实际上leader还活着脑裂:由于假死会发起新的选举,选举一个新的leader,但此时旧的那个leader网络恢复,故此时集群中有两个leader,此时造成脑裂解决脑裂问题:quorums方式:
ZAB(zookeeper autom broadcast)原子广播协议。ZAB协议分为两部分:消息广播阶段:leader接收事务提交,并且将新的proposal请求广播给follower节点,收集各个节点的反馈,决定是否commit崩溃恢复机制:如果在同步过程中出现 Leader 节点宕机,会进入崩溃恢复阶段,重新进行 Leader 选举,崩溃恢复阶段还包含数据同步操作,同步集群中最新的数据,保持集群的数据一致性。
ZAB(zookeeper autom broadcast)原子广播协议。ZAB协议是一个分布式一致性算法,让ZK拥有了崩溃恢复和原子广播的能力,进而保证集群中的数据一致性实现架构:任何learner节点接收到非事务请求查询本地缓存然后返回,任何事务操作都需要转发给leader,由leader发起决议,同集群中超过半数的follower返回确认ack时,leader进行广播看,要求全部节点提交事务特性:保证早leader上提交的事务最终被所有服务器提交;保证丢弃没有经过半数检验的事务协议内容:集群启动时候,或者当leader服务器网络中断、崩溃恢复等情况时候,ZAB协议就会进入崩溃恢复模式,选举产生新的leader;当选举产生新的leader,同时集群中由过半机器与该leader服务器完成了数据同步之后,zab协议就会退出崩溃模式,进入消息广播模式