1.zookeeper概述
ZooKeeper是一个为分布式应用所设计的分布的、开源的协调服务。主要的用处：用来解决分布式应用中经常遇到的数据管理问题，简化分布式应用协调及管理难度，提供高性能的分布式服务。
2.zookeeper的核心
2.1核心：
zookeeper最核心就是一个精简的文件系统，提供一些简单的操作以及附加的抽象（例如排序和通知）
2.2易表达：
zookeeper的原型是一个丰富的集合，它们是一些已建好的快，可以用来构建大型的协作数据结构和协议，例如：分布式队列，分布式锁以及分布式锁以及一组对等体的选举
2.3高可用性
运行在集群上
2.4松散解耦
ZooKeeper的交互支持参与者之间并不了解对方。例如：ZooKeeper可以被当做一种公共的机制，使得进程彼此不知道对方的存在也可以相互发现并且交互，对等方可能甚至不是同步的。
2.5一个库
ZooKeeper提供了一个开源的、共享的执行存储，以及通用协作的方法，分担了每个程序员写通用协议的负担。随着时间的推移，人们可以增加和改进这个库来满足自己的需求。
3.zookeeper案例应用原理
简单来说其原理就是：在一个分布式系统中，有一组服务器在运行同样的程序，它们需要确定一个Value，以那个服务器提供的信息为主/为准，当这个服务器经过n/2+1的方式被选出来后，所有的机器上的Process都会被通知到这个服务器就是主服务器 Master服务器，大家以他提供的信息为准。上图;核心点：
1.ZooKeeper用来存放一些相互协作的信息，这些信息一般不超过1M，在zookeeper中是以一种tree的形式来存放，这些具体的Key/Value信息就store在tree node中。
2.当有事件导致node数据，例如：变更，增加，删除时，Zookeeper就会调用 triggerWatch方法，判断当前的path来是否有对应的监听者(watcher),如果有watcher，会触发其process方法，执行process方法中的业务逻辑：
上图：应用案例：
让我们设想一下，在一个分布式系统中有这这样的一个应用：
2个任务工厂(Task Factory)一主一从，如果从的发现主的死了以后，从的就开始工作，他的工作就是向下面很多台代理(Agent)发送指令，让每台代理(Agent)获得不同的账户进行分布式并行计算，而每台代理(Agent)中将分配很多帐号，如果其中一台代理(Agent)死掉了，那么这台死掉的代理上的账户就不会继续工作了。上述，出现了3个最主要的问题：
1.Task Factory主/从一致性的问题；
2.Task Factory主/从心跳如何用简单+稳定 或者2者折中的方式实现；
3.一台代理(Agent)死掉了以后，一部分的账户就无法继续工作，需要通知所有在线的代理(Agent)重新分配一次帐号；
让我们想想ZooKeeper是不是能帮助我们去解决目前遇到的这3个最主要的问题呢？
1.任务工厂Task Factory都连接到ZooKeeper上，创建节点，设置对这个节点进行监控，监控方法例如：
event= new WatchedEvent(EventType.NodeDeleted, KeeperState.SyncConnected,"/TaskFactory");
这个方法的意思就是只要Task Factory与zookeeper断开连接后，这个节点就会被自动删除。
2.原来主的任务工厂断开了TCP连接，这个被创建的/TaskFactory节点就不存在了，而且另外一个连接在上面的Task Factory可以立刻收到这个事件(Event)，知道这个节点不存在了，也就是说主TaskFactory死了。
3.接下来另外一个活着的TaskFactory会再次创建/TaskFactory节点，并且写入自己的ip到znode里面，作为新的标记。
4、此时Agents也会知道主的TaskFactory不工作了，为了防止系统中大量的抛出异常，他们将会先把自己手上的事情做完，然后挂起，等待收到Zookeeper上重新创建一个/TaskFactory节点，收到 EventType.NodeCreated 类型的事件将会继续工作。
5.原来从的TaskFactory 将自己变成一个主TaskFactory，当系统管理员启动原来死掉的主的TaskFactory，世界又恢复平静了。
6.如果一台代理死掉，其他代理他们将会先把自己手上的事情做完，然后挂起，向TaskFactory发送请求，TaskFactory会重新分配(sharding)帐户到每个Agent上了，继续工作。
4.zookeeper基本知识
4.1层次化的名字空间
ZooKeeper的整个名字空间的结构是层次化的，和一般的Linux文件系统结构非常相似，一颗很大的树
4.2znode
Znode维护着数据、ACL（access control list，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。
另外Znode还具有原子性操作的特点：命名空间中，每一个Znode的数据将被原子地读写。读操作将读取与Znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。
ZooKeeper中同样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着非常重要的作用。
4.3 Watch机制
官方给出的定义：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。
Watch机制主要有以下三个特点：
1.一次性的触发器:数据改变的时候，那么一个Watch事件会产生并且被发送到客户端中。但是客户端只会收到一次这样的通知一次性的触发器（one-time trigger）
2.发送给客户端:不同客户端收到Watch事件的时间可能不一样，但是因为客户端是先看到Watch时间，再看到数据变化的，因此，不同客户端实际的变化数据是一致
3.被设置Watch的数据：数据监控和子节点监控
Zookeeper 中的监视是轻量级的，因此容易设置、维护和分发。
只有一种情况会导致监视事件的丢失，即：通过 exists() 设置了某个 znode 节点的监视，但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系，该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知。
4.4ACL访问控制列表
这是另外一个和Linux操作系统非常相似的地方，ZooKeeper使用ACL来控制对旗下Znode结点们的访问。ACL的实现和Linux文件系统的访问权限十分类似：它通过设置权限为来表明是否允许对一个结点的相关内容的改变。
但是与传统Linux机制不太相同，一个结点的数据没有类似“拥有者，组用户，其他用户”的概念，在ZooKeeper中，ACL通过设置ID以及与其关联的权限来完成访问控制的。ACL的权限组成语法是：
(scheme:expression, perms)
前者表明设置的ID，逗号后面表示的是ID相关的权限，例如：
(ip:172.16.16.1,READ)
指明了IP地址为如上的用户的权限为只读。
以下列举以下ACL所具有的权限：
CREATE：表明你可以创建一个Znode的子结点。
READ：你可以得到这个结点的数据以及列举该结点的子结点情况。
WRITE：设置一个结点的数据。
DELETE：可以删除一个结点ADMIN：对一个结点设置权限。
网友评论