从零学习Zookeeper—Hadoop生态圈（四）

最新推荐文章于 2024-09-23 18:51:41 发布

NightFall丶

最新推荐文章于 2024-09-23 18:51:41 发布

阅读量143

点赞数

分类专栏： # zookeeper 文章标签： zookeeper hadoop

本文链接：https://blog.csdn.net/wsjslient/article/details/110950182

版权

1 篇文章 0 订阅

订阅专栏

一、特点和数据结构

a.Znode有两种类型：

b.Znode有四种形式的目录节点(默认是 persistent);

持久化目录节点(PERSISTENT)
客户端与zookeeper断开连接后该节点依旧存在;
持久化顺序编号目录节点(PERSISTENT_SEQUENTIAL)
客户端与zookeeper断开连接后该节点依旧存在只是Zookeeper给该节点名称进行顺序编号;
临时目录节点(EPHEMERAL)
客户端与zookeeper断开连接后，该节点被删除;
临时顺序编号目录节点(EPHEMERAL_SEQUENTIAL)
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号;

搭建链接：Zookeeper搭建

半数机制：集群中半数以上机器存活，集群可用。所以zookeeper 适合装在奇数台机器上；
Zookeeper虽然在配置文件中并没有指定master 和slave。但是，zookeeper工作时，是有一个节点为leader，其他则为follower，Leader是通过内部的选举机制临时产生的；
leader 的选择机制，zookeeper 提供了三种方式；
- LeaderElection
- AuthFastLeaderElection
- FastLeaderElection

eg.(以FastLeaderElection举例）:

假设有五台服务器组成的zookeeper 集群，它们的id 从1-5，按编号依次启动，它们的选择举过程如下：

服务器1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1 的状态一直属于Looking(选举状态)；
服务器2启动，给自己投票，同时与之前启动的服务器1 交换结果，由于服务器2 的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING；
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器 3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟；
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟；
服务器5启动，后面的逻辑同服务器4成为小弟；

Serverid：服务器 ID
比如有三台服务器，编号分别是1,2,3；编号越大在选择算法中的权重越大；
Zxid：数据 ID
服务器中存放的最大数据ID；值越大说明数据越新，在选举算法中数据越新权重越大；
Epoch：逻辑时钟
或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的；每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断；
Server状态：选举状态
- LOOKING，竞选状态；
- FOLLOWING，随从状态，同步 leader状态，参与投票；
- OBSERVING，观察状态 ,同步 leader状态，不参与投票；
- LEADING，领导者状态；