1.1
Zookeeper从文件系统API得到启发，提供了一组简单的API，使得开发人员可以实现通用的协作任务，包括选举主节点、管理组内成员关系、管理元数据等。
zookeeper组件运行在一组专用的服务器上，保证了高容错性和可扩展性。
zookeeper系统功能都围绕在一条主线上：它可以在分布式系统中协作多任务。
zookeeper应用：
- apache Hbase中使用它选举一个集群内的主节点，以便跟踪可用的服务器，并保存集群的元数据。
- apache kafka使用它用于检测奔溃，实现主体的发现，并保存主题的生产和消费状态。
zookeeper的客户端API功能强大，其主要包括：
- 保证强一致性、有序性和持久性
- 实现通用的同步原语的能力
- 在实际分布式系统中，并发往往导致不正确的行为，zookeeper提供了一种简单的并发处理机制。
zookeeper不适用于海量数据存储。
分布式系统中的通讯分为两种：一种是直接他通过网络进行信息交换 或者 是写某些共享的存储。zookeeper使用共享存储模型来实现应用间的协作和同步原语。
正式的分布式系统中需要注意几个问题：
- 消息延迟：消息可能由于网络堵塞导致任意的延迟，这种延迟导致不可预期的后果。
- 处理器性能：操作系统的调度和超载也以后能导致消息处理的任意延迟。
- 时钟偏移：使用时间概念的系统并不少见，处理器时钟并不可靠，因此依赖处理器时钟也有可能导致错误的决策。
1.2 主从应用示例
在一个主从架构中，主节点进行负责跟踪从节点状态和任务的有效性，并分配任务到从节点，要实现主从模式的系统，我们必须解决以下三个关键问题：
主节点崩溃：如果主节点发送错误并失效，系统将无法分配新任务或者重新分配已经失败的任务。
从节点奔溃：如果从节点崩溃，已分配的任务将无法完成。
通讯故障：如果主节点和从节点之间无法进行信息交换，从节点将无法得知新任务分配 给自己。
1.2.1主节点失效
主节点失效时，需要一个备份主节点，当主节点崩溃时，备份主节点可以接管主要节点的角色，进行故障转移。
其中还涉及到一个问题，即主节点有效，但是备份主节点认为主节点已经崩溃，这种错误的假设可能发生咋以下情况：例如主节点负载很高的情况下，导致消息任意延迟
还有一种情况，即主节点和备份主节点都任务自己的主节点，这种情况可能是由于网络分区导致的“脑裂”：系统中两个或者多个部分开始独立工作，导致整体行为不一致。
1.2.2从节点失效
从节点崩溃，所有已经派发的任务并且尚未执行的任务都需要重新派发，其中首要需求是让主节点发现检测到从节点的崩溃。
1.2.3通讯故障
如果一个从节点和主节点的网络连接断开，可能是由于网络分区导致的，重新分配一个任务可能导致两个从节点执行相同的任务，如果一个任务允许多次执行，那么我们不用检测第一个从节点是否完成了该任务，如果一个任务不允许重新执行，那么我们就需要适应多个从节点执行相同任务的可能性。
这里需要考虑“仅一次”与“最多一次”的概念。
我们可以通过设置锁或者临时状态来检测任务是否正在执行，其次zookeeper需要客户端定义发送是否存活的通知。通过以上两种方式我们就可以预防客户端独立运行而发生的应用宕机。