一文学会Zookeeper

最新推荐文章于 2024-09-15 23:15:27 发布

简至大道

最新推荐文章于 2024-09-15 23:15:27 发布

阅读量81

点赞数 1

分类专栏：中间件文章标签： java-zookeeper zookeeper java

又见面了，惊不惊喜，意不意外

本文链接：https://blog.csdn.net/zxyhj/article/details/126161672

版权

中间件专栏收录该内容

9 篇文章 1 订阅

订阅专栏

一文学会Zookeeper

1.Zookeeper可以做什么?

ZooKeeper 是分布式应用程序的高性能协调服务。它在一个简单的界面中公开了常用服务，例如命名、配置管理、同步和组服务，因此您不必从头开始编写它们。您可以现成地使用它来实现共识、组管理、领导者选举和存在协议。您可以根据自己的特定需求在此基础上进行构建。

2.Zookeeper四种节点类型

2.1 PERSISTENT-持久节点

除非手动删除，否则节点一直存在于 Zookeeper 上

2.2 EPHEMERAL- 临时节点

临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与 zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
2.3 PERSISTENT_SEQUENTIAL- 持久顺序节点
基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
2.4 EPHEMERAL_SEQUENTIAL- 临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

3.zookeeper的watch机制

zookeeper的watch监听机制，用于监听节点数据变化。当watch监听的数据发生变化时，通知该watch的client。

watch机制特性：

一次性触发器：客户端在Znode设置了Watch时，如果Znode内容发生改变，那么客户端就会获得Watch事件，而Watch事件一旦被触发，Znode设置的Watch事件就被取消，需要重新添加Watch事件。
发送至客户端：Watch事件是异步发送到Client。Zookeeper可以保证客户端发送过去的更新顺序是有序的。
设置watch的数据内容：Znode改变有很多种方式，例如：节点创建，节点删除，节点改变，子节点改变等等。Zookeeper维护了两个Watch列表，一个节点数据Watch列表，另一个是子节点Watch列表。getData()和exists()设置数据Watch，getChildren()设置子节点Watch。所以watch可以设置监听当前节点或子节点。

4.zookeeper的Leader选举机制

两种情况一：初始化集群时选取leader

二： leader挂了重新选取leader

第一种情况（五台服务器）

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5)服务器5启动，同4一样当小弟。

第二种情况

当集群中有结点宕机或重启会触发选举。

如果集群中仍然存在leader，直接与leader建立连接。
如果不存在leader，按照EPOCH->ZXID->SID的顺序逐个比较，大的就胜出，成为leader。即EPOCH大的胜出，如果并列再比较ZXID，如果事务id也并列再比较SID.

5.zookeeper如何保证一致性（ZAB协议）

核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式即：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将一个客户端事务请求转化成一个事务Proposal(提议）,并将该Proposa1分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

6.paxos一致性算法

paxos算法核心就是提案。1、proposer选择一个提案为N ,向半数以上的Acceptor发送编号为N的prepare请求。2、如果Acceptor收到一个编号为N的prepare请求，并且N为当前Acceptor所响应的请求中编号最大的，它就接收这个提案，并且不再接收比这个编号更小的提案了。3、如果proposer收到了半数以上Acceptor对其发出的编号为N的prepare请求响应。就会给半数以上的Acceptor发送提案的accept请求。4、如果acceptor收到一个编号为N的accept请求，如果当前acceptor没有对编号大于N的prepare请求做出响应，它就接收该提案。