ZooKeeper 是什么与概述,典型用例
Apache ZooKeeper是Apache软件基金会的一个软件项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。[需要解释] ZooKeeper曾经是Hadoop的一个子项目，但现在是一个独立的顶级项目。
ZooKeeper的架构通过冗余服务实现高可用性。因此，如果第一次无应答，客户端就可以询问另一台ZooKeeper主机。ZooKeeper节点将它们的数据存储于一个分层的名字空间，非常类似于一个文件系统或一个前缀树结构。客户端可以在节点读写，从而以这种方式拥有一个共享的配置服务。更新是全序的。[1]
使用ZooKeeper的公司包括Rackspace、雅虎[2]和eBay，以及类似于像Solr这样的开源企业级搜索系统。
ZooKeeper 概述
ZooKeeper 允许分布式进程通过数据寄存器（我们称这些寄存器为 znodes）的共享分层命名空间相互协调，很像文件系统。与普通文件系统不同，ZooKeeper 为其客户端提供高吞吐量、低延迟、高可用、严格有序的 znode 访问。 ZooKeeper 的性能方面允许它在大型分布式系统中使用。可靠性方面可防止它成为大型系统中的单点故障。它的严格排序允许在客户端实现复杂的同步原语。
ZooKeeper 提供的命名空间很像标准文件系统的命名空间。名称是由斜杠（“/”）分隔的一系列路径元素。 ZooKeeper 名称空间中的每个 znode 都由路径标识。并且每个 znode 都有一个父节点，其路径是 znode 的前缀，少一个元素；此规则的例外是没有父级的根 ("/")。此外，与标准文件系统完全一样，如果 znode 有任何子节点，则无法删除它。
ZooKeeper 和标准文件系统之间的主要区别在于，每个 znode 都可以拥有与之关联的数据（每个文件也可以是一个目录，反之亦然）并且 znode 受限于它们可以拥有的数据量。 ZooKeeper 旨在存储协调数据：状态信息、配置、位置信息等。这种元信息通常以千字节为单位，如果不是字节的话。 ZooKeeper 内置了 1M 的健全性检查，以防止将其用作大型数据存储，但通常它用于存储更小的数据块。
服务本身在组成服务的一组机器上进行复制。这些机器在持久存储中维护数据树的内存映像以及事务日志和快照。因为数据保存在内存中，所以 ZooKeeper 能够获得非常高的吞吐量和低延迟数字。内存数据库的缺点是 ZooKeeper 可以管理的数据库大小受内存限制。此限制是保持 znode 中存储的数据量较小的进一步原因。
组成 ZooKeeper 服务的服务器必须相互了解。只要大多数服务器可用，ZooKeeper 服务就可用。客户端还必须知道服务器列表。客户端使用此服务器列表创建 ZooKeeper 服务的句柄。
客户端仅连接到单个 ZooKeeper 服务器。客户端维护一个 TCP 连接，通过它发送请求、获取响应、获取监视事件和发送心跳。如果与服务器的 TCP 连接中断，客户端将连接到不同的服务器。当客户端第一次连接到 ZooKeeper 服务时，第一个 ZooKeeper 服务器将为客户端建立一个会话。如果客户端需要连接到另一台服务器，此会话将与新服务器重新建立。
ZooKeeper 客户端发送的读取请求在客户端连接的 ZooKeeper 服务器上本地处理。如果读取请求在 znode 上注册了一个监视，则该监视也会在 ZooKeeper 服务器上本地跟踪。写请求被转发到其他 ZooKeeper 服务器并在生成响应之前通过共识。同步请求也会转发到另一台服务器，但实际上并不经过共识。因此，读取请求的吞吐量随着服务器数量的增加而增加，而写入请求的吞吐量随着服务器数量的增加而减少。
顺序对 ZooKeeper 非常重要；几乎接近强迫症。所有更新都是完全有序的。 ZooKeeper 实际上用反映此顺序的数字标记每个更新。我们称这个数字为 zxid（ZooKeeper 事务 ID）。每次更新都会有一个唯一的 zxid。读取（和观察）按更新顺序排列。读取响应将被标记为服务读取的服务器处理的最后一个 zxid。
典型用例
目录服务
目录服务（英语：Directory service）是一个储存、组织和提供信息访问服务的软件系统，在软件工程中，一个目录是指一组名字和值的映射。它允许根据一个给出的名字来查找对应的值，与词典相似。像词典中每一个词也许会有多个词义，在一个目录中，一个名字也许会与多个不同的信息相关联。类似地，就像一个词会有多个不同的发音和多个不同的词义，目录中的一个名字可能会有多个不同类型的值。
目录也许只提供范围非常小的节点类型和数值类型，也可能对任意的或可扩展的一组类型提供支持。在一个电话目录中，节点就是姓名而数值项就是电话号码。在DNS中，节点是域名而数值项是IP地址（还有别名，邮件服务器名等等）。在一个网络操作系统的目录中，节点是那些由操作系统所管理的资源，包括用户、计算机、打印机和其它共享资源。互联网问世以来，有许多目录服务得到应用，但是本文主要关注那些源自X.500的目录服务
目录服务遵循LDAP和X.500协议。目录服务的一个最常用例子是DNS服务。微软的Active Directory是目录服务的一个著名实现。
介绍
名字服务是一个简单的目录服务，名字服务将一个网络资源的名字与它的网络地址进行映射。用名字服务这种类型的目录，一个用户不必记住某个网络资源的物理地址，只需要提供这个网络资源的名字就可以找到它。在网络上的每一个资源都被目录服务当作一个对象，关于某个网络资源的信息被作为这个对象的属性存储起来。存储到对象之内的信息可以进行访问控制以增强安全性，这样只有授权的用户才能访问到这些信息。更复杂的目录服务设计名字空间，诸如：用户、服务、设备、凭证、应用程序配置等等。这种设计是与身份管理高度相关的。
一个目录服务定义网络的名字空间。在此，名字空间是指在一个名字条目中容纳一个或多个对象。目录的设计过程中通常包括一套确定网络资源命名和编号的规则。在这套规则之下，网络资源的命名是唯一且无歧义的。在 X.500 (目录服务的标准)和LDAP中这种名字称作可分辨名称 (DN)，用来作为在目录中的入口从而访问到该可分辨名称的属性集合。
目录服务是一种共享的基础信息服务，可用来定位、管理和组织通用项目和网络资源，包括：卷、文件夹、文件、打印机、用户、组、设备、电话号码和其它对象。目录服务是NOS的重要组件。更复杂的情况下，目录服务作为一个服务交付平台的中心信息库使用。比方说使用目录服务查找“计算机”时，可能会调出所有可用的计算机和相关信息列表，用户可以在列表中操作这些计算机。
在设计和管理目录服务中，复制和分布是两个截然不同的概念。复制是指相同的目录名字空间（相同的对象）被复制到另外一台服务器用以冗余备份和提高负载能力。复制的名字空间由同一个部门管理。分布是指多台服务器分别负责不同的名字空间，相互连接，形成一个分布式的目录服务,每一个不同的名字空间可以由不同的部门管辖。
配置管理
配置管理（Configuration management、CM）也称为组态管理，是系统工程的一部分，应用在专案的完整生命周期中，使产品的性能、功能以及实体属性和其需求、设计、操作资讯可以保持一致[1][2]。 配置管理已普遍使用在军事工程组织中，在复杂系统（例如武器系统、军用车辆及信息系统）的系统发展生命周期中管理其变更。在军事以外的应用中，配置管理也用在IT服务管理中，像是信息技术基础架构库、土木工程的领域模型，或是其他像是道路、桥梁、运河、水坝及建筑物的专案中[3][4][5]。
简介
配置管理是用系统化的方式管理变更的实务，目的是让系统在不同时间都可以维持一致性。在配置管理中包括了政策、程序、技巧以及工具，在系统变化的过程中，可以管理变更、评估要进行的变更、追踪变更状态、维持系统资产及支持文件。配置管理方案以及计划会提供技术以及管理的方向，实现要成功开发及维护复杂系统需要的相关程序、功能、服务、工具、流程以及资源。配置管理中可以进行计划管理，在包括运作及维护在内的整个生命周期中，追踪各项的需求。不可避免的，在过程中会有需求以及设计的变化，这些变化需要核可，也需要记录，以针对系统状态有准确的纪录。理想上，配置管理会在整个系统发展生命周期中使用。有时会将配置管理和资产管理混淆，资产管理是盘点手上的资产。配置管理和资产管理的差异是前者不会由财务的角度来进行管理，而是以系统要提供的服务才进行管理。
在MIL–HDBK–61A中提到，针对硬件及软件的配置管理包括五项不同的知识领域（discipline）[9] ，在ANSI/EIA-649中，这些知识领域是建立形态基准及进行标准应变管理时的政策及程序。IEEE 12207程序IEEE 12207.2中也有这些活动，另外再加上“发布管理及交货”（Release management and delivery）。 五个知识领域如下：
配置管理计划及管理：配置管理专案的正式文件及计划，包括有以下项目：
- 人员
- 权责及资源
- 训练要求
- 管理会议的指南，其中包括流程及工具的定义
- 基准流程
- 配置控制及配置状态统计（Configuration Status Accounting）
- 命名规范
- 审核和审查
分包商/供应商的配置管理需求
- 配置识别（Configuration Identification、CI）：包括设定基准以及维持基准，基准是定义系统及子系统架构、组件，以及在任何时间点的开发。这是识别、纪录以及追踪系统中变更项目的基础，应用在设计、开发、测试及交付阶段。配置识别会渐进式的建立系统以及其配置项目（CI）的配置状态统计（Configuration Status Accounting）的目前状态，并且在系统生命周期中（开发、生产、布署以及运行维护）持续的维护，一直到系统停用为止。
- 配置控制（Configuration Control）：包括变更请求以及变更提案的评估，后续是否核可等。此程序包括系统设计、硬件、软件、固件、文件任何修改的控制程序。
- 配置状态统计（Configuration Status Accounting）：包括纪录配置项目说明（例如硬件、软件、固件），、产出报告、并且纪录在设计或制造阶段，所有不符合基准的部分。若怀疑有问题，透过基准配置验证以及核可修改的验证即可缩小确认范围。
- 配置验证及审核：硬件和软件的独立验证，目的是要针对性能需求、商业或军事标准、性能基准、产品基准，评估是否符合。在核可架构进入架构基线之前，会先进行基础配置审核（Configuration audits），会验证系统及子系统的组态文件是否符合机能以及实体的性能特点。
- 软件主条目：软件配置管理
软件配置管理（SCM）是在开发软件专案时，处理变更的方式。此作法会在专案的不同阶段落识别软件的机能属性及实体属性，用系统化的方式来控制变更，目的是为了是在开发周期中维持软件完整并且可追踪。
软件配置管理流程会定义需要追踪变更的项目，并且可以确认最后发布的软件是否有原先预期发布时应该有的更新内容。若要实施软件配置管理流程，需在软件专案中识别出以下四个流程：
- 配置识别（Configuration Identification）
- 配置控制（Configuration Control）
- 配置状态统计（Configuration status accounting）
- 配置审核（Configuration audits）
其名词及定义会随标准而不同，不过在本质上是一様的。
配置识别（Configuration identification）是识别配置项目每一个层面的属性。配置项目（configuration item）是一个终端客户会使用的产品（硬件或／及软件）。属性会纪录在组态文件中，并且设定形态基准。设定形态基准的好处是当属性变更时，要透过正式的控制管理流程才能变动。
配置变更控制（Configuration change control）是要修改配置项目属性，或是重新订形态基准时需要进行的流程以及核可。
配置状态统计（Configuration status accounting）是指可以纪录每一个配置项目的形态基准，并且提供任何时间时的对应形态基准。
配置审核（Configuration audits）会分为机能配置审核（function configuration audit）及实体配置审核（physical configuration audit）。可以在交付时进行，也可以在任何变更要实施时进行。机能配置审核确保配置项目可以达到其机能属性以及性能属性，实体配置审核则确认配置项目的安装方式符合细节设计文件中的需求。
配置管理数据库
资讯技术基础架构数据库（ITIL）有规范用配置管理系统（Configuration management system、CMS）或配置管理数据库（CMDB）作为产业上配置管理的最佳实务。配置管理数据库用来追踪配置项目，并且追踪彼此之间的相关性，此处的配置项目是指在企业内值得追踪并且管理的项目，包括电脑、软件授权、电脑机架、网络装置、储存设备，甚至是这些设备的零件等。
配置管理系统／配置管理数据库的好处是可以进行像是根本原因分析、影响分析、变更管理等机能，也可以评估目前状态，作为未来策略开发的根据。这类系统（多半会分类为资讯科技服务管理系统）的例子有FreshService、ServiceNow及Samanage。
资讯保障
在资讯保障领域中，配置管理是在资讯系统的生命周期中，透过硬件、软件、固件、文件、测试、测试治具、测试文件的变更管理，来管理系统的资料安全特性及保障。[10]。资讯保障的配置管理，有时也会简称SCM（Secure Configuration Management），, 需要配合IT平台及产品的性能、功能及实体属性，以及其环境，来决定系统需要的适当安全特点以及保障。例如，同样是防火墙，在组织互联网边界上的防火墙，其组态需求就和在公司内部的防火墙不同。
维护系统
配置管理也可以用在维护系统上，可以了解复杂资产的情形，以最低的成本达到最高程度的可用性，其目的是要确保不会因资产（或资产的零件）运作超过计划寿命或是运作在品质水准以下，造成运作的中断。
在军事上，这类活动称为任务准备（mission readiness），要定义可用资产以及要执行的任务。例如航空母舰上的飞机是否配备了用于地面支援的炸弹或防御用的导弹。
操作系统配置管理
配置管理可以用来维护操作系统的配置档案[11]。这类的系统中包括Ansible、Bcfg2、CFEngine、Chef、Otter、Puppet、Quattor、SaltStack、Terraform、Pulumi及Vagrant。许多这类的系统用基础架构即代码（IaaS）来定义组态以及维护组态[12]
配置管理的承诺理论（Promise theory）是由Mark Burgess开发的[13][14][15]，实际的实现是在现今CFEngine软件，可以做实时的修复，也可以做预防性的保养。
预防性维护
主条目：预防性维护
预防性维护常用在企业资产维护、维修及企业资产管理系统系统中，其核心元素是了解资产及其重要组成当前的状态。
像飞机、船舶、工业设备等复杂的资料，要在其中的各种零件是可服务的状态下才能正常运作。可用性（serviceability）会用许多的资讯定义，包括零件购置后、安装后、维修后的使用情形，以及其他的限制因素。需要了解这些元件还可用多久，以往这类的工作需要大量的人力，一直到有对应的软件后才改善此一问题。
预测性维护
主条目：预测性维护
许多设备都会有电子感测器搜集资料在运行过程进行状态监测。资料会在设备上或远端的电脑上分析，评估目前的可用性，并且设法预测未来的可用性，会使用预测未来潜在失效的算法，依以往现场的失效案例，以及建模的结果来分析，并且提供提前维护的建议，这称为预测性维护。
可以有准确且及时的可用性资讯，对配置管理可以提供运营价值至关重要，少了这些资讯可能就会造成一些限制。撷取操作资讯，并且分发给各支持组织，本身就形成一个产业。
随着原始设备制造商（OEM）提供的软件越来越多，这些数据的使用也越来越多。这些的目的是让运营商可以保证其可用性，也让资产管理的内容更加复杂，但原始设备制造商仍有责任确保其产品的可用性。
同步
同步（英语：synchronization），指在一个系统中所发生的事件（event）之间进行协调，在时间上出现一致性与统一化的现象。在系统中进行同步，也被称为及时（in time）或同步化的（synchronous, in sync）。
同步，可以理解为在通信时、函数调用时、协议栈的相邻层协议交互时等场景下，发信方与收信方、主调与被调等双方的状态是否能及时保持状态一致。如果一方完成一个动作后，另一方立即就修改了自己的状态，就是同步。而异步，是指调用方发出请求就立即返回，请求甚至可能还没到达接收方，比如说放到了某个缓冲区中，等待对方取走或者第三方转交；而调用结果是通过接收方主动推送，或调用方轮询来得到。
同步还可以理解为：发出一个调用时，在没有得到结果之前，该调用就不返回；一旦调用返回，就得到返回值。换句话说，就是由调用者主动等待这个调用的结果。而异步则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知或通过回调函数，让调用者能响应结果。
对于非阻塞情形，同步非阻塞是观察者定期主动的去查看目标对象状态；异步非阻塞是目标对象状态改变后去通知观察者做出相应处理。
集群节点击举
消息队列
在计算机科学中，消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的资料，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。[1]
一个 WIMP 环境像是 Microsoft Windows，借由优先的某些形式（通常是事件的时间或是重要性的顺序）来存储用户产生的事件到一个 事件贮列 中。系统把每个事件从事件贮列中传递给目标的应用程序。
实现
实际上，消息队列常常保存在链表结构中。[2]拥有权限的进程可以向消息队列中写入或读取消息。
目前，有很多消息队列有很多开源的实现，包括JBoss Messaging、JORAM、Apache ActiveMQ、Sun Open Message Queue、RabbitMQ[3]、IBM MQ[4]、Apache Qpid[5]、Apache RocketMQ[6]和HTTPSQS。[7]
优缺点
消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息，这和大多数通信协议是不同的。例如WWW中使用的HTTP协议（HTTP/2之前）是同步的，因为客户端在发出请求后必须等待服务器回应。然而，很多情况下我们需要异步的通信协议。比如，一个进程通知另一个进程发生了一个事件，但不需要等待回应。但消息队列的异步特点，也造成了一个缺点，就是接收者必须轮询消息队列，才能收到最近的消息。
和信号相比，消息队列能够传递更多的信息。与管道相比，消息队列提供了有格式的数据，这可以减少开发人员的工作量。[2]但消息队列仍然有大小限制。
消息队列除了可以当不同线程或进程间的缓冲外，更可以透过消息队列当前消息数量来侦测接收线程或进程性能是否有问题。
