Hadoop之Zookeeper

Matrix70

已于 2023-12-09 13:13:04 修改

阅读量255

点赞数

分类专栏： Hadoop 文章标签： hadoop java-zookeeper zookeeper

于 2023-06-16 14:29:27 首次发布

本文为博主原创文章，未经博主允许，不得转载！！

本文链接：https://blog.csdn.net/qq_52128187/article/details/131246326

版权

Hadoop 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

Hadoop 之 Zookeeper

zookeeper 台数

1n + 1 (奇数台zookeeper)
- 防止由脑裂造成的集群不可用。
- 在容错能力相同的情况下，奇数台更节省资源。
端口号
- 1181：对client端提供服务
- 3888：选举leader使用
- 1888：集群内机器通讯使用（Leader监听此端口）

zookeeper 算法

ZooKeeper是以Fast Paxos算法为基础的，
老版本是以Paxos算法为基础，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。

zookeeper 角色

领导者（leader），负责进行投票的发起和决议，更新系统状态（数据同步），发送心跳。事务请求唯一调度者和处理者，保证集群事务处理的顺序性
学习者（learner），包括跟随者（follower）和观察者（observer）。
- 跟随者（follower），用于接受客户端请求、向客户端返回结果，在选主过程中参与投票。收到写事务请求直接转发给Leader
- 因为我们就三台zk所有这个角色就被忽略了，可以接受客户端请求，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。
1）leader失效后会在follower中重新选举新的leader

1）每个follower都和leader有连接，接受leader的数据更新操作

3）客户端可以连接到每个server，每个server的数据完全相同(强一致性)

4）每个节点的服务Server，记录事务日志和快照到持久存

Zookeeper 工作原理

ZAB协议的全称是ZooKeeper Atomic Broadcast（ZooKeeper原子消息广播协议）。ZAB协议是一种特别为ZooKeeper设计的崩溃可恢复的原子消息广播算法。+
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。
- 恢复模式：
  
  当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
- 广播模式：
  
  一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。
- ZooKeeper的广播状态一直到Leader崩溃了或者Leader失去了大部分的Followers支持。

Zookeeper 监听原理

选举机制

半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

Zookeeper的选举机制

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

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

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

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

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

在选举的过程还会涉及到轮次和 zxid

1.1.7 Zookeeper 读写流程

写数据流程
- 在Client向Follwer 或 Observer 发出一个写的请求；
- Follwer 或 Observer 把请求发送给Leader；
- Leader接收到以后向所有follower发起提案；
- Follwer收到提案后执行写操作，然后把操作结果发送给Leader；
- 当半数以上follower返回提案结果后，leader会commit该提议，通知其他Follower 和 Observer 同步信息；
- Follwer 或Observer把请求结果返回给Client
读数据流程
- 1）在Client向Follwer 或 Observer 发出一个读的请求；
- 1）Follwer 或 Observer 把请求结果返回给Client；

1.1.8 Zookeeper 特点和节点类型

最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的特性；

可靠性：具有简单、健壮、良好的性能，如果消息被某一台服务器接受，那么它将被所有的服务器接受；

实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口；

等待无关(wait-free)：慢的或者失效的client，不得干预快速的client的请求，使得每个client都能有效的等待；

原子性：更新只能成功或者失败，没有中间状态；

顺序性：按照客户端发送请求的顺序更新数据(队列)；

面试题
- 讲一讲什么是CAP法则？Zookeeper符合了这个法则的哪两个？
  
  CAP法则：强一致性、高可用性、分区容错性；
  
  指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得
- Zookeeper符合强一致性、高可用性！

临时节点和永久节点存在的意义，就是不让树状结构太大，影响同步速度