Zookeeper

Zookeeper -- 简介

Zookeeper 是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置管理、名称服务、分布式同步、集群服务等。

配置管理： 可以使用 ZooKeeper 集中存储和管理分布式系统的配置。

名称服务： 名称服务是将一个名称映射到与该名称有关联的一些信息的服务。

分布式同步：与互斥同时出现的是同步访问共享资源的需求。

锁定： 为了允许在分布式系统中对共享资源进行有序的访问，可能需要实现分布式互斥 。

集群服务：分布式系统可能必须处理节点停机的问题，您可能想实现一个自动故障转移策略。ZooKeeper 通过领导者选举对此提供现成的支持。

Zookeeper虽然是一个针对分布式的协调服务，但其本身就是一个分布式应用程序。遵循一个简单的客服端-服务器模型，其中客户端是使用服务的节点，而服务器是提供服务的节点。Zookeeper服务器的集合形成了一个Zookeeper服务器。每个Zookeeper服务器可以同时处理大量客户端连接，每个客户端定时发送ping到它所连接的Zookeeper服务器，让服务器知道它处于活动和连接状态。被连接的Zookeeper服务器通过ping确认进行响应，表示服务器处于活动状态。如果客户端指定时间内没用收到服务器的确认，那么客户端会连接到集合体中另外一台服务器，而且客户端回话透明地转移到新的Zookeeper服务器。

 

图 1. ZooKeeper 的客户端-服务器架构

Zookeeper有一个类似于文件系统的数据模型，由znodes组成，可以有各自的子节点。也可以视为目录，它们可以有其他相关的数据，每个目录都被成为znode，znode层次结构被存储在每个Zookeeper服务器的内存中，这实现了对来自客户端读取操作和可扩展的快速响应。每个Zookeeper服务器在磁盘上维护了一个事务日志，也是Zookeeper中对性能重要的组成部分。可以存储在znode中的数据默认最大为1MB。因此。即使Zookeeper的层次结构看起来类似与文件系统相似，也不应该将它用作一个通用的文件系统。相反，应该只将它用作少量数据的存储机制，以便为分布式应用程序提供可靠性、可用性和协调。

当客户端请求读取特定 znode 的内容时，读取操作是在客户端所连接的服务器上进行的。因此，由于只涉及集合体中的一个服务器，所以读取是快速和可扩展的。然而，为了成功完成写入操作，要求 ZooKeeper 集合体的严格意义上的多数节点都是可用的。在启动 ZooKeeper 服务时，集合体中的某个节点被选举为领导者。当客户端发出一个写入请求时，所连接的服务器会将请求传递给领导者。此领导者对集合体的所有节点发出相同的写入请求。如果严格意义上的多数节点（也被称为法定数量（quorum））成功响应该写入请求，那么写入请求被视为已成功完成。然后，一个成功的返回代码会返回给发起写入请求的客户端。如果集合体中的可用节点数量未达到法定数量，那么 ZooKeeper 服务将不起作用。

法定数量是通过严格意义上的多数节点来表示的。在集合体中，可以包含一个节点，但它不是一个高可用和可靠的系统。如果在集合体中有两个节点，那么这两个节点都必须已经启动并让服务正常运行，因为两个节点中的一个并不是严格意义上的多数。如果在集合体中有三个节点，即使其中一个停机了，您仍然可以获得正常运行的服务（三个中的两个是严格意义上的多数）。出于这个原因，ZooKeeper 的集合体中通常包含奇数数量的节点，因为就容错而言，与三个节点相比，四个节点并不占优势，因为只要有两个节点停机，ZooKeeper 服务就会停止。在有五个节点的集群上，需要三个节点停机才会导致 ZooKeeper 服务停止运作。

现在，我们已经清楚地了解到，节点数量应该是奇数，让我们再来思考一下 ZooKeeper 集合体中需要有多少个节点。读取操作始终从连接到客户端的 ZooKeeper 服务器读取数据，所以它们的性能不会随着集合体中的服务器数量额变化而变化。但是，仅在写入法定数量的节点时，写入操作才是成功的。这意味着，随着在集合体中的节点数量的增加，写入性能会下降，因为必须将写入内容写入到更多的服务器中，并在更多服务器之间进行协调。

ZooKeeper 的美妙之处在于，想运行多少服务器完全由您自己决定。如果想运行一台服务器，从 ZooKeeper 的角度来看是没问题的；只是您的系统不再是高度可靠或高度可用的。三个节点的 ZooKeeper 集合体支持在一个节点故障的情况下不丢失服务，这对于大多数用户而言，这可能是没问题的，也可以说是最常见的部署拓扑。不过，为了安全起见，可以在您的集合体中使用五个节点。五个节点的集合体让您可以拿出一台服务器进行维护或滚动升级，并能够在不中断服务的情况下承受第二台服务器的意外故障。

因此，在 ZooKeeper 集合体中，三、五或七是最典型的节点数量。请记住，ZooKeeper 集合体的大小与分布式系统中的节点大小没有什么关系。分布式系统中的节点将是 ZooKeeper 集合体的客户端，每个 ZooKeeper 服务器都能够以可扩展的方式处理大量客户端。例如，HBase（Hadoop 上的分布式数据库）依赖​​于 ZooKeeper 实现区域服务器的领导者选举和租赁管理。您可以利用一个相对较少（比如说，五个）节点的 ZooKeeper 集合体运行有 50 个节点的大型 HBase 集群。

（https://www.ibm.com/developerworks/cn/data/library/bd-zookeeper/）

为什么zookeeper的节点配置的个数必须是奇数个？

zookeeper有这样一个特性：，那么整个集群对外就是可用集群中只要有过半的机器是正常工作的的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。

（http://blog.csdn.net/gaochao1995/article/details/39613431）

 

 

转载于:https://my.oschina.net/u/2600440/blog/1531896