Zookeeper(二)原理知识,paxos-zab原子广播协议,ZK集群选举Leader的过程,JAVA客户端API使用及说明

最新推荐文章于 2023-10-24 20:25:53 发布

君陌先生

最新推荐文章于 2023-10-24 20:25:53 发布

阅读量580

点赞数

分类专栏： zookeeper 文章标签：分布式 zookeeper java

本文链接：https://blog.csdn.net/weixin_42008012/article/details/106865921

版权

本文详细介绍了Zookeeper的Paxos简化版ZAB协议，Zookeeper集群的选举过程，以及Java客户端API的使用注意事项。Zookeeper通过ZAB协议确保分布式一致性，其选举机制确保快速恢复和高可用性。在Java API使用时，需注意设置合适的sessionTimeout以避免意外断连。

摘要由CSDN通过智能技术生成

概览

Zookeeper用于分布式协调,有这几个特点:扩展性,可靠性,时序性;快速恢复(选举leader)

Zookeeper集群的通信模型

在虚拟机中搭建了四个节点的ZK集群,观察每个节点的2888和3888端口:
netstat -natp | egrep ‘(2888|3888)’
可以得到这个关系图:
所有的从节点,连接数和被链接数时相等的;
leader要通过3888连接所有follower,同时通过2888被所有follower连接
3888是选leader时投票用的端口;
2888是leader和follower沟通的端口
在这里插入图片描述

扩展性

在这里插入图片描述

可靠性

这块主要是其分布式的特性
Paxos https://www.douban.com/note/208430424/
ZK实现了精简版的Paxos协议—ZAB协议
在这里插入图片描述

Paxos 和 Zookeeper

概念

百度搜索: paxos site:douban.com https://www.douban.com/note/208430424/
http://zh.wikipedia.org/zh-cn/Paxos

Paxos是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

Paxos描述了这样一个场景，有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效。每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。

通过"每个议员只会同意大于当前编号的提议"这个规则,可以解决两个提议间的冲突.

两阶段提交(部分解决消息传递问题,比如网络延迟):

有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。
发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。

ZK Server 和 Paxos的对应关系

小岛(Island)——ZK Server Cluster
议员(Senator)——ZK Server
提议(Proposal)——ZNode Change(Create/Delete/SetData…)
提议编号(PID)——Zxid(ZooKeeper Transaction Id)
正式法令——所有ZNode及其数据

貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。
如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。

总统——ZK Server Leader

总统(leader)的选举

这个直接在下面看ZK集群怎么选举leader的…

总统的作用?

情况一(读操作):
屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。

情况二(写操作):
屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将问题反映给了总统，总统询问所有议员的意见，多数议员表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。

情况三(无主模式,服务不可用,专心选举):
总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。