1、zookeeper定义：开源的分布式应用协调系统，主要用于管理分布式应用程序。被设计用于存储协调数据、状态信息、配置信息及位置信息等。
2、zookeeper的特性及用途：
1）：特性
-
简单的分布式协调过程
-
同步 - 服务器进程之间的相互排斥和协作。此过程有助于Apache HBase进行配置管理。
-
有序的消息
-
序列化 - 根据特定规则对数据进行编码。确保应用程序运行一致。这种方法可以在MapReduce中用来协调队列以执行运行的线程。
-
可靠性
-
原子性 - 数据转移完全成功或完全失败，但没有事务是部分的。
3、数据节点 znode: zookeeper树中的每个节点被称为一个znode，和windows文件系统的目录树一样zookeeper树中的每个节点都可以拥有子节点，数据节点分为永久节点和临时节点，临时节点由客户端创建，当客户端被删除时临时节点也会被删除，zookeeper所有的数据都是存储于znode中。
4、主从节点：zookeeper由众多节点构成集群，保证了其不会发生发生单点故障，所以zookeeper建议至少部署3个以上节点，另外部署zookeeper节点个数一定要为单数如1、3、5等。同一时间zookeeper保证只有一个主节点（leader）,其他节点都是从节点（follower）。
5、组件操作
| 组件 | 描述 |
|---|---|
| 写入（write） | 写入过程由leader节点处理。leader将写入请求转发到所有znode，并等待znode的回复。如果一半的znode回复，则写入过程完成。 |
| 读取（read） | 读取由特定连接的znode在内部执行，因此不需要与集群进行交互。 |
| 复制数据库（replicated database） | 它用于在zookeeper中存储数据。每个znode都有自己的数据库，每个znode在一致性的帮助下每次都有相同的数据。 |
| Leader | Leader是负责处理写入请求的Znode。 |
| Follower | follower从客户端接收写入请求，并将它们转发到leader znode。 |
| 请求处理器（request processor） | 只存在于leader节点。它管理来自follower节点的写入请求。 |
| 原子广播（atomic broadcasts） | 负责广播从leader节点到follower节点的变化。 |
6、分布式锁
熟悉java的朋友看到锁可以联想起synchronized,但是它只能处理单个应用程序对锁的要求，下面我们来介绍一下分布式锁。
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。分布式锁又分为排他锁和共享锁两种。
1）排他锁（Exclusive Locks，简称X锁），又称为写锁或独占锁。
如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能在对这个数据对象进行任何类型的操作（不能再对该对象加锁），直到T1释放了排他锁。
可以看出，排他锁的核心是如何保证当前只有一个事务获得锁，并且锁被释放后，所有正在等待获取锁的事务都能够被通知到。
那么ZooKeeper是如何实现排他锁？
定义锁
ZooKeeper上的一个ZNode可以表示一个锁。例如/exclusive_lock/lock节点就可以被定义为一个锁。
获得锁
如上所说，把ZooKeeper上的一个ZNode看作是一个锁，获得锁就通过创建ZNode的方式来实现。所有客户端都去/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。ZooKeeper会保证在所有客户端中，最终只有一个客户端能够创建成功，那么就可以认为该客户端获得了锁。同时，所有没有获取到锁的客户端就需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。
释放锁
因为/exclusive_lock/lock是一个临时节点，因此在以下两种情况下，都有可能释放锁。
- 当前获得锁的客户端机器发生宕机或重启，那么该临时节点就会被删除，释放锁。
- 正常执行完业务逻辑后，客户端就会主动将自己创建的临时节点删除，释放锁。
无论在什么情况下移除了lock节点，ZooKeeper都会通知所有在/exclusive_lock节点上注册了节点变更Watcher监听的客户端。这些客户端在接收到通知后，再次重新发起分布式锁获取，即重复『获取锁』过程。
2）共享锁
共享锁（Shared Locks，简称S锁），又称为读锁。如果事务T1对数据对象O1加上了共享锁，那么T1只能对O1进行读操作，其他事务也能同时对O1加共享锁（不能是排他锁），直到O1上的所有共享锁都释放后O1才能被加排他锁。
总结：可以多个事务同时获得一个对象的共享锁（同时读），有共享锁就不能再加排他锁（因为排他锁是写锁）
7、session(会话)
会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。
8、watches事件监听器
ZooKeeper可以为所有的读操作设置watch，这些读操作包括：exists()、getChildren()及getData()。watch事件是一次性的触发器，当watch的对象状态发生改变时，将会触发此对象上watch所对应的事件,watch事件将被异步地发送给客户端，并且ZooKeeper为watch机制提供了有序的一致性保证。
watch的注册与触发事件
3）etChildren操作上的watch，在被监视的Znode的子节点创建或删除，或是这个Znode自身被删除时被触发。可以通过查看watch事件类型来区分是Znode，还是他的子节点被删除：NodeDelete表示Znode被删除，NodeDeletedChanged表示子节点被删除。
9、心跳检测
机器间的心跳检测机制是指在分布式环境中，不同机器（或进程）之间需要检测到彼此是否在正常运行，例如A机器需要知道B机器是否正常运行。在传统的开发中，我们通常是通过主机直接是否可以相互PING通来判断，更复杂一点的话，则会通过在机器之间建立长连接，通过TCP连接固有的心跳检测机制来实现上层机器的心跳检测，这些都是非常常见的心跳检测方法。
下面来看看如何使用ZK来实现分布式机器（进程）间的心跳检测。
基于ZK的临时节点的特性，可以让不同的进程都在ZK的一个指定节点下创建临时子节点，不同的进程直接可以根据这个临时子节点是否存在来判断对应的进程是否存活。通过这种方式，检测和被检测系统直接并不需要直接相关联，而是通过ZK上的某个节点进行关联把检测工作交给了zk，大大减少了系统之间的耦合。
10：示例用途
数据发布与订阅（配置中心）
数据发布与订阅，即所谓的配置中心，顾名思义就是发布者将数据发布到ZooKeeper节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和动态更新。
在我们平常的应用系统开发中，经常会碰到这样的需求：系统中需要使用一些通用的配置信息，例如机器列表信息、数据库配置信息等。这些全局配置信息通常具备以下3个特性。
- 数据量通常比较小。
- 数据内容在运行时动态变化。
- 集群中各机器共享，配置一致。
对于这样的全局配置信息就可以发布到ZooKeeper上，让客户端（集群的机器）去订阅该消息。
发布/订阅系统一般有两种设计模式，分别是推（Push）和拉（Pull）模式。
- 推：服务端主动将数据更新发送给所有订阅的客户端。
- 拉：客户端主动发起请求来获取最新数据，通常客户端都采用定时轮询拉取的方式。
ZooKeeper采用的是推拉相结合的方式。如下：
客户端想服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据（推拉结合）。
命名服务(Naming Service)
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架（如RPC、RMI）中的服务地址列表。通过在ZooKeepr里创建顺序节点，能够很容易创建一个全局唯一的路径，这个路径就可以作为一个名字。
ZooKeeper的命名服务即生成全局唯一的ID。
11、参考地址：
官方地址：https://zookeeper.apache.org/
git地址：https://github.com/apache/zookeeper
w3cSchool学习地址：https://www.w3cschool.cn/zookeeper/zookeeper_cli.html
https://www.cnblogs.com/wuxl360/p/5817471.html
http://blog.jobbole.com/110388/
6979
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
