一步一步学ZooKeeper-ZooKeeper初了解

角色

         Zookeeper中的角色主要有以下三类

         领导者(Leader)

                   领导者负责进行投票的发起和决议,更新系统状态

         学习者(Learner)

                   跟随者(Follwer)

                            Follwer用于接收客户请求并向客户端返回结果,在选主过程中参与投票

                   观察者(ObServer)

ObServer可以接收客户端连接,将写请求转发给leader节点。但ObServer不参加投票过程,只同步leader的状态。ObServer的目的是为了扩展系统,提高读取速度。

         客户端(Client)

                   请求发起方

Zookeeper的工作原理

         Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步之后,恢复模式就结束了,状态同步保证了leader和Server具有相同的系统状态。

         为了保证事务的顺序一致性,zookeeper采用了递增事务id号(zxid)来标识事务,所有的提议(proposal)都在被提出的时候加上了zxid。其中zxid是一个64位的数组,它高32位是epoch用来表示leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于哪个leader的统治时期,低32位用于递增技数。

每个Server在工作过程中有三种状态:

         LOOKING:当前Server不知道leader是谁,正在搜寻。

         LEADING:当前Server即为选举出来的leader。

         FOLLOWING:leader已经选举出来,当前Server与之同步。

选主流程

         当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

         Fast paxos流程是在选举过程中,某Server首先向所有的Server提议自己要成为leader,当其它Server收到提议以后,解决epoch和zxid的冲突,并接收对方的提议,然后向对方发送接受提议完成的消息,重复这个流程,最后一定能选出Leader。

    设计目的

  1、  最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。

  2、  可靠性:具有简单、健壮、良好的性能,如果消息m被一台服务器接收,那么它将被所有服务器接受。

  3、  实时性:ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效信息,但由于网络延时等原因,ZooKeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口

  4、  等待无关:慢的或者失效的client不得干预快速的client请求,使得每个client都能有效的等待。

  5、  原子性:更新只能成功或者失败,没有中间状态。

  6、  顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将消息b前被发布;偏序是指如果一个消息b在消息a后备同一个发送者发布,a必将排在b前面。

 

Zookeeper系统架构

        

 

         Zookeeper架构图中我们需要掌握

  1、  Zookeeper分为服务器端和客户端,客户端可以连接到整个Zookeeper服务的任意服务器上(除非leaderServers参数显示设置,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 Broadcast阶段

  a)         集群中将选举一个leader,其他的机器则称为follower,所有的写操作都被传送给leader,并通过broadcast将所有的更新告诉给follower。

  b)         当leader崩溃或者leader失去大多数follower时,需要重新选举出一个新的leader,让所有的服务器都恢复到一个正确的状态。

  c)         当leader被选举出来,且大多数服务器完成了和leader的状态同步后,leadder election的过程就结束了,就将会进入到Atomic broadcast的过程。

  d)         Atomic Broadcast同步leader和follower之间的信息,保证leader和follower具有相同的系统形态。

Zookeeper的Server数目一般为奇数

         Zookeeper中Leader选举算法采用了Zab协议。Zab核心思想是当多数Server写成功,则任务数据写成功。

      容错性

  1、  如果有3个Server,则最多允许1个Server挂掉。

  2、  如果有4个Server,则同样最多允许1个Server挂掉。

  既然3个或者4个Server,同样最多允许1个Server挂掉,那么它们的可靠性是一样的,所以选择奇数个ZooKeeper Server即可,这里选择3个Server。

   防止脑裂发生

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

  1、  比如Client向ZooKeeper的Server1上写数据,发送一个写请求。

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

  3、  当Leader收到大多数Server数据写成功了,那么久说明数据写成功了,写成功之后,Leader会告诉Server1数据写成功了。

  4、  Server1会进一步通知Client数据写成功了,这是就认为整个写操作成功。

   

 

                   

posted @ 2017-08-24 17:29 一步一步学 阅读(...) 评论(...) 编辑 收藏