客户端与服务端之间任何交互操作都与会话息息相关，如临时节点的生命周期、客户端请求的顺序执行、Watcher通知机制等。Zookeeper的连接与会话就是客户端通过实例化Zookeeper对象来实现客户端与服务端创建并保持TCP连接的过程。

服务端服务端整体架构如下 Zookeeper服务器的启动，大致可以分为以下五个步骤 配置文件解析。 初始化数据管理器。 初始化网络I/O管理器。 数据恢复。 对外服务。 单机版服务器启动单机版服务器的启动其流程图如下 上图的过程可以分为预启动和初始化过程。 1. 预启动 统一由Quorum ...

客户端组成Zookeeper客户端主要由如下核心部件构成。 　　1. **Zookeeper实例**，客户端入口。 　　2. **ClientWatchManager**， 客户端Watcher管理器。 　　3. **HostProvider**，客户端地址列表管理器。 　　4 ...

本节将从数据模型、节点特性、版本、watch和ACL五个方面来讲述 zookeeper 的系统模型。

Zookeeper是一个高可用的分布式数据管理和协调框架，并且能够很好的保证分布式环境中数据的一致性。在越来越多的分布式系统（Hadoop、HBase、Kafka）中，Zookeeper都作为核心组件使用。

Leader选举概述

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

1. 服务器初始化启动。
2. 服务器运行期间无法和Leader保持连接。

下面就两种情况进行分析讲解。

Zookeeper 概述

　　Zookeeper是一个开源的分布式协调服务，其设计目标是将那些复杂的且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一些列简单的接口提供给用户使用。其是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/发布、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。其可以保证如下 分布式一致性特性。

1. 顺序一致性，从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中去。
2. 原子性，所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用。
3. 单一视图，无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。
4. 可靠性，一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行了变更。
5. 实时性，Zookeeper保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

Zookeeper部署

Zookeeper有三种运行形式：集群模式、单机模式、伪集群模式。

在第二小节，我们学习了如何使用 Work Queues 将耗时的任务分发到多个 worker 处理。

但是，当我们需要在远程机计算机上运行一个函数，之前的例子就无法满足了。这种模式一般被称为 远程方法调用（Remote Procedure Call or RPC）。

在这一节，我们将使用 RabbitMQ 来构建一个 RPC 系统：一个客户端和一个可伸缩的 RPC 服务器。因为我们没有耗时的任务需要分布式计算，所以我们将创建一个虚构的 RPC Server 来返回 斐波那契数据列。

在前面的小结，我们使用了 direct exchange 代替盲目广播的 fanout exchagne 使得接受者能够选择需要接收的日志消息。但 direct exchange 还是存在局限性——它无法根据多标准路由。

日志系统中，我们可能不止需要根据日志级别订阅消息，同时也需要基于 ”日志发送来源“ 来过滤。你可能从 syslog unix tool 得知可以通过日志的 严重级别 severity (info/warn/crit…) 和 来源设备 facility (auth/cron/kern…) 来路由日志。

这会基于我们更多的灵活性 —— 我们也许只想监听来自 ‘cron’ 的 critical errors 和 所有来自 ‘kern’ 的日志。