简要分析ZooKeeper基本原理

最新推荐文章于 2022-03-23 12:08:38 发布

有趣的难受

最新推荐文章于 2022-03-23 12:08:38 发布

阅读量211

点赞数 1

分类专栏： Zookeeper

本文链接：https://blog.csdn.net/m0_37383866/article/details/87376857

版权

Zookeeper 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

zk挂了还能使用吗
zk 挂了还能使用，因为本地缓存。
一、ZooKeeper 基本概念

1、ZooKeeper 是什么？
ZooKeeper 是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等；它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简单示例图如下：
这里写图片描述

2、ZooKeeper设计目标：

ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。名称空间由ZooKeeper中的数据寄存器组成 - 称为znode，这些类似于文件和目录。与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

Zookeeper层次结构命名空间示意图如下：
这里写图片描述
通过这种树图结构的数据模型，很容易的查找到具体的某一个服务。

3、ZooKeeper主要特点：

1)、最终一致性：为客户端展示同一视图，这是 ZooKeeper 最重要的性能。
2)、可靠性：如果消息被一台服务器接受，那么它将被所有的服务器接受。
3)、实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4)、等待无关（wait-free）：慢的或者失效的 client 不干预快速的client的请求。
5)、原子性：更新只能成功或者失败，没有中间其它状态。
6)、顺序性：对于所有Server，同一消息发布顺序一致。

二、ZooKeeper 基本原理

1、ZooKeeper 系统架构

首先看一下 ZooKeeper 的架构图。

这里写图片描述

ZooKeeper 的架构图中我们需要了解和掌握的主要有：

（1）ZooKeeper分为服务器端（Server）和客户端（Client），客户端可以连接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。

（2）客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时，接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。

（3）上图中每一个Server代表一个安装Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）；

（4）组成ZooKeeper服务的服务器必须彼此了解。它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照，只要大多数服务器可用，ZooKeeper服务就可用；

（5）ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。

（6）Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；

（7）Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段。

a) 集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新告诉给follower。
b) 当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。
c) 当leader被选举出来，且大多数服务器完成了 和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。
d) Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具有形同的系统状态。

2、Zookeeper 角色

启动 Zookeeper 服务器集群环境后，多个 Zookeeper 服务器在工作前会选举出一个 Leader。选举出 leader 前，所有 server 不区分角色，都需要平等参与投票（ obServer 除外，不参与投票）；

选主过程完成后，存在以下几种角色：

这里写图片描述

思考：

1、为什么需要server?

①ZooKeeper 需保证高可用和强一致性;
②为了支持更多的客户端，需要增加更多的Server;
③Follower增多会导致投票阶段延迟增大，影响性能。

２、在Zookeeper 中ObServer 起到什么作用？

①ObServer 不参与投票过程，只同步 leader的状态 ;
②Observers 接受客户端的连接，并将写请求转发给 leader节点 ;
③加入更多ObServer 节点，提高伸缩性，同时还不影响吞吐率。

３、为什么在Zookeeper中Server 数目一般为奇数？

我们知道在Zookeeper中 Leader 选举算法采用了Paxos协议。Paxos核心思想是当多数 Server 写成功，则任务数据写成功。
①如果有3个Server，则最多允许1个Server 挂掉。
②如果有4个Server，则同样最多允许1个Server挂掉。
既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。

3、ZooKeeper 写数据流程

ZooKeeper 写数据的流程图如下所示。

这里写图片描述

ZooKeeper 的写数据流程主要分为以下几步：

a)、比如 Client 向 ZooKeeper 的 Server1 上写数据，发送一个写请求。

b)、如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。

c)、当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。

d)、Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。

4、ZooKeeper 组件

ZooKeeper组件显示了ZooKeeper服务的高级组件。除了请求处理器，组成ZooKeeper服务的每个服务器复制其自己的每个组件的副本。

这里写图片描述

Replicated Database是包含整个数据树的内存数据库。更新操作会记录到磁盘里以进行可恢复性，并且写操作将在放到内存数据库之前序列化到磁盘。

每个ZooKeeper服务器服务客户端。客户端连接到一个服务器以提交irequest。读取请求从每个服务器数据库的本地副本服务。更改服务状态（写入请求）的请求由协议进行处理。

作为协议协议的一部分，来自客户端的所有写请求被转发到单个服务器，称为leader。其余的ZooKeeper服务器（称为followers）从领导者接收消息提议并同意消息传递。消息层负责在失败时替换领导者，并与leader同步followers。
三、ZooKeeper 应用场景总结

1、统一命名服务

统一命名服务的命名结构图如下所示：

这里写图片描述
　
1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。
　 a）类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。
　 b）通过名称来获取资源或服务的地址，提供者等信息。
　
2、按照层次结构组织服务/应用名称。
　 a）可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。

2、配置管理

配置管理结构图如下所示：

这里写图片描述

1、分布式环境下，配置文件管理和同步是一个常见问题。
　 a）一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
　 b）对配置文件修改后，希望能够快速同步到各个节点上。
　　
2、配置管理可交由ZooKeeper实现。
　 a）可将配置信息写入ZooKeeper上的一个Znode。
　 b）各个节点监听这个Znode。
　 c）一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

3、集群管理

集群管理结构图如下所示：

这里写图片描述

1、分布式环境中，实时掌握每个节点的状态是必要的。
　　a）可根据节点实时状态做出一些调整。
　　
2、可交由ZooKeeper实现。
　　a）可将节点信息写入ZooKeeper上的一个Znode。
　　b）监听这个Znode可获取它的实时状态变化。
　　
3、典型应用
　　a）HBase中Master状态监控与选举。

4、分布式通知与协调

1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。
　　a）NameNode需知道各个Datanode的状态。
　　b）JobTracker需知道各个TaskTracker的状态。
　　
2、心跳检测机制可通过ZooKeeper来实现。

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。

5、分布式锁

处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。

分布式锁具有以下特性：

1、ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端，它们同时创建相同的Znode，但是只有一个客户端创建成功。

2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁，其它客户端只能等待。当前客户端用完这个锁后，会删除这个Znode，其它客户端再尝试创建Znode，获取分布式锁。

3、控制锁的时序。各个客户端在某个Znode下创建临时Znode，这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL，这样该Znode可掌握全局访问时序。

6、分布式队列

分布式队列分为两种：

1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
　　a）一个job由多个task组成，只有所有任务完成后，job才运行完成。
　　b）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。
　　
2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。

二、zookeeper脑裂（Split-Brain）问题

2.1、什么是脑裂？

白话点说，就是比如当你的 cluster 里面有两个结点，它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候，就会达成共识，选出其中一个作为 master。但是如果它们之间的通信出了问题，那么两个结点都会觉得现在没有 master，所以每个都把自己选举成 master。于是 cluster 里面就会有两个 master。

对于Zookeeper来说有一个很重要的问题，就是到底是根据一个什么样的情况来判断一个节点死亡down掉了。在分布式系统中这些都是有监控者来判断的，但是监控者也很难判定其他的节点的状态，唯一一个可靠的途径就是心跳，Zookeeper也是使用心跳来判断客户端是否仍然活着。

使用ZooKeeper来做master HA基本都是同样的方式，每个节点都尝试注册一个象征master的临时节点其他没有注册成功的则成为slaver，并且通过watch机制监控着master所创建的临时节点，Zookeeper通过内部心跳机制来确定master的状态，一旦master出现意外Zookeeper能很快获悉并且通知其他的slaver，其他slaver在之后作出相关反应。这样就完成了一个切换。这种模式也是比较通用的模式，基本大部分都是这样实现的，但是这里面有个很严重的问题，如果注意不到会导致短暂的时间内系统出现脑裂，因为心跳出现超时可能是master挂了，但是也可能是master，zookeeper之间网络出现了问题，也同样可能导致。这种情况就是假死，master并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样slaver中就有一个成为了master，但是原本的master并未死掉，这时候client也获得master切换的消息，但是仍然会有一些延时，zookeeper需要通讯需要一个一个通知，这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的master上去了，有的client仍然连接在老的master上如果同时有两个client需要对master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上，就会出现很严重问题。

总结：

假死：由于心跳超时（网络原因导致的）认为master死了，但其实master还存活着。
脑裂：由于假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，导致出现了两个master ，有的客户端连接到老的master 有的客户端链接到新的master。
2.2、什么原因导致的？
主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现，那就会出现上面的情况。同时，在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小，需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，数据不一致。