Hadoop==zookeeper

Posted 2020-12-31 dsjxb

Zookeeper

每一个专业的技术总可以在生活中找到相应的实例，就比如说zookeeper，攘其外必先安其内就很好的解释了zookeeper，Hadoop集群的组件中的很多在学习的时候都会觉得每一个都不稳定，都会出现这样那样的问题，会常常听到的一个词语就是高可用，在zookeeper的官方定义的时候在集群出现故障到解决故障正常执行的间隔时间小于200ms，在我们看来就是整个集群一直可用的错觉

我们以HDFS为例子先解释一下zookeeper，在开机时，两个namenode只有一个处于存活状态，每一个namenode伴随着有一个zkfc存在，zkfc一边连接namenode，另一边是zookeeper集群，当开机后，zkfc会争先去zookeeper中创建一个节点，谁先创建就可以启动并创建一个节点进行监控、注册等，节点的变化会产生一个事件，当一个namenode出现异常挂掉之后会产生一个事件，事件会向节点去注册，然后节点会回调存活的namenode并启动，挂掉的namenode处于等待状态，所以说zookeeper就是一个协调服务

Zookeeper的构成

领导者（leader）	进行投票的发起和决议，更新系统状态
学习者 （leaener）	跟随者 （follower）	接受客户端的请求并返回结果，选举过程中参与投票
	观察者 （observer）	接收客户端的连接，将写请求转发给leader节点，不参与投票，只同步leader的状态
客户端（Client）	请求发起方

Leader主要有三个功能：

1 .恢复数据；

2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

Observer的目的是为了扩展系统，提高读取速度

Follower主要有四个功能：

1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

2 .接收Leader消息并进行处理；

3 .接收Client的请求，如果为写请求，发送给Leader进行投票；

4 .返回Client结果。

Zookeeper 的特性：

单一视图 为客户展现同一个视图，即使因为挂机或者其他原因造成版本低等现象，但是当重新连接之后数据版本等信息会进行更新，最终达到一致性的特点

可靠性 如果消息被一台服务器接受，那么它将被所有的服务器接收

实时性 不能保证两个客户端同时得到刚更新的数据

独立性 各个Client之间互不干预

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

顺序性 所有Server，同一消息发布顺序一致

Zookeeper的基本运行流程：

 

 

 

Client将一条请求写入到zookeeper集群中

Follower将请求转发给leader，然后leader将请求转发给集群中的节点，投票表决

因为zookeeper集群的原子性，所以会有两个过程，首先投票表决是否可以进行这个请求操作，如果过半的节点同意进行这个请求，那么，进行下一步，将请求发送到各个节点上进行处理，这也就保证了只会有成功和失败两种状态，不会出现中间状态

当过半的节点（不同意的节点可能因为挂机或者其他原因失去联系）同意并且执行完毕之后，zookeeper会恢复所有的节点之间的通信，这个时候会将数据进行同步处理，达到整个集群中的数据的一致性

Zookeeper的核心是原子广播，（但client发送请求将hello写入到集群中时，节点会投票选择是否同意这个请求，当同意之后，leader会将hello更新到所有的节点上），保证了各个server之间的同步，实现协议是zab协议

Zab协议包括

恢复模式：leader挂掉了，需要重新选举leader或者当服务刚刚启动还没有产生leader的时候

广播模式：产生leader之后，集群处于主从结构之后的模式

而对于为产生leader之前的恢复模式，他在选举leader的时候有一套他自己的算法机制

Zookeeper内部选举算法：

当客户端提交请求之后 或者当集群刚启动的时候，zookeeper会进行投票的行为，投票选举出来在大家之中最适合成为领导者的那个节点，让他领导其余的节点，投票不是一轮既可以完成的，因为总有得票数相同的节点出现，素以需要进行多轮投票，直到选出那唯一的一个，，在每一轮投票结束之后会将投票信息发送到所有的节点上，这些信息包括：服务器ID，数据ID，逻辑时钟，选举状态（LOOKING，竞选状态。 FOLLOWING，随从状态，同步leader状态，参与投票。OBSERVING，观察状态,同步leader状态，不参与投票。LEADING，领导者状态)在每一轮的投票中不断的更新这些数据，最后可以得到一个的票数最多的节点，他就是众望所归的leader

 

 

具体的投票执行流程：

(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。

　　(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为3，Server3的ZXID为2；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。

　　(3) 接收来自各个服务器的投票。与启动时过程相同。

　　(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。

　　(5) 统计投票。与启动时过程相同。

　　(6) 改变服务器的状态。与启动时过程相同