ZooKeeper术语概念

一：Zookeeper的设计目标

 

-->Zookeeper致力于提供一个高性能，高可用，且具有严格的顺序访问控制能力（主要是写操作的严格顺行性）的分布式协调服务。

-->高性能使得Zookeeper能够应用于那些对系统吞吐有明确要求的大型分布式系统中。

-->高可用使得分布式的单点问题得到很好的解决，而严格的顺序访问控制使得客户端能够基于Zookeeper实现一些复杂的同步原语

 

［1］目标一：简单的数据模型

  -->树形结构的数据模型

  -->整棵树形结构的数据存储在内存中

 

［2］目标二：可以构建集群

  -->>=3的奇数台机器构建成一个zookeeper集群

  -->半数以上的机器节点正常运行，就可以对外提供正常的服务。

  -->客户端可以和zk集群中的任意一台建立tcp连接，与其中一台断连，立马会连接到zk集群中另一台服务器节点

 

［3］目标三：顺序访问

  -->对于来自客户端的每个更新（写操作）请求，zk集群服务都会分配一个全局唯一的递增编号，这个编号反应了所有事物操作的先后顺序

 

［4］高性能

  -->zk集群将全量数据存储在内存中，并直接服务于客户端所有非事务请求。（性能高）

  -->因此它尤其适用于以读操作为主的应用场景。

 

二：Zookeeper集群中的节点

-->通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式就是Master/Slave模式（主备模式）

-->而Zookeeper中，没有沿用Master/Slave概念，而是引用Leader,Follower,Observer三种角色

 

［1］Master/Slave模式

  -->在这种模式中，我们把能够处理所有写操作的机器成为Master机器，

  -->把所有通过异步复制方式获取最新数据，并提供读服务的机器称之为Slave机器。

［2］Leader,Follower,Observer模式

  -->Leader服务器为客户端提供读和写的服务

  -->Follower,Observer服务器只能提供读服务

  -->Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略。因此Observer可以在不影响写性能的情况下提升集群的读性能

 

 

三：zookeeper的基本概念
介绍Zookeeper的几个核心概念，这些概念贯穿于本书之后对ZooKeeper更深入的讲解，因此有必要预先了解这些概念。

●集群角色
一：集群角色  
        通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式就是Master/Slave模式（主备模式）。在这种模式中，我们把能够处理所有写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为Salve机器。
        而在ZooKeeper中，这些概念就被颠覆了。它没有沿用传统的Master/Slave概念，而是引入Leader,Follower和Observer三种角色。ZooKeeper集群中的所有机器通过一个Leader选举过程来选定一台被称为“Leader”的机器，Leader服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和Observer.Follower和Observer都能够提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略。因此Observer可以在不影响写性能的情况下提升集群的读性能。

--->Leader
        (1)Leader服务器是整个Zookeeper集群工作机制的核心
--->Follower
        (1)Follower服务器是Zookeeper集群状态的跟随者
--->Observer
       (1)Observer服务器充当一个观察者的角色
--->两种设计模式
        （1）Leader，Follower设计模式
        （2）Observer观察者设计模式


二：会话   
--->会话是指客户端和ZooKeeper服务器的连接。Zookeeper中的会话叫Session,客户端与服务器建立一个TCP的长连接来维持一个Session，客户端在启动的时候首先会与服务器建立一个TCP连接，通过这个连接，客户端 能够通过心跳检测与服务器保持有效会话，也能向ZK集群服务器发送请求并获得响应。    
--->ZooKeeper对外的服务端口默认是2181
--->通过TCP链接，客户端能够通过心跳检测与服务器保持有效会话，也能够向ZK集群发送请求并接受响应，同时还能够通过该链接接受来自服务器的Watch事件通知。
--->Session的sessionTimeout来设置一个客户端会话的超时时间。当由于服务器压力太大，网络故障或是客户端主动断开链接等各种原因导致客户端链接断开时，只要在sessionTimeout规定的时间内能够重新链接上集群中任意一台服务器，那么之前创建的会话仍然有效。

三：数据节点
--->ZooKeeper集群中有两类节点
--->一种节点：集群中的一台机器称之为一个节点，称为机器节点。
--->另一种节点：数据模型中的数据单元Znode,又分为持久节点和临时节点。
         ●持久节点
         ●临时节点
--->Zookeeper的数据模型是一棵树，树的节点就是Znode,Znode中可以保存信息。（数据内容和一系列属性信息）
--->Zookeeper的数据模型
--->持久节点：一旦这个ZNode被创建了，除非主动进行ZNode的删除操作，否则这个ZNode将一直保存在ZooKeeper上。
--->临时节点：它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被删除。
--->Zookeeper还允许用户为每个节点添加一个特殊的属性，SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建时，ZooKeeper会自动在其节点名字后面加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。




四：版本
--->版本用来寄来记录节点数据，或者节点的子节点列表，或者是权限信息的修改次数
--->版本类型和说明，对于ZNode，Zookeeper都会为其维护一个叫做Stat的数据结构
     ●  version(当前数据节点数据内容的版本号)
     ●  cversion(当前数据节点子节点的版本号)
     ●  aversion(当前数据节点ACL变更版本号)
--->利用版本来实现分布式的锁服务
--->锁分为悲观锁和乐观锁
悲观锁：又叫悲观并发锁，是数据库中一种非常严格的锁策略，具有强烈的排它性，能够避免不同事务对同一数据并发更新造成的数据不一致性，在上一个事务没有完成之前，下一个事务不能访问相同的资源，适合数据更新竞争非常激烈的场景

乐观锁：相比悲观锁，乐观锁使用场景更多，悲观锁认为事务访问相同数据的时候一定会出现相互干扰，所以简单粗暴的使用排它访问方式，而乐观锁认为不同事务访问相同资源是很少出现相互干扰的情况，因此在事务处理期间不需要进行并发控制，当然
乐观锁也是锁，它还是会有并发控制。对于数据库我们通常的做法是在每个表中增加一个version的版本字段，事务修改数据前先读取数据，当然版本号也顺势读取出来，然后把这个读取出来的版本号加入到更新语句的条件中，比如，读取出来的版本号是1,我们修改数据的语句可以这样写，update某某表 set  字段=某某 where id=某某 and version=1.那么如果更新失败了说明当时并发情况下已经有其他事务对数据已经修改过了，那么系统需要抛出错误给客户端，让客户端自行处理，客户端可以选择重试。

五：watcher  
--->事件监听器。
--->Zookeeper集群允许用户在指定的节点上注册Watcher(事件监听器),当数据节点变化的时候，Zookeeper服务器会把这个变化的通知发送给感兴趣的客户端。客户端收到这个变化通知，可以再回到Zookeeper中去取得数据的详细信息。



六：ACL权限控制
--->ACL是Access Control Lists的简写，Zookeeper采用ACL策略来进行权限控制
--->ACL拥有以下五种权限类型
        ●CREATE:创建子节点的权限
        ●READ：获取节点数据和子节点列表的权限
        ●WRITE：更新节点数据的权限
        ●DELETE：删除子节点的权限
        ●ADMIN：设置节点ACL的权限