ZooKeeper的基本概念（二）
第一篇博文，我们对Zookeeper有了一个简单的认识，而且比较浅显，易懂，这篇博文，我们了解它的基本概念，如下图所示：
了解它的基本概念，有助于我们后面的学习，虽然今天的文章都是概念性质的内容，但是意义重大。
一、集群角色：
Zookeeper集群通常有三种角色：Leader，Follower，Observer。
| 角色 | 描述 |
|---|---|
| Leader服务器 | 整个Zookeeper集群工作机制中的核心 ，不接受client的请求，主要负责进行投票的发起和决议，更新系统状态。 |
| Follower服务器 | Zookeeper集群状态的跟随者，用于接受客户请求并向客户端返回结果，参与leader发起的投票。 |
| ObServer服务器 | 充当一个观察者的角色，ObServer可以接收客户端连接，将写请求转发leader节点。但ObServer不参加投票过程，只同步leader的状态。ObServer的目的是为了扩展系统，提高读取速度。 |
系统模型如图所示：
二、会话：
会话是指客户端和ZooKeeper服务器的连接，ZooKeeper中的会话叫Session，客户端靠与服务器建立一个TCP的长连接来维持一个Session，客户端在启动的时候首先会与服务器建立一个TCP连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能向Zookeeper服务器发送请求并获得响应。
三、数据节点：
Zookeeper中的节点有两类：
1. 集群中的一台机器成为一个节点
2. 数据模型中的数据单元Znode，分为持久节点和临时节点
Zookeeper的数据模型是一棵树，树的节点就是Znode，Znode中可以保存信息。
如下图所示：
ZK大致数据结构跟上图是一致的，如上图所示这个图就像一棵树，这个树有个根节点，然后其下有些子节点，然后每个子节点其下又可以有子节点，大多数的开发就是跟zk的这些数据节点打交道，来读写这些数据节点，来完成任务。
与传统文件系统不同的是，ZooKeeper中的数据保存在内存中，实现了分布式同步服务的高吞吐和低延迟。
在上图示例的ZooKeeper的数据模型中，有如下要点：
- 每个节点（ZNode）中存储的是同步相关的数据（这是ZooKeeper设计的初衷，数据量很小，大概B到KB量级），例如状态信息、配置内容、位置信息等。
- 一个ZNode维护了一个状态结构，该结构包括：版本号、ACL变更、时间戳。每次ZNode数据发生变化，版本号都会递增，这样客户端的读请求可以基于版本号来检索状态相关数据。
- 每个ZNode都有一个ACL，用来限制是否可以访问该ZNode。
- 在一个命名空间中，对ZNode上存储的数据执行读和写请求操作都是原子的。
- 客户端可以在一个ZNode上设置一个监视器（Watch），如果该ZNode数据发生变更，ZooKeeper会通知客户端，从而触发监视器中实现的逻辑的执行。
- 每个客户端与ZooKeeper连接，便建立了一次会话（Session），会话过程中，可能发生CONNECTING、CONNECTED和CLOSED三种状态。
- ZooKeeper支持临时节点（Ephemeral Nodes）的概念，它是与ZooKeeper中的会话（Session）相关的，如果连接断开，则该节点被删除。
四、版本：
ZK中的版本，是用来记录节点数据或者是节点的子节点列表或者是权限信息的修改次数，注意是这里是修改次数。如果一个节点的version是1，那就代表说这个节点从创建以来被修改了一次，那么这个版本怎么用呢，典型的我们可以利用版本来实现分布式的锁服务。我们知道在数据库中，一般有两种锁，一种是悲观锁一种是乐观锁。
悲观锁
悲观锁又叫悲观并发锁，是数据库中一种非常严格的锁策略，具有强烈的排他性，能够避免不同事务对同一数据并发更新造成的数据不一致性，在上一个事务没有完成之前，下一个事务不能访问相同的资源，适合数据更新竞争非常激烈的场景。
乐观锁
相比悲观锁，乐观锁使用的场景会更多，悲观锁认为事务访问相同数据的时候一定会出现相互的干扰，所以简单粗暴的使用排他访问的方式，而乐观锁认为不同事务访问相同资源是很少出现相互干扰的情况，因此在事务处理期间不需要进行并发控制，当然乐观锁也是锁，它还是会有并发的控制！对于数据库我们通常的做法是在每个表中增加一个version版本字段，事务修改数据之前先读出数据，当然版号也顺势读取出来，然后把这个读取出来的版本号加入到更新语句的条件中，比如，读取出来的版本号是1,我们修改数据的语句可以这样写，update 某某表 set 字段一=某某值where id=1 and version=1，那如果更新失败了说明以后其他事务已经修改过数据了，那系统需要抛出异常给客户端，让客户端自行处理，客户端可以选择重试。锁，ZK中版本有类似的作用。
ZK的版本类型有三种：version cversion aversion
| 版本类型 | 说明 |
|---|---|
| version | 当前数据节点数据内容的版本号 |
| cversion | 当前数据节点子节点的版本号 |
| aversion | 当前数据节点ACL变更版本号 |
五、watcher（事件监听器）：
watcherWatcher我们可以理解为他是一个事件监听器。
ZooKeeper允许用户在指定节点上注册一些watcher,当数据节点发生变化的时候，Zookeeper服务器会把这个变化的通知发送给感兴趣的客户端。
两个客户端都在zookeeper集群中注册了watcher（事件监听器），那么当zk中的节点数据发生变化的时候，zk会把这一变化的通知发送给客户端，当客户端收到这个变化通知的时候，它可以再回到zk中，去取得这个数据的详细信息。
六、ACL权限控制：
ACL是Access Control Lists 的简写， ZooKeeper采用ACL策略来进行权限控制，有以下权限：
1. CREATE:创建子节点的权限
2. READ:获取节点数据和子节点列表的权限
3. WRITE:更新节点数据的权限
4. DELETE:删除子节点的权限
5. ADMIN:设置节点ACL的权限
上面的权限有点类似我们信息系统的权限管理，我们在开发系统的时候一般也会对数据做这些权限管理，一个zk集群可能会服务很多的业务，尤其是一些大公司，zk集群的节点中会保存重要的信息，那么这些信息通常只能对一部分的访问者开放，通过acl我们可以对某些节点的访问进行授权，从而来保证数据的安全。
下篇博文我们搭建zookeeper集群。