Zookeeper是hadoop的一个子项目，虽然源自hadoop，但是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多。今天我想谈谈zookeeper，本文不谈如何使用zookeeper，而是zookeeper到底有哪些实际的运用，哪些类型的应用能发挥zookeeper的优势，最后谈谈zookeeper对分布式网站架构能产生怎样的作用。
　　Zookeeper是针对大型分布式系统的高可靠的协调系统。由这个定义我们知道zookeeper是个协调系统，作用的对象是分布式系统。为什么分布式系统需要一个协调系统了？理由如下：
　　开发分布式系统是件很困难的事情，其中的困难主要体现在分布式系统的&部分失败&。&部分失败&是指信息在网络的两个节点之间传送时候，如果网络出了故障，发送者无法知道接收者是否收到了这个信息，而且这种故障的原因很复杂，接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。发送者能够获得真实情况的唯一办法就是重新连接到接收者，询问接收者错误的原因，这就是分布式系统开发里的&部分失败&问题。
　　Zookeeper就是解决分布式系统&部分失败&的框架。Zookeeper不是让分布式系统避免&部分失败&问题，而是让分布式系统当碰到部分失败时候，可以正确的处理此类的问题，让分布式系统能正常的运行。
　　下面我要讲讲zookeeper的实际运用场景：
　　场景一：有一组服务器向客户端提供某种服务（例如：我前面做的分布式网站的服务端，就是由四台服务器组成的集群，向前端集群提供服务），我们希望客户端每次请求服务端都可以找到服务端集群中某一台服务器，这样服务端就可以向客户端提供客户端所需的服务。对于这种场景，我们的程序中一定有一份这组服务器的列表，每次客户端请求时候，都是从这份列表里读取这份服务器列表。那么这分列表显然不能存储在一台单节点的服务器上，否则这个节点挂掉了，整个集群都会发生故障，我们希望这份列表时高可用的。高可用的解决方案是：这份列表是分布式存储的，它是由存储这份列表的服务器共同管理的，如果存储列表里的某台服务器坏掉了，其他服务器马上可以替代坏掉的服务器，并且可以把坏掉的服务器从列表里删除掉，让故障服务器退出整个集群的运行，而这一切的操作又不会由故障的服务器来操作，而是集群里正常的服务器来完成。这是一种主动的分布式数据结构，能够在外部情况发生变化时候主动修改数据项状态的数据机构。Zookeeper框架提供了这种服务。这种服务名字就是：统一命名服务，它和javaEE里的JNDI服务很像。
　　场景二：分布式锁服务。当分布式系统操作数据，例如：读取数据、分析数据、最后修改数据。在分布式系统里这些操作可能会分散到集群里不同的节点上，那么这时候就存在数据操作过程中一致性的问题，如果不一致，我们将会得到一个错误的运算结果，在单一进程的程序里，一致性的问题很好解决，但是到了分布式系统就比较困难，因为分布式系统里不同服务器的运算都是在独立的进程里，运算的中间结果和过程还要通过网络进行传递，那么想做到数据操作一致性要困难的多。Zookeeper提供了一个锁服务解决了这样的问题，能让我们在做分布式数据运算时候，保证数据操作的一致性。
　　场景三：配置管理。在分布式系统里，我们会把一个服务应用分别部署到n台服务器上，这些服务器的配置文件是相同的（例如：我设计的分布式网站框架里，服务端就有4台服务器，4台服务器上的程序都是一样，配置文件都是一样），如果配置文件的配置选项发生变化，那么我们就得一个个去改这些配置文件，如果我们需要改的服务器比较少，这些操作还不是太麻烦，如果我们分布式的服务器特别多，比如某些大型互联网公司的hadoop集群有数千台服务器，那么更改配置选项就是一件麻烦而且危险的事情。这时候zookeeper就可以派上用场了，我们可以把zookeeper当成一个高可用的配置存储器，把这样的事情交给zookeeper进行管理，我们将集群的配置文件拷贝到zookeeper的文件系统的某个节点上，然后用zookeeper监控所有分布式系统里配置文件的状态，一旦发现有配置文件发生了变化，每台服务器都会收到zookeeper的通知，让每台服务器同步zookeeper里的配置文件，zookeeper服务也会保证同步操作原子性，确保每个服务器的配置文件都能被正确的更新。
　　场景四：为分布式系统提供故障修复的功能。集群管理是很困难的，在分布式系统里加入了zookeeper服务，能让我们很容易的对集群进行管理。集群管理最麻烦的事情就是节点故障管理，zookeeper可以让集群选出一个健康的节点作为master，master节点会知道当前集群的每台服务器的运行状况，一旦某个节点发生故障，master会把这个情况通知给集群其他服务器，从而重新分配不同节点的计算任务。Zookeeper不仅可以发现故障，也会对有故障的服务器进行甄别，看故障服务器是什么样的故障，如果该故障可以修复，zookeeper可以自动修复或者告诉系统管理员错误的原因让管理员迅速定位问题，修复节点的故障。大家也许还会有个疑问，master故障了，那怎么办了？zookeeper也考虑到了这点，zookeeper内部有一个&选举领导者的算法&，master可以动态选择，当master故障时候，zookeeper能马上选出新的master对集群进行管理。
　　下面我要讲讲zookeeper的特点：
zookeeper是一个精简的文件系统。这点它和hadoop有点像，但是zookeeper这个文件系统是管理小文件的，而hadoop是管理超大文件的。
zookeeper提供了丰富的&构件&，这些构件可以实现很多协调数据结构和协议的操作。例如：分布式队列、分布式锁以及一组同级节点的&领导者选举&算法。
zookeeper是高可用的，它本身的稳定性是相当之好，分布式集群完全可以依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，zookeeper可以被用作一个约会机制，让参入的进程不在了解其他进程的（或网络）的情况下能够彼此发现并进行交互，参入的各方甚至不必同时存在，只要在zookeeper留下一条消息，在该进程结束后，另外一个进程还可以读取这条信息，从而解耦了各个节点之间的关系。
zookeeper为集群提供了一个共享存储库，集群可以从这里集中读写共享的信息，避免了每个节点的共享操作编程，减轻了分布式系统的开发难度。
zookeeper的设计采用的是观察者的设计模式，zookeeper主要是负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。
　　由此可见zookeeper很利于分布式系统开发，它能让分布式系统更加健壮和高效。
　　前不久我参加了部门的hadoop兴趣小组，测试环境的hadoop、mapreduce、hive及hbase都是我来安装的，安装hbase时候安装要预先安装zookeeper，最早我是在四台服务器上都安装了zookeeper，但是同事说安装四台和安装三台是一回事，这是因为zookeeper要求半数以上的机器可用，zookeeper才能提供服务，所以3台的半数以上就是2台了，4台的半数以上也是两台，因此装了三台服务器完全可以达到4台服务器的效果，这个问题说明zookeeper进行安装的时候通常选择奇数台服务器。在学习hadoop的过程中，我感觉zookeeper是最难理解的一个子项目，原因倒不是它技术负责，而是它的应用方向很让我困惑，所以我有关hadoop技术第一篇文章就从zookeeper开始，也不讲具体技术实现，而从zookeeper的应用场景讲起，理解了zookeeper应用的领域，我想再学习zookeeper就会更加事半功倍。
　　之所以今天要谈谈zookeeper，也是为我上一篇文章分布式网站框架的补充。虽然我设计网站架构是分布式结构，也做了简单的故障处理机制，比如：心跳机制，但是对集群的单点故障还是没有办法的，如果某一台服务器坏掉了，客户端任然会尝试连接这个服务器，导致部分请求的阻塞，也会导致服务器资源的浪费。不过我目前也不想去修改自己的框架，因为我总觉得在现有的服务上添加zookeeper服务会影响网站的效率，如果有独立的服务器集群部署zookeeper还是值得考虑的，但是服务器资源太宝贵了，这个可能性不大。幸好我们部门也发现了这样的问题，我们部门将开发一个强大的远程调用框架，将集群管理和通讯管理这块剥离出来，集中式提供高效可用的服务，等部门的远程框架开发完毕，我们的网站加入新的服务，我想我们的网站将会更加稳定和高效。
阅读(...) 评论()下次自动登录
现在的位置:
& 综合 & 正文
zookeeper机制原理
zookeeper机原理（长连接）：
Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管。当对目录节点监控状态打开时，一旦目录节点的状态发生变化，Watcher 对象的 process 方法就会被调用。
（任何实现org.apache.zookeeper.Watcher类，持有zookeeper实例对象，只要调用zookeeper的方法，并且监控相应节点类型，
那么zookeeper服务端该节点发生变化会通知到观察者（观察者重写方法process会被调用））
zk = new ZooKeeper(zookeeperQuorum,
sessionTimeout, this);
zookeeperQuorum=IP+端口（xxx.xxx.xxx.xxx:2181,xxx.xxx.xxx.xxx:2181,xxx.xxx.xxx.xxx:2181）多个逗号隔开
可以设置观察的操作：exists,getChildren,getData
可以触发观察的操作：create,delete,setData
zookeeper观察机制;
服务端只存储事件的信息,客户端存储事件的信息和Watcher的执行逻辑.ZooKeeper客户端是线程安全的每一个应用只需要实例化一个ZooKeeper客户端即可，同一个ZooKeeper客户端实例可以在不同的线程中使用。ZooKeeper客户端会将这个Watcher对应Path路径存储在ZKWatchManager中,同时通知ZooKeeper服务器记录该Client对应的Session中的Path下注册的事件类型。当ZooKeeper服务器发生了指定的事件后,ZooKeeper服务器将通知ZooKeeper客户端哪个节点下发生事件类型，ZooKeeper客户端再从ZKWatchManager中找到相应Path，取出相应watcher引用执行其回调函数process。
源码分析如：
zookeeper.java
wcb = new DataWatchRegistration(watcher, clientPath);//将观察者引用和节点路径绑定
ZKWatchManager.java
public void register(int rc) {
if (shouldAddWatch(rc)) {
Map&String, Set&Watcher&& watches = getWatches(rc);
synchronized(watches) {
Set&Watcher& watchers = watches.get(clientPath);
if (watchers == null) {
watchers = new HashSet&Watcher&();
watches.put(clientPath, watchers);//key为path,value为watcher引用
watchers.add(watcher);
znode存储数据量最大：jute.maxbuffer默认1M
通知注意点：
1.一次性触发器（可以通过定时调用方法 get() 或者 exists()获取触发事件，手动访问触发，）client在一个节点上设置watch，随后节点内容改变，client将获取事件。当节点内容再次改变，client不会获取这个事件，除非它又执行了一次读操作并设置watch
2.发送至client，watch事件延迟watch事件异步发送至观察者。比如说client执行一次写操作，节点数据内容发生变化，操作返回后，而watch事件可能还在发往client的路上。这种情况下，zookeeper提供有序保证：client不会得知数据变化，直到它获取watch事件。网络延迟或其他因素可能导致不同client在不同时刻获取watch事件和操作返回值。
循环调用：
Watcher watcher = loopWatch?this:
byte[] newdata = keeper.getData(path, watcher, null);//实现改变再次提醒！！
应用场景：
Zookeeper 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应。
通知者模式：
发布者持有订阅者的句柄引用，一单状态变化，调用订阅者接口，实现通知模式调用。
zookeeper 操作API：
客户端要连接 Zookeeper 服务器可以通过创建 org.apache.zookeeper.
ZooKeeper 的一个实例对象，然后调用这个类提供的接口来和服务器交互
ZooKeeper 主要是用来维护和监控一个目录节点树中存储的数据的状态。
目录节点类型：
PERSISTENT：持久化目录节点，这个目录节点存储的数据不会丢失
PERSISTENT_SEQUENTIAL：顺序自动编号的目录节点，这种目录节点会根据当前已近存在的节点数自动加 1
EPHEMERAL：临时目录节点，一旦创建这个节点的客户端与服务器端口也就是 session 超时或者断口，这种节点会被自动删除
EPHEMERAL_SEQUENTIAL：临时自动编号节点
节点状态（Stat）：
private long ephemeralO
private int dataL
private int numC
Watch事件类型
ZOO_CREATED_EVENT：节点创建事件，需要watch一个不存在的节点，当节点被创建时触发，此watch通过zoo_exists()设置ZOO_DELETED_EVENT：节点删除事件，此watch通过zoo_exists()或zoo_get()设置ZOO_CHANGED_EVENT：节点数据改变事件，此watch通过zoo_exists()或zoo_get()设置ZOO_CHILD_EVENT：子节点列表改变事件，此watch通过zoo_get_children()或zoo_get_children2()设置ZOO_SESSION_EVENT：会话失效事件，客户端与服务端断开或重连时触发ZOO_NOTWATCHING_EVENT：watch移除事件，服务端出于某些原因不再为客户端watch节点时触发
一：集群管理：
1 监控服务器健康
它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点，然后每个 Server 在它们创建目录节点的父目录节点上调用 ( path,
boolean watch) 方法并设置 watch 为 true，由于是 EPHEMERAL 目录节点，当创建它的 Server 死去，这个目录节点也随之被删除，所以 Children 将会变化，这时 上的 Watch 将会被调用，所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。
2 Master选举
Zookeeper 如何实现 Leader
Election，也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点，是因为我们可以给每台 Server 编号，我们可以选择当前是最小编号的 Server 为 Master，假如这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。
二：分布式锁
在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点，然后调用 方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么它就获得了这个锁，如果不是那么它就调用 ( path,
boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了 n lang=EN-US& Server 也是同样的原理。
&&&&推荐文章:
【上篇】【下篇】