查看“Zookeeper：概述”的源代码

[[category:Zookeeper]]

== 关于 ==
ZooKeeper 是一种'''分布式协调服务'''，用于'''管理大型主机'''。
: 在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper 通过其简单的架构和 API 解决了这个问题。ZooKeeper 允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。

== 分布式 ==
<pre>
分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成。

通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为“集群”，而在集群中运行的每台机器被称为“节点”。
</pre>

分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。 客户端应用程序是与分布式应用进行交互的工具：
: [[File:Zookeeper：分布式应用.png|500px]]

=== CAP 理论 ===
CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：
# '''一致性'''（Consistency）：在分布式环境中，一致性是指'''数据在多个副本之间是否能够保持一致'''的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
# '''可用性'''（Availability）：'''每次请求都能获取到正确的响应'''，但是不保证获取的数据为最新数据。
# '''分区容错性'''（Partition tolerance）：分布式系统在遇到任何'''网络分区故障的时候'''，仍然需要能够保证'''对外提供满足一致性和可用性的服务'''，除非是整个网络环境都发生了故障。


一个分布式系统最多只能同时以上的两项：'''P''' 是必须的，因此只能在 '''CP''' 和 '''AP''' 中选择。
* zookeeper 保证的是 '''CP'''；
* 对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。

: [[File:分布式：CAP理论.png|400px]]

=== BASE 理论 ===
BASE 理论：
# '''基本可用'''（Basically Available）：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。
# '''软状态'''（Soft-state）：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。
#* 这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。
# '''最终一致性'''（Eventually Consistent）：data replications 经过一段时间达到一致性。


BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：'''我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性'''。

== Zookeeper ==
<pre>
ZooKeeper 是 Apache 软件基金会的一个软件项目，它为大型分布式计算提供开源的'''分布式配置服务'''、'''同步服务'''和'''命名注册'''。

ZooKeeper 框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper 成为 Hadoop，HBase 和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase 使用 ZooKeeper 跟踪分布式数据的状态。
</pre>

ZooKeeper 是一个'''分布式协调服务'''的开源框架。主要用来解决分布式集群中应用系统的'''一致性'''的问题。（例如怎样避免同时操作同一数据造成脏读的问题）

Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。


* ZooKeeper 本质上是一个'''分布式的小文件存储系统'''。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而来维护和监控你存储的数据的状态变化。将通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
* ZooKeeper 的架构通过冗余服务实现高可用性。
* 分布式应用程序可以基于它实现诸如：'''数据发布/订阅'''、'''负载均衡'''、'''命名服务'''、'''分布式协调/通知'''、'''集群管理'''、'''Master 选举'''、'''分布式锁'''和'''分布式队列'''等功能。

=== 架构图 ===
: [[File:Zookeeper：架构图.png|800px]]

# '''Leader'''： ZooKeeper 集群工作的核心。
#* 事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务的调度者。
#* 对于 create，setData，delete 等有写操作的请求，则需要统一转发给 leader 处理，leader 需要决定编号、执行操作，这个过程称为一个'''事务'''。
# '''Follower'''： 处理客户端非事务（读操作）请求。
#* 转发事务请求给 Leader；
#* 参与集群；
#* leader 选举投票 2n-1 台可以做集群投票。
# '''Observer'''： 观察者角色。
#* 观察 ZooKeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器处理。
#* 不会参与任何形式的投票只提供服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

=== Zookeeper的主从与主备 ===
# '''主从'''：主节点少，从节点多，主节点分配任务，从节点具体执行任务。
# '''主备'''：主节点与备份节点，主要用于解决我们主机节点挂掉以后，如何选出来一个新的主节点的问题，保证我们的主节点不会宕机。

很多时候，主从与主备没有太明显的分界线，很多时候都是一起出现。

=== Zookeeper 特性 ===
* 全局数据的一致：每个 server 保存一份相同的数据副本，client 无论链接到哪个 server，展示的数据都是一致的。
* 可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
* 顺序性：包括全局有序和偏序两种：
** 全局有序：是指如果在一台服务器上消息 a 在消息 b 前发布，则在所有 server 上消息 a 在消息 b 前被发布；
** 偏序：是指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必须将排在 b 前面
* 数据更新原子性：一次数据更新要么成功，要么失败，不存在中间状态。
* 实时性：ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

=== ZooKeeper 提供的服务 ===
* 命名服务 - 按名称标识集群中的节点。它类似于DNS，但仅对于节点。
* 配置管理 - 加入节点的最近的和最新的系统配置信息。
* 集群管理 - 实时地在集群和节点状态中加入/离开节点。
* 选举算法 - 选举一个节点作为协调目的的leader。
* 锁定和同步服务 - 在修改数据的同时锁定数据。此机制可帮助你在连接其他分布式应用程序（如Apache HBase）时进行自动故障恢复。
* 高度可靠的数据注册表 - 即使在一个或几个节点关闭时也可以获得数据。


ZooKeeper框架提供了一个完整的机制来克服分布式应用程序所有的挑战。
: 竞争条件和死锁使用故障安全同步方法进行处理。
: 数据的不一致性，ZooKeeper使用原子性解析。