“ zk” zk:您知道zk是这样吗?

发布时间:2019-11-06 浏览:
ZK集群
群集仅阻止单个zk挂起。这将禁用(或受其影响)所有依赖zk的服务。实际上,zkClient缓存了调用者的zkServer数据。您可能需要研究它的外观。根据分析,博客作者此时不知道如何进行分析。感谢您对退伍军人的建议!
ZookeeperService集群是多个从属的主结构。
更新数据时,请首先更新主节点(该节点指的是服务器,而不是Znode),然后与辅助节点同步。
读取数据时直接读取从节点。
说到这个主控多集群模式,您可以想到mysql集群模式。这种群集模式可确保较高的服务可用性,但是如何随时确保每个主节点和从节点的数据完整性?
ZK一致性
Zookeeper使用ZAB协议来确保主节点和从节点之间的数据完整性。这与Paxos和Raft相干算法非常相似。
ZAB合约
首先,有必要了解ZAB协议中定义的三个节点状态。
搜索:选举状态。
下一步:跟随者节点(从节点)的状态。
领导者:领导者节点(主节点)的状态。
您还需要了解最大ZXID的概念。
最大ZXID是节点的最后本地事务号,包括时间和计数。
纪元是指纪元,相当于选择了筏算法时的术语。
ZK主节点的灾难恢复
如果当前的主要Zookeeper节点被阻止,则群集将从锁中恢复。
ZAB灾难恢复分为三个阶段。
1)
领导者选拔
在选择阶段,集群中的节点处于搜索状态。
每个节点都开始在其他节点上投票。这包括其自己的服务器ID和最后一个事务ID(ZXID)。
然后,该节点将ZXID与从另一个节点接收到的ZXID进行比较。如果您发现其他人的ZXID大于您,即数据比您新,则恢复投票,并投票给拥有最大已知ZXID的节点。
每次投票后,服务器都会计算投票数,以确定该节点的投票数是否超过一半。
如果存在这样的节点,它将成为准领导者,并且状态更改为领导者。
其他节点的状态如下。
2)
发现
发现阶段用于检测从属节点上的最新ZXID和事务日志。
我为什么要在节点上寻找最后一笔交易,因为选择了领导者作为主节点,并且集群中的数据是最后一笔?
这是为了避免意外情况,例如由于网络原因在上一阶段有多个领导者时。
接下来,在这个阶段,领导者集思广益,并获得了追随者时代的最后价值。
领导者选择最大的纪元,根据该值加1,生成一个新纪元,并将其分配给每个跟随者。
进入新纪元后,每个关注者都将ACK返回给领导者,从而获得每个历史交易记录和ZXID的记录。
读取器选择最大的ZXID并更新其自己的历史记录。
3)
同步处理
在同步阶段,阅读器收集的最后历史事务日志与集群中的所有关注者同步。
仅当一半的关注者同步成功时,此准领导才可以成为正式领导。
从那时起,灾难恢复已正式完成。