Hello小伙伴们大家好~本兔君又来鸟~~今天要接着为大家介绍Zookeeper呢,有没有很期待哟
下面切入正题!
一般企业级架构的Zookeeper都是采用一主多从的架构,主节点负责写和读而从节点负责读取,在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。在读取数据时,直接读取任意从节点。那么如何保证主从节点数据的一致性呢?Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。
在学习ZAB之前,我们需要首先了解ZAB协议所定义的三种节点状态:
Looking :选举状态。
Following :Follower节点(从节点)所处的状态。
Leading :Leader节点(主节点)所处状态。
最大ZXID又是啥呢?
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:下面一一为大家介绍一波~
1.Leader election
选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。
接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。
每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
2.Discovery
发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
3.Synchronization
同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。自此,故障恢复正式完成。
什么是Broadcast呢?简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式,先发送Propose广播给Follower。
4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
今天的分享就到这里啦,本兔兔是不是讲的很明白呀,小伙们感觉清晰易懂别忘了关注+在看哦,想打个赏我也不拦着
~~