001_ZooKeeper简介

1. ZooKeeper是一个高性能的分布式应用程序协调服务。它暴露了一些常用服务, 例如命名注册, 配置管理, 同步控制和群组服务。我们可以使用ZooKeeper来实现达成共识, 集群管理, 领导者选举和制定协议。您可以根据自己的特定需求在此基础上进行构建。

2. ZooKeeper的目标就是封装好复杂易出错的关键服务, 将简单易用的接口和性能高效、功能稳定的系统提供给用户。

3. ZooKeeper是以Fast Paxos算法为基础的, Paxos算法存在活锁的问题, 即当有多个proposer交错提交时, 有可能互相排斥导致没有一个proposer能提交成功, 而Fast Paxos做了一些优化, 通过选举产生一个leader(领导者), 只有leader才能提交proposer, 具体算法可见Fast Paxos。因此, 要想弄懂ZooKeeper首先得对Fast Paxos有所了解。

4. ZooKeeper数据结构

4.1. 在ZooKeeper中, znode是一个跟Unix文件系统路径相似的节点, 可以以key-value的形式往这个节点存储或获取数据。名称key是由斜线/分割的一系列路径元素, ZooKeeper 名称空间中的每个节点都是由一个路径标识的。

4.2. 如果在创建znode时Flag设置为EPHEMERAL, 那么当创建这个znode的节点的客户端和ZooKeeper失去连接后, 这个znode也将自动删除。ZooKeeper客户端和服务器采用长连接方式, 每个客户端和服务器通过心跳来保持连接, 这个连接状态称之为会话(Session), 如果znode是临时节点, 当Session结束的时候, znode也不存在了, 即临时节点是会话级别的。

4.3. znode可以有子节点目录, 被标记为EPHEMERAL的节点不能有子节点目录。

4.4. znode是有版本的, 每个znode中存储的数据可以有多个版本, 也就是一个访问路径可以存储多份数据。

4.5. ZooKeeper使用Watcher察觉事件信息。当客户端接收到事件信息, 比如连接超时、节点数据改变、子节点改变, 可以调用相应的行为来处理数据。

5. ZooKeeper组成

5.1. ZooKeeper Server根据其身份特性分成三种: Leader, Follower和Observer。

5.2. Leader: 负责客户端的Writer类型请求。

5.3. Follower: 负责客户端Reader类型请求, 参与Leader选举等。

5.4. Observer: 特殊的Follower, 其可以接受客户端Reader请求, 但不参与选举。

6. ZooKeeper应用场景

6.1. ZooKeeper从设计模式角度来看, 是一个基于观察者模式设计的分布式服务管理框架, 它负责存储和管理大家都关心的数据, 然后接受观察者的注册, 一旦这些数据的状态发生变化, ZooKeeper就将负责通知已经在ZooKeeper上注册的那些观察者做出相应的反应。

6.2. ZooKeeper是一个典型的分布式数据一致性的解决方案, 分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

6.3. 配置管理: 在分布式应用环境中很常见, 比如我们平常的应用系统中, 经常会碰到这样的需求: 如机器的配置列表、运行时的开关配置、数据库配置信息等。这些全局配置信息通常具备以下三个特征:

• 数据量比较小。
• 数据内容在运行时动态发生变化。
• 集群中各个集群共享信息, 配置一致。

6.4. 集群管理: ZooKeeper不仅能够帮你维护当前的集群中机器的服务状态, 而且能够帮助你选出一个总管, 让这个总管来管理集群, 这就是ZooKeeper的另外一个功能Leader, 并实现集群容错功能。

• 希望知道当前集群中究竟有多少机器工作。
• 对集群中每天集群的运行时状态进行数据收集。
• 对集群中每台集群进行上下线操作。

7. CAP原则

7.1. 一致性(C): 在分布式系统中的所有数据备份, 在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

7.2. 可用性(A): 保证每个请求不管成功或者失败都有响应。

7.3. 分区容错性(P): 系统中任意信息的丢失或失败不会影响系统的继续运作。

7.4. 一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

7.5. 在这三个基本需求中, 最多只能同时满足其中的两项, P是必须的, 因此只能在CP和AP中选择。zookeeper保证的是CP, 对比spring cloud系统中的注册中心eruka实现的是AP。

8. BASE理论

8.1. BASE是Basically Available(基本可用)、Soft-state(软状态)和Eventually Consistent(最终一致性)三个短语的缩写。

8.2. 基本可用: 在分布式系统出现故障, 允许损失部分可用性(服务降级、页面降级)。

8.3. 软状态: 允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的data replication(数据备份节点)之间的数据更新可以出现延时的最终一致性。

8.4. 最终一致性: data replications经过一段时间达到一致性。

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