Zookeeper是hadoop的一个子项目，尽管源自hadoop，可是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多。
今天我想谈谈zookeeper。本文不谈如何使用zookeeper。而是zookeeper究竟有哪些实际的运用，哪些类型的应用能发挥zookeeper的优势，最后谈谈zookeeper对分布式站点架构能产生如何的作用。
Zookeeper是针对大型分布式系统的高可靠的协调系统。
由这个定义我们知道zookeeper是个协调系统，作用的对象是分布式系统。为什么分布式系统须要一个协调系统了？理由例如以下：
开发分布式系统是件非常困难的事情，当中的困难主要体如今分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候，假设网络出了故障，发送者无法知道接收者是否收到了这个信息。并且这样的故障的原因非常复杂。接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。
发送者可以获得真实情况的唯一办法就是又一次连接到接收者，询问接收者错误的原因，这就是分布式系统开发里的“部分失败”问题。
Zookeeper就是解决分布式系统“部分失败”的框架。
Zookeeper不是让分布式系统避免“部分失败”问题，而是让分布式系统当碰到部分失败时候。能够正确的处理此类的问题，让分布式系统能正常的执行。
以下我要讲讲zookeeper的实际运用场景：
场景一：有一组server向client提供某种服务（比如：我前面做的分布式站点的服务端。就是由四台server组成的集群，向前端集群提供服务）。我们希望client每次请求服务端都能够找到服务端集群中某一台server，这样服务端就能够向client提供client所需的服务。
对于这样的场景，我们的程序中一定有一份这组server的列表。每次client请求时候，都是从这份列表里读取这份server列表。
那么这分列表显然不能存储在一台单节点的server上。否则这个节点挂掉了，整个集群都会发生问题，我们希望这份列表时高可用的。
高可用的解决方式是：这份列表是分布式存储的，它是由存储这份列表的server共同管理的。假设存储列表里的某台server坏掉了。其它server立即能够替代坏掉的server。而且能够把坏掉的server从列表里删除掉，让故障server退出整个集群的执行，而这一切的操作又不会由故障的server来操作。而是集群里正常的server来完毕。
这是一种主动的分布式数据结构，能够在外部情况发生变化时候主动改动数据项状态的数据机构。Zookeeper框架提供了这样的服务。这样的服务名字就是：统一命名服务。它和javaEE里的JNDI服务非常像。
场景二：分布式锁服务。当分布式系统操作数据，比如：读取数据、分析数据、最后改动数据。在分布式系统里这些操作可能会分散到集群里不同的节点上，那么这时候就存在数据操作过程中一致性的问题，假设不一致。我们将会得到一个错误的运算结果，在单一进程的程序里，一致性的问题非常好解决，可是到了分布式系统就比較困难，由于分布式系统里不同server的运算都是在独立的进程里。运算的中间结果和过程还要通过网络进行传递，那么想做到数据操作一致性要困难的多。Zookeeper提供了一个锁服务攻克了这种问题。能让我们在做分布式数据运算时候。保证数据操作的一致性。
场景三：配置管理。在分布式系统里，我们会把一个服务应用分别部署到n台server上，这些server的配置文件是同样的（比如：我设计的分布式站点框架里，服务端就有4台server，4台server上的程序都是一样，配置文件都是一样），假设配置文件的配置选项发生变化，那么我们就得一个个去改这些配置文件。假设我们须要改的server比較少，这些操作还不是太麻烦，假设我们分布式的server特别多，比方某些大型互联网公司的hadoop集群有数千台server。那么更改配置选项就是一件麻烦并且危急的事情。
这时候zookeeper就能够派上用场了，我们能够把zookeeper当成一个高可用的配置存储器，把这种事情交给zookeeper进行管理，我们将集群的配置文件复制到zookeeper的文件系统的某个节点上，然后用zookeeper监控全部分布式系统里配置文件的状态，一旦发现有配置文件发生了变化。每台server都会收到zookeeper的通知，让每台server同步zookeeper里的配置文件，zookeeper服务也会保证同步操作原子性，确保每一个server的配置文件都能被正确的更新。
场景四：为分布式系统提供故障修复的功能。
集群管理是非常困难的。在分布式系统里增加了zookeeper服务，能让我们非常easy的对集群进行管理。集群管理最麻烦的事情就是节点故障管理，zookeeper能够让集群选出一个健康的节点作为master，master节点会知道当前集群的每台server的执行状况，一旦某个节点发生问题，master会把这个情况通知给集群其它server，从而又一次分配不同节点的计算任务。Zookeeper不仅能够发现故障，也会对有故障的server进行甄别，看故障server是什么样的故障，假设该故障能够修复，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。最早我是在四台server上都安装了zookeeper，可是同事说安装四台和安装三台是一回事，这是由于zookeeper要求半数以上的机器可用。zookeeper才干提供服务。所以3台的半数以上就是2台了，4台的半数以上也是两台。因此装了三台server全然能够达到4台server的效果，这个问题说明zookeeper进行安装的时候通常选择奇数台server。
在学习hadoop的过程中，我感觉zookeeper是最难理解的一个子项目。原因倒不是它技术负责，而是它的应用方向非常让我困惑，所以我有关hadoop技术第一篇文章就从zookeeper開始。也不讲详细技术实现。而从zookeeper的应用场景讲起，理解了zookeeper应用的领域，我想再学习zookeeper就会更加事半功倍。
之所以今天要谈谈zookeeper，也是为我上一篇文章分布式站点框架的补充。尽管我设计站点架构是分布式结构。也做了简单的故障处理机制，比方：心跳机制，可是对集群的单点故障还是没有办法的，假设某一台server坏掉了。client任然会尝试连接这个server。导致部分请求的堵塞。也会导致server资源的浪费。只是我眼下也不想去改动自己的框架，由于我总认为在现有的服务上加入zookeeper服务会影响站点的效率，假设有独立的server集群部署zookeeper还是值得考虑的。可是server资源太宝贵了，这个可能性不大。
幸好我们部门也发现了这种问题，我们部门将开发一个强大的远程调用框架。将集群管理和通讯管理这块剥离出来，集中式提供高效可用的服务，等部门的远程框架开发完成。我们的站点加入新的服务，我想我们的站点将会更加稳定和高效。