zookeeper原理，与集群部署

Zookeeper集群部署 是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操做。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper提供了什么？ 1)文件系统 2)通知机制 Zookeeper文件系统 每一个子目录项如 NameService 都被称做为znode，和文件系统同样，咱们可以自由的增长、删除znode，在一个znode下增长、删除子znode，惟一的不一样在于znode是能够存储数据的。 有四种类型的znode： 一、PERSISTENT-持久化目录节点 客户端与zookeeper断开链接后，该节点依旧存在 二、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开链接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 三、EPHEMERAL-临时目录节点 客户端与zookeeper断开链接后，该节点被删除 四、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开链接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 Zookeeper通知机制 客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增长删除）时，zookeeper会通知客户端。 Zookeeper作了什么？ 1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理 Zookeeper命名服务 在zookeeper的文件系统里建立一个目录，即有惟一的path。在咱们使用tborg没法肯定上游程序的部署机器时便可与下游程序约定好path，经过path即能互相探索发现。 Zookeeper的配置管理 程序老是须要配置的，若是程序分散部署在多台机器上，要逐个改变配置就变得困难。如今把这些配置所有放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，而后全部相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每一个应用程序就会收到 Zookeeper 的通知，而后从 Zookeeper 获取新的配置信息应用到系统中就好 Zookeeper集群管理 所谓集群管理无在意两点：是否有机器退出和加入、选举master。 对于第一点，全部机器约定在父目录GroupMembers下建立临时目录节点，而后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的链接断开，其所建立的临时目录节点被删除，全部其余机器都收到通知：某个兄弟目录被删除，因而，全部人都知道：它上船了。 新机器加入也是相似，全部机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，咱们稍微改变一下，全部机器建立临时顺序编号目录节点，每次选取编号最小的机器做为master就好。 Zookeeper分布式锁 有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务能够分为两类，一个是保持独占，另外一个是控制时序。 对于第一类，咱们将zookeeper上的一个znode看做是一把锁，经过createznode的方式来实现。全部客户端都去建立 /distribute_lock 节点，最终成功建立的那个客户端也即拥有了这把锁。用完删除掉本身建立的distribute_lock 节点就释放出锁。 对于第二类， /distribute_lock 已经预先存在，全部客户端在它下面建立临时顺序编号目录节点，和选master同样，编号最小的得到锁，用完删除，依次方便。

Zookeeper队列管理 两种类型的队列： 一、同步队列，当一个队列的成员都聚齐时，这个队列才可用，不然一直等待全部成员到达。 二、队列按照 FIFO 方式进行入队和出队操做。 第一类，在约定目录下建立临时目录节点，监听节点数目是不是咱们要求的数目。 第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。 分布式与数据复制 Zookeeper做为一个集群提供一致的数据服务，天然，它要在全部机器间作数据复制。数据复制的好处： 一、容错：一个节点出错，不致于让整个系统中止工做，别的节点能够接管它的工做； 二、提升系统的扩展能力 ：把负载分布到多个节点上，或者增长节点来提升系统的负载能力；

三、提升性能：让客户端本地访问就近的节点，提升用户访问速度。 从客户端读写访问的透明度来看，数据复制集群系统分下面两种： 一、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，能够读取任何一个节点。这种状况下客户端须要对读与写进行区别，俗称读写分离； 二、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读同样。这种状况下，客户端对集群节点的角色与变化透明。 对zookeeper来讲，它采用的方式是写任意。经过增长机器，它的读吞吐能力和响应能力扩展性很是好，而写，随着机器的增多吞吐能力确定降低（这也是它创建observer的缘由），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，仍是当即复制快速响应。 Zookeeper角色描述

Zookeeper与客户端

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前面。 Zookeeper工做原理 Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫作Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和Server具备相同的系统状态。 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。全部的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。 Zookeeper 下 Server工做状态 每一个Server在工做过程当中有三种状态： LOOKING：当前Server不知道leader是谁，正在搜寻 LEADING：当前Server即为选举出来的leader FOLLOWING：leader已经选举出来，当前Server与之同步 Zookeeper选主流程(basic paxos) 当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会记录事务日志并按期进行快照，方便在恢复时进行状态恢复。选主的具体流程图所示：

Zookeeper选主流程（fast paxos） fast paxos流程是在选举过程当中，某Server首先向全部Server提议本身要成为leader，当其它Server收到提议之后，解决epoch和 zxid的冲突，并接受对方的提议，而后向对方发送接受提议完成的消息，重复这个流程，最后必定能选举出Leader。

Zookeeper同步流程 选完Leader之后，zk就进入状态同步过程。

1. Leader等待server链接； 2 .Follower链接leader，将最大的zxid发送给leader； 3 .Leader根据follower的zxid肯定同步点； 4 .完成同步后通知follower 已经成为uptodate状态； 5 .Follower收到uptodate消息后，又能够从新接受client的请求进行服务了。

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

Zookeeper工做流程-Follower Follower主要有四个功能： 1.向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）； 2.接收Leader消息并进行处理； 3.接收Client的请求，若是为写请求，发送给Leader进行投票； 4.返回Client结果。 Follower的消息循环处理以下几种来自Leader的消息： 1 .PING消息： 心跳消息； 2 .PROPOSAL消息：Leader发起的提案，要求Follower投票； 3 .COMMIT消息：服务器端最新一次提案的信息； 4 .UPTODATE消息：代表同步完成； 5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session仍是容许其接受消息； 6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制获得最新的更新。

3个同时运行，将zookeeper复制两份， 修改conf/zoo.cfg文件内容 每一个zookeeper指定本身的目录 dataDir=D:/ubuntu-storm/workspace/zookeeper-2/data dataLogDir=D:/ubuntu-storm/workspace/zookeeper-2/logs 因为在同一台机器上，因此各个zoo.cfg下修改clientport，不一样机器则不需修改端口。 clientPort=2181 clientPort=2182 clientPort=2180 本地集群添加以下，为通讯序列，远程集群修改ip地址便可。每一个zoo.cfg内容同样。 server.1=192.168.220.128:2888:3888 server.2=192.168.220.128:4888:5888 server.3=192.168.220.128:6888:7888 在对应文件夹D:\ubuntu-storm\workspace\zookeeper-1\data\创建一个文本文件命名为myid，内容就为对应的zoo.cfg里server.后数字，1就写1，2就写2，3就写3.否则会报错。 配置成功后启动zookeeper服务。 进入到bin目录，而且启动zkServer.cmd 启动后jps能够看到QuorumPeerMain的进程 jps –v –l 动客户端链接zkclint.cmd -server 127.0.0.1:2181 zkclint.cmd -server 127.0.0.1:2182 zkclint.cmd -server 127.0.0.1:2180 必定要加上-server参数，否则会报错。