ZooKeeper的概念和基础
简介
ZooKeeper是Google的Chubby项目的开源实现，它曾作为Hadoop的子项目，在大数据领域得到广泛应用。ZooKeeper以Fast Paxos算法为基础，同时为了解决活锁问题，对Fast Paxos算法进行了优化，因此也可以广泛用于大数据之外的其他分布式系统，为大型分布式系统提供可靠的协作处理功能。Apache ZooKeeper旨在减轻构建健壮的分布式系统的任务。ZooKeeper基于分布式计算的核心概念而设计，主要目的是给开发人员提供一套容易理解和开发的接口，从而简化分布式系统构建的任务。
在大数据和云计算盛行的当下，应用服务由很多个独立的程序组成，这些独立的程序则运行在形形色色的一组计算机上。相对于开发单台计算机上运行程序，如何让一个应用中多个独立的程序协同工作是一件非常困难的事情。ZooKeeper的设计保证了多个程序协同工作的逻辑的健壮性，使得应用开发人员可以更多关注应用本身的逻辑。ZooKeeper从文件系统API得到启发，提供了一组简单的API，使得开发人员可以实现通用的协同任务，包括选举主节点、管理组内成员关系、管理元数据等。
ZooKeeper包括一个应用开发库（主要提供Java和C两种语言的API）和一个用Java实现的服务组件。ZooKeeper的服务组件运行在一组专用服务器上，保证了高容错性和可扩展性。当开发人员使用ZooKeeper进行开发时，开发人员设计的那些应用往往可以看成一组连接到ZooKeeper服务器端的客户端，它们通过ZooKeeper的客户端API连接到ZooKeeper服务器端进行相应的操作。应用服务的数据包括应用数据和协同数据，ZooKeeper管理的就是协同数据。例如，网络邮箱服务的应用数据就是电子邮件的内容，而从邮箱到某台邮箱服务器之间的映射关系就是协同数据（或称元数据）。
ZooKeeper的使命
ZooKeeper的系统功能围绕一条主线：在分布式系统中协作多个任务。一个协作任务是指一个包含多个进程的任务。这个任务可以是为了协作或者是为了管理竞争。协作意味着多个进程需要一同处理某些事情，一些进程采取某些行动使得其他进程可以继续工作。比如，在典型的主从工作模式中，从节点处于空闲状态时会通知主节点可以接受工作，于是主节点就会分配任务给从节点。竞争是指两个进程不能同时处理工作的情况，一个进程必须等待另一个进程。同样在主从模式中，多个进程都想被选举为主节点，因此需要实现互斥排他锁(mutual exclusion)。实际上，我们可以认为获取主节点身份的过程其实就是获取锁的过程，获得主节点控制权锁的进程即主节点进程。
ZooKeeper之前的其他一些系统采用分布式锁管理器或分布式数据库来实现协作。实际上，ZooKeeper从这些系统中借鉴了很多概念。但是，ZooKeeper的设计更专注于任务写作，并不提供任何锁的接口或通用存储数据接口。同时，ZooKeeper没有给开发人员强加任何特殊的同步原语，使用非常灵活。
ZooKeeper中实现了一组核心操作，通过这些可以实现很多常见分布式应用的任务。你知道有多少应用服务采用主节点方式或进程响应跟踪方式？虽然ZooKeeper并没有为你实现这些任务，也没有为应用实现主节点选举，或者进程存活与否的跟踪的功能，但是，ZooKeeper提供了实现这些任务的工具，对于实现什么样的协同任务，由开发人员自己决定。
通过ZooKeeper构建分布式系统
分布式系统是同时跨越多个物理主机，独立运行的多个软件组件所组成的系统。使用一个独立的协调组件有几个重要的好处：首先，我们可以独立地设计和实现该组件，这样独立的组件可以跨多个应用共享。其次，系统架构师可以简化协作方面的工作，这些并不是琐碎的小事。软件组件以操作系统的进程的方式运行，很多时候还涉及多线程的执行。
ZooKeeper的服务端和客户端也是以进程的方式运行，一个单独的物理主机（无论是一个独立主机还是一个虚拟环境中的操作系统）上运行一个单独的应用进程，尽管进程可能采用多线程运行的方式，以便利用现代处理器的多核(multicore)处理能力。
分布式系统中的进程通信有两种选择：直接通过网络进行信息交换，或读写某些共享存储。ZooKeeper使用共享存储模型来实现应用间的协作和同步原语。对于共享存储本身，又需要在进程和存储间进行网络通信。 所以，网络通信是分布式系统中并发设计的基础。
分布式系统存在的问题
分布式系统存在的问题：消息延迟、处理器性能、时钟偏移。消息传输可能会发生任意延迟，比如，因为网络拥堵。这种任意延迟可能会导致不可预期的后果。操作系统的调度和超载也可能导致消息处理的任意延迟。当一个进程向另一个进程发送消息时，整个消息的延时时间约等于发送端消耗的时间、传输时间、接收端的处理时间的总和。如果发送或接收过程需要调度时间进行处理，消息延时会更高。使用时间概念的系统并不少见，比如，确定某一时间系统中发生了哪些事件。处理器时钟并不可靠，它们之间也会发生任意的偏移。因此，依赖处理器时钟也许会导致错误的决策。ZooKeeper的精确设计简化了这些问题的处理，ZooKeeper并不是完全消除这些问题，而是将这些问题在应用服务层面上完全透明化，使得这些问题更容易处理。ZooKeeper实现了重要的分布式计算问题的解决方案，直观为开发人员提供某种程度上实现的封装。
主从应用
一般主从架构，主节点进程负责跟踪从节点状态和任务的有效性，并分配任务到从节点。
主节点崩溃 --> 选举主节点
主节点失效时，我们需要有一个备份主节点(backup master)。当主要主节点崩溃时，备份主节点接管主要主节点的角色，进行故障转移，然而，这并不是简单开始处理进入主节点点的请求。新的主要主节点需要能够恢复到旧的主要主节点崩溃时的状态。对于主节点状态的可恢复性，我们不能依靠从已经崩溃的主节点来获取这些信息，而需要从其他地方获取，也就是通过ZooKeeper来获取。
假如主节点有效，备份主节点却认为主节点已经崩溃。这种错误的假设可能发生在以下情况，例如主节点负载很高，导致消息任意延迟，备份主节点将会接管成为主节点的角色，执行所有必需的程序，最终可能以主节点的角色开始执行，成为第二个主要节点。更糟的是，如果一些从节点无法与主要主节点通信，如由于网络分区错误，这些从节点可能会停止与主要主节点的通信，而与第二个主要主节点建立主从关系。针对这个场景导致的问题，成为脑裂：系统中两个或多个部分开始独立工作，导致整体行为不一致性。
从节点崩溃 --> 跟踪有效的从节点
客户端向主节点提交任务，之后主节点将任务派发到有效的从节点中。从节点接收到派发的任务，执行完这些任务后会向主节点报告执行状态。主节点下一步会将执行结果通知给客户端。如果从节点崩溃了，所有已派发给这个从节点且尚未完成的任务需要重新派发。其中首要需求是让主节点具有检测从节点的崩溃的能力。主节点必需能够检测到从节点的崩溃，并确定哪些从节点是否有效以便派发崩溃节点的任务。一个从节点崩溃时，从节点也许执行了部分任务，也许全部执行完，但没有报告结果。如果整个运算过程产生了其他作用，我们还有必要执行某些恢复过程来清楚之前的状态。
通信故障
如果一个从节点与主节点的网络连接断开，重新分配一个任务可能会导致两个从节点执行相同的任务。如果一个任务允许多次执行，我们在进行任务再分配时可以不用验证第一个从节点是否完成了该任务。如果一个任务不允许，那么我们的应用需要适应多个从节点执行相同任务的可能性。
通信故障导致的另一个重要问题是对锁等同步原语的影响。因此节点可能崩溃，而系统也可能网络分区，锁机制也会阻止任务的继续执行。因此ZooKeeper也需要实现处理这些情况的机制。首先，客户端可以告诉ZooKeeper某些数据的状态是临时状态；其次，同时ZooKeeper需要客户端定时发送是否存活的通知，如果一个客户端未能及时发送通知，那么所有从属于这个客户端的临时状态的数据将全部被删除。通过这两个机制，在崩溃或通信故障发生时，我们就可以预防客户端独立运行而发生的应用宕机。
维护应用元数据
- 组成员关系管理 主节点必须具体知道哪一个从节点可以执行任务的能力
- 元数据管理 主节点和从节点必须具有通过某种可靠的方式来保存分配状态和执行状态的能力。