zookeeper工做原理以及基础概念

  ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：数据发布/发布、负载均衡、配置维护、域名服务、分布式同步、组服务等。而咱们为什么选择zookeeper，由于Zookeeper具备如下特性：

特色	说明
最终一致性	为客户端展现同一个视图，这是zookeeper里面一个很是重要的功能
可靠性	若是消息被到一台服务器接受，那么它将被全部的服务器接受。
实时性	Zookeeper不能保证两个客户端能同时获得刚更新的数据，若是须要最新数据，应该在读数据以前调用sync()接口
独立性	各个Client之间互不干预
原子性	更新只能成功或者失败，没有中间状态。
顺序性	全部Server，同一消息发布顺序一致。

1.zookeeper设计目标

 Zookeeper致力于提供一个高性能、高可用、且具备严格的顺序访问控制能力（主要是写操做的严格顺序性）的分布式协调服务，其具备以下的设计目标：

1. 简单的数据模型，Zookeeper使得分布式程序可以经过一个共享的树形结构的名字空间来进行相互协调，即Zookeeper服务器内存中的数据模型由一系列被称为ZNode的数据节点组成，Zookeeper将全量的数据存储在内存中，以此来提升服务器吞吐、减小延迟的目的。
2. 可构建集群，一个Zookeeper集群一般由一组机器构成，组成Zookeeper集群的而每台机器都会在内存中维护当前服务器状态，而且每台机器之间都相互通讯。
3. 顺序访问，对于来自客户端的每一个更新请求，Zookeeper都会分配一个全局惟一的递增编号，这个编号反映了全部事务操做的前后顺序。
4. 高性能，Zookeeper将全量数据存储在内存中，并直接服务于客户端的全部非事务请求，所以它尤为适用于以读操做为主的应用场景。

2.zookeeper架构图

zookeeper角色：

角色	描述
leader	负责进行投票的发起和决议以及更新系统状态
learner	包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程当中参与投票.Observer能够接受客户端链接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提升读取速度
client	请求发起方

其中每一个Server在工做过程当中有三种状态：

1. LOOKING：当前Server不知道leader是谁，正在搜寻
2. LEADING：当前Server即为选举出来的leader
3. FOLLOWING：leader已经选举出来，当前Server与之同步

那如何选举server leader呢？
半数经过 ，奇数选举
– 3台机器 挂一台 2>3/2
– 4台机器 挂2台 2！>4/2
具体选举流程：
» 每一个Server启动之后都询问其它的Server它要投票给谁。
» 对于其余server的询问，server每次根据本身的状态都回复本身推荐的leader的id和上一次处理事务的zxid（系统启动时每一个server都会推荐本身）
» 收到全部Server回复之后，就计算出zxid最大的哪一个Server，并将这个Server相关信息设置成下一次要投票的Server。
» 计算这过程当中得到票数最多的的sever为获胜者，若是获胜者的票数超过半数，则改server被选为leader。不然，继续这个过程，直到leader被选举出来 » leader就会开始等待server链接
» Follower链接leader，将最大的zxid发送给leader
» Leader根据follower的zxid肯定同步点
» 完成同步后通知follower 已经成为uptodate状态
» Follower收到uptodate消息后，又能够从新接受client的请求进行服务了

3.zookeeper工做原理

  Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步，实现这个机制的协议叫作Zab协议。 Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和server具备相同的系统状态。
  一旦leader已经和多数的follower进行了状态同步后，他就能够开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。 Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。
  广播模式须要保证proposal被按顺序处理，所以zk采用了递增的事务id号(zxid)来保证。全部的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
   当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式须要从新选举出一个新的leader，让全部的server都恢复到一个正确的状态。

4.Zookeeper的数据模型

»层次化的目录结构，命名符合常规文件系统规范
» 每一个节点在zookeeper中叫作znode,而且其有一个惟一的路径标识
» 节点Znode能够包含数据和子节点，可是EPHEMERAL类型的节点不能有子节点
» Znode中的数据能够有多个版本，好比某一个路径下存有多个数据版本，那么查询这个路径下的数据就须要带上版本
» 客户端应用能够在节点上设置监视器
» 节点不支持部分读写，而是一次性完整读写

5.Zookeeper的节点

» Znode有两种类型，短暂的（ephemeral）和持久的（persistent）

» Znode的类型在建立时肯定而且以后不能再修改

» 短暂znode的客户端会话结束Zookeeper的保证时，zookeeper会将该短暂znode删除，短暂znode不能够有子节点

» 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

» Znode有四种形式的目录节点

1. PERSISTENT、
2. EPHEMERAL
3. PERSISTENT_SEQUENTIAL、
4. EPHEMERAL_SEQUENTIAL

6.Zookeeper的保证

» 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
» 数据更新原子性，一次数据更新要么成功，要么失败
» 全局惟一数据视图，client不管链接到哪一个server，数据视图都是一致的
» 实时性，在必定事件范围内，client能读到最新数据

7.ACL

Zookeeper采用ACL（Access Control Lists）策略来进行权限控制，其定义了以下五种权限：

 · CREATE：建立子节点的权限。

 · READ：获取节点数据和子节点列表的权限。

 · WRITE：更新节点数据的权限。

 · DELETE：删除子节点的权限。

 · ADMIN：设置节点ACL的权限。

欢迎转载，标明出处！！