重识Zookeeper（二）：zookepper基础

本文大多数为理论，枯燥乏味，但是确是zookeeper的基础，只有理解这些基础才能学好zookeeper，笔者尽量用通俗的语言来解释zookeeper的接触内容：
1，zookeeper的API和文件树
- 在一个涉及到相互协作的系统中，例如主-从模式的系统中，一般相互通讯会用到原语，即系统的自定义语言，实现相互的通讯，但是这种模式有一个明显的弊端，即原语可能不够实现功能，这样除非能提供一份全面详细的原语列表，或者是扩展性的API才行。
- zookeeper使用的是另外一种方式，不暴露原语，而是维护一个文件树，其他系统通过操作树与zookeeper进行交互，这也就是zookeeper的核心之一：文件树。
- 文件树可以简单的理解为一个文件系统，但并不完全一致，因为这些树最后都要绑定的是一个数据，类似于一个文件，文件系统中文件夹下可以没有文件，但是zookeeper的“文件夹”下必须有“文件”而且唯一。这些文件的路径在zookeeper中称为znode.
- 既然zookeeper提供了文件树，必然会提供一些命令去维护文件树，也就是zookeeper的API了，有几个方法，假如我们是zookeeper的创建者，我们会提供哪几种方法去维护文件树呢？
创建、删除、修改、获取肯定是必须的，除此之外，zookeeper也提供了检查节点是否存在，获取子节点列表两个方法一共六个API， 当然在java实现中zookeeper的Client实现了其他的方法，都是对这几个方法的组合。这些都属于zookeeper的命令，后续会有专门的文章说这个。
2，zookeeper的node类型分类
- znode 在是否永远存在方面分为两种类型，第一种是永久的（persistent），第二种是对应的临时节点（ephemeral） ，从字面是也很好理解，第一种是只要创建了，不手动删除就会永久存在，第二种节点在当zookeeper挂机，或者客户端失去连接的时候，节点会自动删除，java客户端在创建节点的时候会指定节点类型，后续会有例子。节点还可以设置是否有序（sequential），创建有序节点的时候，会自动追加序号，所以整个来讲节点分为四种： 永久的，临时的，永久且有序，临时且有序。
3，zookeeper的监听-通知模型
- 使用zookeeper一般是远程连接的，但是如果每次客户端都去便利这些节点看数据有没有变化效率明显太低了，zookeeper实现的是 “监视-通知”模型，即客户端会在节点处设置一个Watcher（监听器），当节点处数据有变化的时候，zookeeper会通知这些设置了监听的客户端，客户端来固定的路径下取数据，提高了效率，这种模型也是zookeeper的核心之一。
4，zookeeper集群
- zookeeper分为两种模式，独立模式和仲裁模式，可以直接翻译为单击模式和集群模式，单击模式并不能体现出zookeeper的优势，一般可以忽略，主要是仲裁模式： 仲裁模式即集群模式下zookeeper的设计者需要第一个解决的问题就是访问不通zookeeper时候的数据一致性的问题，即集群下所有节点存贮的数据都是一样的，文件树的结构是相同的，节点崩溃后启动，可以重新同步其他节点的数据，为了实现这个功能，zookeeper用了它的核心算法ZAB（分布式一致性算法），第二个难点就是选举leader,这两个算法也是zookeeper最最核心的东西。
5，zookeeper会话
- zookeeper会话：zookeeper的会话是指客户端到服务端的一次请求，zookeeper接受请求到返回响应为一次完整的生命周期，为了完成这个过程，zookeeper定义了一套会话的生命周期，COMMECTING、CONNECTION 、CLOSED 、NOT_CONNECTION, zookeeper 也是通过对处于不同生命周期的会话做不同的管理，达到“高可用”的目标的