转载

ZooKeeper解析：分布式系统工程师的瑞士军刀

【51CTO.com快译】所谓分布式系统，指的是一组通过发送消息实现协作、从而共同达成同一目标的资源集合。正如知名计算机科学家Leslie Lamport所指出之定义：“所谓分布式系统，其中任意一台计算设备——即使使用者并未直接使用甚至对其存在毫不知情——出现故障，亦会影响到其它设备的正常运作。”

而这条定义也恰恰概括了我们在分布式系统当中经常遇到的一类问题。事实上，在云计算时代之下，资源的汇聚已经成为满足负载对于计算及存储实际需求的一种必然手段。这类系统的特点在于包含大量需要管理的资源，而其中故障的出现频率与整体规模则成正比关系。

在分布式系统当中，故障属于一类常规事态，而非意外状况——这意味着我们必须时刻做好心理准备。有鉴于此，相关社区专门创建出专门的工具，旨在帮助开发人员应对这方面问题，而Apache ZooKeeper正是其中之一。

ZooKeeper是一款极具实用性、现场测试能力并拥有广泛用户群体的中间件，专门用于构建分布式应用程序。在OpenStack当中，ZooKeeper也成为Nova ServiceGroup API后端中的组成部分。最近，ZooKeeper还与Ceilometer相集成，从而为Central Agent带来更为理想的高可用性水平——当然，这方面话题我们以后将另行讨论。

我们为什么需要ZooKeeper?

一般来讲，当大家设计一款分布式应用程序时，常常会发现需要将各类流程加以协同才能执行预期任务。在大多数情况下，这种协作关系依赖于最基本的分布式协作机制。

Heat是一款OpenStack编排程序。大家可以利用它创建出一系列云资源，而这类资源会由一个模板文件负责指定，这就是堆栈的概念。Heat允许用户对堆栈进行更新，但更新过程必须以原子方式进行，否则可能会导致资源复制或者相关性破坏等冲突。这类问题在并发更新场景下非常常见，而为了解决此类问题，Heat会在对堆栈进行更新之前首先设置一套所谓分布式互斥锁。

在这类原型基础之上进行开发是项极为困难的工作，而且经常带来令人头痛的麻烦。事实上，在分布式系统当中反复出现的这些问题早已成为技术圈中的共识。为了简化开发人员的日常工作，雅虎实验室创造出了Apache ZooKeeper项目，旨在为这些协作因素提供一套集中式API。归功于ZooKeeper的帮助，现在我们已经能够轻松实现多种不同协议，包括分布式锁、屏障以及队列等等。

ZooKeeper应用程序的架构与优势

一款ZooKeeper应用程序由一台或者多台ZK服务器支撑而成，我们可以将其称为一个“集合”，在应用程序端则为一组ZK客户端。

ZooKeeper解析：分布式系统工程师的瑞士军刀

其设计思路在于，该分布式应用程序的每一个节点都通过使用一个ZK客户端在应用层级使用相关API，这意味着应用的运行将依赖于ZooKeeper服务器实现。

这种架构方案拥有以下几项突出优势：

我们可以立足于应用层提取大部分分布式同步负载，从而实现一套所谓KISS(即Keep It Simple, Stupid，保持一切简单且具傻瓜式特性)架构。
常见的各类分布式协作元能够实现开箱即用，因此开发人员无需再自行对其加以处理。
开发人员不需要处理服务故障等状况，因为整套体系拥有出色的弹性。ZooKeeper以应用程序神经中心的姿态存在，因为它负责控制整个协作机制，因此众多组件都需要依附于它以实现作用。出于这些理由，ZooKeeper在设计中引入了出色的分布式算法，从而提供开发人员所需要的高可靠性与可用性保障。一个ZooKeeper集合基于群体形式存在，且通常由三到五台服务器构成。

ZooKeeper集合能够在多种场景之下发挥作用，下面让我们从实践角度出发一同来了解。