zookeeper应用场景（转）

转载自：http://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html

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的特色：

1. zookeeper是一个精简的文件系统。这点它和hadoop有点像，可是zookeeper这个文件系统是管理小文件的，而hadoop是管理超大文件的。
2. zookeeper提供了丰富的“构件”，这些构件能够实现不少协调数据结构和协议的操做。例如：分布式队列、分布式锁以及一组同级节点的“领导者选举”算法。
3. zookeeper是高可用的，它自己的稳定性是至关之好，分布式集群彻底能够依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
4. zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，zookeeper能够被用做一个约会机制， 让参入的进程不在了解其余进程的（或网络）的状况下可以彼此发现并进行交互，参入的各方甚至没必要同时存在，只要在zookeeper留下一条消息，在该进 程结束后，另一个进程还能够读取这条信息，从而解耦了各个节点之间的关系。
5. zookeeper为集群提供了一个共享存储库，集群能够从这里集中读写共享的信息，避免了每一个节点的共享操做编程，减轻了分布式系统的开发难度。
6. 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仍是值得考虑的，可是服务器资源太宝贵了，这个可能性不大。幸亏咱们部门也发现了这样的问题，咱们部门将开发一个强大的远程调用框架， 将集群管理和通信管理这块剥离出来，集中式提供高效可用的服务，等部门的远程框架开发完毕，咱们的网站加入新的服务，我想咱们的网站将会更加稳定和高效。