Zookeeper的理解

  1. Zookeeper是什么?
    Zookeeper是一个分布式,开放源代码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,它是集群的管理者,监视着急群众各个节点的状态根据节点提交的反馈进行下一步合理操作,最终,将简易的接口和性能高校、功能稳定的系统提供给用户。
  2. Zookeeper提供了什么?
    1)文件系统
    每个子目录项如NameService都被称作znode,和文件系统一样,我们能够自由的增加、删除znode,在一个znode下增加、删除子znode,唯一的不同在于znode可以存储数据的。
    有四中类型的znode:
    1.PERSISTENT-持久化目录节点
    客户端与zookeeper断开连接后,该节点依旧存在。
    2.PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
    客户端与zookeeper断开连接后,该节点依旧存在,只是zookeeper给该节点名称进行顺序编号
    3.EPHEMERAL-临时目录节点
    客户端与zookeeper断开连接后,该节点被删除。
    4.EPHEMERAL-SEQUENTIAL-临时顺序编号目录节点
    客户端与zookeeper断开连接后,该节点被删除,只是zookeeper给该节点进行顺序编号

    2)通知机制
    客户端注册监理它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,zookeeper会通知客户端。
  3. Zookeeper做了什么?
    1)命名服务
    在zookeeper的文件系统里创建一个目录,即有唯一的path,在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好的path,通过path即能互相搜索发现。
    2)配置管理
    程序总是需要配置的,如果程序分散部署在多台机器上,要逐个改变配置就变得困难,现在把这些配置全部放到zookeeper上去,保存在zookeeper的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到zookeeper的通知,然后从zookeeper获取新的配置信息应用到系统中就好。
    这里写图片描述
    3)集群管理
    所谓集群管理无非在乎两点:是否有机器加入和推出、选举master。
    对于第一点,所有机器约定在父目录GroupMembers下创建临时目录节点,然后监听父目录的子节点变化消息,一旦有机器挂掉,该机器与zookeeper的连接断开,其所创建的临时目录节点被删除,所有其他机器都收到通知:某个兄弟目录被删除,于是,所有人都知道有人上船了。

    4)分布式锁
    有了zookeeper的一致性文件系统,锁的问题变得容易,锁服务可以分为两类:保持独占、控制时序。对于第一类,我们将zookeeper上的一个znode看作是一把锁,通过createZnode的方式来实现,所有客户端都去创建disribute_lock节点,最终创建的那个客户端也拥有了这把锁。用完删除自己创建的disribute_lock节点就释放锁。对于第二类,disribute_lock已经预先存在,所有客户端在它下面创建临时顺序序号目录节点,和选master一样,编号最小的获得锁,用完删除,依次方便。

    5)队列管理
    两种类型的队列:
    同步队列,当一个队列的成员都聚齐时,这个队列才可用,否则一直等到所有成员到达。
    队列按照FIFO方式进行入队和出队操作。
    第一类,在约定目录下创建临时目录节点,监听节点数目是否是我们要求的数目。
    第二类,和分布式锁服务中的控制时序长江基本原理一致,入列有编号、出列按编号。
  4. 分布式与数据复制
    zookeeper作为一个集群提供一致的数据服务,自然它要在所有机器间所有机器做数据复制,数据复制的好处:
    容错:一个节点出错,不至于让整个系统停止工作,别的节点可以接管它的工作。
    提高系统的扩展能力:把负载分布到多个节点上,或者增加节点来提高系统的负载能力。
    提高性能:让客户端本地访问就近的节点,提高用户的访问速度。
    从客户端读写访问的透明度来看,数据复制集群系统分为下面两种:
    1.写主(WriteMaster):对数据的修改提交给指定的节点。读无限制,可以读取任何任何一个节点。这种情况下客户端需要对读写进行区别,俗称读写分离。
    2.写任意(WriteAny):对数据的修改可提交给任意的节点,跟读一样。这种情况下,客户端对集群节点的角色变化透明。
    对zookeeper来说,它采用的方式是写任意。通过增加机器,它的读吞能力和影响能力扩展性非常好,而写,随着机器的增多吞吐能力肯定下降(这也是它建立observer的原因),而响应能力则取决于具体实现方式,是延迟复制保持最终一致性,还是立即复制kuaisu快速响应。
  5. zookeeper角色描述

  6. zookeeper与客户端

  7. zookeeper设计目的
    1)最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。
    2)可靠性:具有简单、健壮、良好的性能,如果消息被推送到一台服务器接收,那么它将被所有的服务器接收。
    3)实时性:zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息,但由于网络延时等原因,zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync接口。
    4)等待无关(wait-free):慢的或者失效的client不得干预快速的client的请求,使得每个client都能有效的等待。
    5)原子性:更新只能成功或者失败,没有中间状态。
    6)顺序性:包括全局有序和偏序两种,全局有序是指如果在一台服务器上消息a在消息b之前发布,则所有的Server上消息a都将消息b之前发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。

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

  9. zookeeper下server工作状态
    每个server在工作过程中有三种状态:
    LOOKING:当前Server不知道leader是谁,正在搜寻。
    LEADING:当前Server即为选举出来的leader
    FOLLOWING:leader已经选举出来,当前Server与之同步

  10. zookeeper选主流程
    当leader崩溃或者leader是去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
    1)选举线程由当前server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的Server
    2)选举线程首先向所有Server发起一次询问
    3)选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并将这些信息存储到当次选举的投票记录中
    4)收到所有Server回复以后,就计算出zxid最大的那个server,并将这个server相关信息设置成下一次的投票的Server
    5)线程将当前zxid最大的Server设置为当前Server要推荐的leader,如果此时获胜的Server获得n/2+1的Server票数,设置当前推荐的leader为获胜的Server,将根据获胜的Server相关信息设置自己的装填,否则继续这个过程。直到leader被选举出来。通过流程分析我们可以得出,要使leader获得多数Server的支持,则Server总数必须使奇数2n+1,且存活的Server的数目不得少于n+1,每个Server启动后都会重复以上流程。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的Server还会从磁盘快照中恢复数据和会话信息,zk会记录事务日志并定期进行快照。方便在恢复时进行状态恢复,选中流程图所示:

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

  12. zookeeper同步流程
    选完leader以后,zk就进入状态同步过程:
    1)leader等待server连接。
    2)follower连接leader,将最大的zxid发送给leader
    3)leader根据follower的zxid确定同步点
    4)完成同步后follower已经成为uptodate状态
    5)follower收到uptodate消息后,又可以重新接受client的请求进行服务了

  13. zookeeper工作流程-Leader
    1)恢复数据
    2)维持与learner的心跳,接收learner请求并判断learner的请求消息类型
    3)learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根据不同的消息类型,进行不同的处理。
    PING消息是指Learner的心跳信息;
    REQUEST消息是指Follower发送的提议信息,包括写请求及同步请求;
    ACK消息是Follower的对提议的回复,超过半数的Follower通过,则commit该提议;
    REVALIDATE消息是用来延长SESSION有效时间。

  14. zookeeper工作流程-Follower
    Follower主要有四个功能:
    1)向leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息)
    2)接收leader消息并进行处理
    3)接收Client的请求,如果为写请求,发送给Leader进行投票
    4)返回Client结果
    Follower的消息循环处理如下几种来自Leader的消息:
    1)PING消息:心跳信息;
    2)PROPOSAL消息:Leader发起的提案,要求Follwer投票;
    3)COMMIT消息:服务端最新一次提案的信息;
    4)UPTODATE消息:表名同步完成;
    5)REVALIDATE消息:根据Leader的REVALIDATE结果,关闭等待revalidate的session还是允许其接收消息;
    6)SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。

猜你喜欢

转载自blog.csdn.net/P923284735/article/details/80826310