ZooKeeper之基础概念（一）

之前在项目中使用过zooKeeper，但是只是简单的应用和配置，这当然不能满足我这渴望求知的心，于是我打算重新完整深入学习一下ZooKeeper，做到知其然知其所以然！

ZooKeeper是什么？

中心观点：它可以在分布式系统中协作多个任务。

在计算机发展初期，所有的程序运行和计算都在同一台计算机上，服务也相对简单，但是随着计算机的告诉发展以及各种服务的复杂度不断提升，单体应用已经不能满足实际需求，应用也变成由多个主机同时运行。

对于开发人员来说，精力已经不能简单的放在业务逻辑的开发上，还要分出更多的精力去协同一个应用中多个程序相互合作。人的精力是有限的，当开发一个不可靠的统一协调器去处理这些问题，那么很可能会引发单点问题。

所以Zookeeper出现了，它保证自身的可靠性，并且使开发人员专注于业务逻辑开发。它提供一组简单的API，使得开发人员可以选举主节点，管理组内成员关系，管理元数据等。ZooKeeper包括一个应用开发库（提供了Java和C两种语言的API），和一个用Java实现的服务组件。ZooKeeper的服务组件运行在一组专用服务器上，保证了高容错性和可扩展性。

ZooKeeper怎么协调多个任务？

协调包含两个方面

协作：协作意味着多个进程需要一同处理某些事情，一些进程采取某些行动使得其他进程可以继续工作。在典型的主-从工作模式中，从节点处于空闲状态时会通知主节点可以接受工作，于是主节点就会分配任务给从节点。

管理竞争：与协作不同，它指的是两个进程不能同时处理工作的情况，一个进程必须等待另一个进程。同样在主-从工作模式中，我们想有一个主节点，但是很多进行都想成为主节点，因此我们需要实现互斥排他锁。可以认为获取主节点身份的过程其实就是获取锁的过程，获得主节点控制权锁的进程就是主节点进程。

ZooKeeper不适用场景

ZooKeeper适合管理应用协作的关键数据，不适合作为海量数据存储。因此在设计应用时，最佳实践是应该将应用数据和协同数据独立开。

构建分布式系统需要注意问题

消息延迟：消息传输会发生任意延迟，当网络发生拥堵的时候，先发送的消息未必会先完成发送

处理器性能：操作系统的调度和超载也可能导致消息处理的任意延迟。进程之间发送消息时，延迟时间约等于发送端消耗时间，传输时间，接收端处理时间的总和。

时钟偏移：处理器时钟并不可靠，它们之间也会发生任意的偏移。因此，依赖处理器时钟也许会

主从应用

对ZooKeeper来说，这种架构非常具有代表性。要实现主-从模式的系统，我们必须解决下面这些问题：

主节点崩溃：如果主节点发生错误，那么系统将无法分配新的任务或重新分配已失败的错误。

主节点失效时，需要有一个备份主节点来接管主节点的角色。新的主节点不能直接接管新的请求，首先需要恢复到旧的主节点崩溃时的状态，我们不能依靠崩溃的旧主节点来获取这些信息，而需要从ZooKeeper获取。

其中会遇到这样的问题。当主节点有效，但是由于消息发生延迟（可能由于负载过高，网络延迟），备份主节点将会接管成为主节点的角色来执行程序，成为第二个主节点。并且有可能一些从节点无法同之前的主节点进行通信，这些从节点可能会与第二个主要节点建立主从关系。这个场景导致的问题，我们一般称之为脑裂(splitbrain)。描述的是系统中多个部分开始独立工作，导致整体行为不一致。

从节点崩溃：如果从节点崩溃，那么无法完成已分配的任务。

主节点需要具备检测从节点是否崩溃的能力。一般客户端向主节点提交任务，然后主节点将任务分配给有效的从节点，从节点执行完任务后会向主节点报告执行状态。一个从节点崩溃，也许它已经执行了部分任务，也许全部执行，但没有报告结果。如果整个过程还有其他作用，还需要机制来恢复之前的状态。

通信故障：如果通信发生故障，那么主节点无法未从节点分配新的任务。

如果一个从节点与主节点的网络连接断开，重新分配一个任务可能会导致两个从节点执行相同的任务。需要根据任务是否允许多次执行，判断是否需要处理这种情况。对任务加锁并不能保证一个任务被执行多次，因为多个从节点执行同一个任务没有步骤交错，因此需要”仅一次“和”最多一次“语义学来处理类似情况。