Zookepeer心得篇一：异步通信理论

   为什么使用Zookepeer

   伴随着大数据与云计算的告诉发展，单服务器变的越来越显单薄。相对于在单台服务器上进行开发，如何让应用多个相互独立的程序之间进行有效的系统工作成为开发运维中的一大难点。开发这样的程序必须考虑好多程序之间的协同工作问题，还要考虑好程序本身的应用逻辑。Zookepeer的设计保证了应用程序的健壮性，使得开发人员可以花费大量的时间在应用程序的设计本身上。Zooleper通过文件系统的启发，实现了一套简单的Api，使得开发人员可以实现通用的协作任务，包括包括选举主节点、管理组内成员关系、管理元数据等。ZooKeeper包括一个应用开发库（主要提供Java和C两种语言的API）和一个用Java实现的服务组件。ZooKeeper的服务组件运行在一组专用服务器之上，保证了高容错性和可扩展性。

抽象上的Zookepeer

在使用Zookepeer进行开发时，开发人员应该把开发的应用程序当做连接在Zookepeer服务器上的客户端，它们通过ZooKeeper的客户端API连接到ZooKeeper服务器端进行相应的操作。Zookeep的客户端API功能强大，其中包括：

1·保障强一致性、有序性和持久性。
2·实现通用的同步原语的能力。(原语:是由若干条指令组成的，用于完成一定功能的一个过程。原语的执行是不可以被中断的过程。)
3·在实际分布式系统中，并发往往导致不正确的行为。ZooKeeper提供了一种简单的并发处理机制。

        分布式系统中的进程通信有两种选择：直接通过网络进行信息交换，或读写某些共享存储。ZooKeeper使用共享存储模型来实现应用间的协作和同步原语。对于共享存储本身，又需要在进程和存储间进行网络通信。我们强调网络通信的重要性，因为它是分布式系统中并发设计的基础。

在真实的系统中，我们需要特别注意以下问题：

消息延迟

 消息传输可能会发生任意延迟，比如，因为网络拥堵。这种任意延迟可能会导致不可预期的后果。比如，根据基准时钟，进程P先发送了一个消息，之后另一个进程Q发送了消息，但是进程Q的消息也许会先完成传送。

 处理器性能

操作系统的调度和超载也可能导致消息处理的任意延迟。当一个进程向另一个进程发送消息时，整个消息的延时时间约等于发送端消耗的时间、传输时间、接收端的处理时间的总和。如果发送或接收过程需要调度时间进行处理，消息延时会更高。

时钟偏移 

  使用时间概念的系统并不少见，比如，确定某一时间系统中发生了哪些事件。处理器时钟并不可靠，它们之间也会发生任意的偏移。因此，依赖处理器时钟也许会导致错误的决策。关于这些问题的一个重要结果是，在实际情况中，我们很难判断一个进程是崩溃了还是某些因素导致了延时。没有收到一个进程发送的消息，可能是该进程已经崩溃，或是最新消息发生了网络延迟，或是其他情况导致进程延迟，或者是进程时钟发生了偏移。我们无法确定一个被称为异步（asynchronous）的系统中的这些区别。  使用时间概念的系统并不少见，比如，确定某一时间系统中发生了哪些事件。处理器时钟并不可靠，它们之间也会发生任意的偏移。因此，依赖处理器时钟也许会导致错误的决策。关于这些问题的一个重要结果是，在实际情况中，我们很难判断一个进程是崩溃了还是某些因素导致了延时。没有收到一个进程发送的消息，可能是该进程已经崩溃，或是最新消息发生了网络延迟，或是其他情况导致进程延迟，或者是进程时钟发生了偏移。我们无法确定一个被称为异步（asynchronous）的系统中的这些区别。

         数据中心通常使用大量统一的硬件。但即使在数据中心，我们需要发现这些问题对应用服务带来的影响，因为一个应用服务使用了多代的硬件，甚至对于同一批次的硬件也存在微小但显著的性能差异。所有这些事情使分布式系统设计师的生活越来越复杂。
ZooKeeper的精确设计简化了这些问题的处理，ZooKeeper并不是完全消除这些问题，而是将这些问题在应用服务层面上完全透明化，使得这些问题更容易处理。ZooKeeper实现了重要的分布式计算问题的解决方案，直观为开发人员提供某种程度上实现的封装，至少这是我们一直希望的。