大佬教程收集整理的这篇文章主要介绍了ZooKeeper集群解析,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
ZooKeeper集群解析。
这篇文章中来介绍一下 ZooKeeper 相关的集群角色,还有 ZAB协议,集群的安装在 ZooKeeper入门 中有介绍。
server.0=192.168.182.130:2888:3888:Observer
。ZAB协议的实现借鉴于 Paxos,是为了解决分布式系统的数据一致性问题。
zookeeper 就是根据 zab 协议建立了主备模型完成集群的数据同步(保证数据的一致性),前面介绍了集群的各种角色,这说所说的主备架构模型指的是,在 zookeeper 集群中,只有一台 leader(主节点)负责处理外部客户端的事务请求(写操作),leader 节点负责将客户端的写操作数据同步到所有的 follower 节点中,大概流程如下:
为什么要有限比较ZXID呢?
因为ZXID为事务id,值越大,证明它的数据最新。
在这个选举过程中每个 Server 有三种状态:
情况一的出现场景:
当 leader 收到合法数量 follower 的 ACK 后,就向各个 follower 广播 commit 命令,同时也会在本地执行 commit 并向连接的客户端返回 成功,但是如果在各个 follower 在收到 commit 命令前 leader 就挂了,导致剩下的服务器并没有执行都这条消息。
那么这种情况要怎么处理呢?
1、选举 ZXID 最大的节点作为新的 leader:由于所有提案被 commit 之前必须有合法数量的 follower ACK,即必须有合法数量的服务器的事务日志上有该 proposal,因此,ZXID 最大也就是数据最新的节点保存了所有被 commit 消息的 proposal 状态。 2、新的 leader 将自己事务日志中 proposal 但未 COMMIT 的消息处理。 3、新的 leader 与 follower 建立先进先出的队列, 先将自身有而 follower 没有的 proposal 发送给 follower,再将这些 proposal 的 COMMIT 命令发送给 follower,以保证所有的 follower 都保存了所有的 proposal、所有的 follower 都处理了所有的消息,通过以上策略,能保证已经被处理的消息不会丢。
情况二的出现场景
当 leader 接收到消息请求生成 proposal 后就挂了,其他 follower 并没有收到此 proposal,因此经过恢复模式重新选了 leader 后,这条消息是被跳过的,此时,之前挂了的 leader 重新启动并注册成了 follower,他保留了被跳过消息的 proposal 状态,与整个系统的状态是不一致的,所以需要将其删除。
在 zookeeper 集群中数据副本的传递策略就是采用的广播模式,Zab 协议中的 leader 等待 follower 的 ack 反馈,只要半数以上的 follower 成功反馈就好,不需要收到全部的 follower 反馈。
具体步骤如下:
都读到这里了,来个 点赞、评论、关注、收藏 吧!
文章作者:IT王小二 首发地址:https://www.itwxe.com/posts/2c8e19cc/ 版权声明:文章内容遵循 署名-非商业性使用-禁止演绎 4.0 国际 进行许可,转载请在文章页面明显位置给出作者与原文链接。
以上是大佬教程为你收集整理的ZooKeeper集群解析全部内容,希望文章能够帮你解决ZooKeeper集群解析所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。