zookeeper知识点

znode(原子读写操作):

zoo.cfg:

tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。

dataDir：是Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。

clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

 

server角色:

启动zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个Leader。选举出leader前，所有server不区分角色，都需要平等参与投票（observer除外，不参与投票）；选主过程完成后，存在以下几种角色：

leader：领导者，可以接受client请求，也接收其他server转发的写请求，负责更新系统状态。

follower：可以接收client请求，如果是写请求将转发给leader来更新系统状态。

observer：同follower，唯一区别就是不参与选主过程。

 

session机制：

client连接server成功后，server赋予该client一个sessionid，client需要不断发送心跳维持session有效，在session有效期内，可以使用Zookeeper提供的API进行操作。如果因为某些原因导致client无法正常发送心跳，在超时时长后，server会判断该client的session失效，此时client发送的任何操作都会被拒绝，并触发ExpiredException异常，此时KeeperState处于Expired状态。

但client有自动重连server的机制，如果client的心跳无法正常连接server，会在session超时前尝试连接其他server，连接成功后可以继续操作。

 

一致性：

zookeeper是一种提供强一致性的服务，在分区容错性和可用性上做了一定折中，这和CAP理论是吻合的原因：

1. 假设有2n+1个server，在同步流程中，leader向follower同步数据，当同步完成的follower数量大于 n+1时同步流程结束，系统可接受client的连接请求。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。

2. follower接收写请求后，转发给leader处理；leader完成两阶段提交的机制。向所有server发起提案，当提案获得超过半数（n+1）的server认同后，将对整个集群进行同步，超过半数（n+1）的server同步完成后，该写请求完成。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。

 

选主流程:

zookeeper核心机制包括：恢复模式（选主流程）和广播模式（同步流程）。当服务刚启动、leader崩溃、follower不足半数时，系统就进入选主流程，此时不对外提供服务；当leader被选举出来后，系统就进入同步流程，server之间完成状态同步，此后对外提供服务。本章主要讲解选主流程的原理。

选举策略主要基于paxos算法，一种称为LeaderElection算法，一种称为FashLeaderElection算法，系统默认使用FashLeaderElection算法完成。

 

Watch机制:

Zookeeper客户端在数据节点上设置监视，则当数据节点发生变化时，客户端会收到提醒。Zookeeper中的各种读请求，如getDate()，getChildren()，和exists()，都可以选择加“监视点”(watch)。“监视点”指的是一种一次性的触发器(trigger)，当受监视的数据发生变化时，该触发器会通知客户端。

监视机制有三个关键点：

a) “监视点”是一次性的，当触发过一次之后，除非重新设置，新的数据变化不会提醒客户端。

b) “监视点”将数据改变的通知客户端。如果数据改变是客户端A引起的，不能保证“监视点”通知事件会在引发数据修改的函数返回前到达客户端A。对于“监 视点”，Zookeeper有如下保证：客户端一定是在接收到“监视”事件（watch event）之后才接收到数据的改变信息。

c) getData() 和exists()设置关于节点数据的“监视点”，并返回节点数据信息；getChildren()设置关于子节点的“监视点”，并返回子节点信息。 setData()会触发关于节点数据的“监视点”。成功的create()会触发所建立节点的数据“监视点”，和父节点的子节点“监视点”。成功的 delete()会触发所删除节点的数据“监视点”，和父节点的子节点“监视点”。

d) “监视点”保留在Zookeeper服务器上，则当客户端连接到新的Zookeeper服务器上时，所有需要被触发的相关“监视点”都会被触发。当客户端 断线后重连，与它的相关的“监视点”都会自动重新注册，这对客户端来说是透明的。在以下情况，“监视点”会被错过：客户端B设置了关于节点A存在性的“监视点”，但B断线了，在B断线过程中节点A被创建又被删除。此时，B再连线后不知道A节点曾经被创建过。

Zookeeper的“监视”机制保证以下几点：

a) “监视”事件的触发顺序和分发顺序与事件触发的顺序一致。

b) 客户端将先接收到“监视”事件，然后才收到新的数据

c) “监视”事件触发的顺序与Zookeeper服务器上数据变化的顺序一致

关于Zookeeper“监视”机制的注意点：

a) “监视点”是一次性的

b) 由于“监视点”是一次性的，而且，从接收到“监视”事件到设置新“监视点”是有延时的(间隙内未监视，发生事件监听不到)，所以客户端可能监控不到数据的所有变化

c) 一个监控对象，只会被相关的通知触发一次。如，一个客户端设置了关于某个数据点exists和getData的监控，则当该数据被删除的时候，只会触发“文件被删除”的

通知。

d) 当客户端断开与服务器的连接时，客户端不再能收到“监视”事件，直到重新获得连接。所以关于Session的信息将被发送给所有Zookeeper服务器。由于当连接断开时收不到“监视”时间，所以在这种情况下，模块行为需要容错方面的设计。

 

ACL控制：

znode还具有原子性操作的特点：命名空间中，每一个znode的数据将被原子地读写。读操作读出与数据节点相关联的所有数据，写则替换该节点上的所有数据。每个节点上的“访问控制链”(ACL, Access Control List)保存了各客户端对于该节点的访问权限。

Zookeeper利用访问控制链机制（Access Control List）控制客户端访问数据节点的权限，类似于UNIX文件的访问控制。但Zookeeper对于用户类别的区分，不止局限于所有者(owner)、组 (group)、所有人(world)三个级别。Zookeeper中，数据节点没有“所有者”的概念。访问者利用id标识自己的身份，并获得与之相应的 不同的访问权限。

Zookeeper支持可配置的认证机制。它利用一个三元组来定义客户端的访问权限：(scheme:expression, perms) 。其中，scheme定义了expression的含义，如：host:host1.corp.com标识了一个名为host1.corp.com的主机。 Perms标识了操作权限，如：（ip:19.22.0.0/16, READ）表示IP地址以19.22开头的主机有该数据节点的读权限。

Zookeeper权限定义： 权限 描述 备注 CREATE 有创建子节点的权限 READ 有读取节点数据和子节点列表的权限 WRITE 有修改节点数据的权限 无创建和删除子节点的权限 DELETE 有删除子节点的权限 ADMIN 有设置节点权限的权限

digest:用户名，密码  host:通过客户端的主机名来识别客户端  ip：?通过客户端的ip来识别客户端  new ACL(Perms.READ,new Id("host","example.com"));这个ACL对应的身份验证模式是host，符合该模式的身份是example.com，权限的组合是：READ

 

广播机制：

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

 

Curator（开源客户端框架）

二阶段提交(Two-phased Commit)

二阶段提交机制用于保证分布式系统中的客户端都同意提交或者放弃某事务。

在Zookeeper中，可以在有协调客户端(coordinator)的基础上，实现二阶段提交机制。首先协调客户端创建一个事务节点（如：/app /Tx），为每个参与客户端建立一个子节点（如：/app/Tx/s_i），这些子节点的数据为空。当各个参与客户端接收到协调客户端发送的事务时，它们 别的客户端对应的节点设置“监视”。并通过写自己对应的节点的数据来告诉别的客户端自己是否确认提交事务。需要注意的是，由于很多情况下，只要有一个客户 端不能确认提交，事务就会被丢弃，所以整个处理时间可能很短。