（一）、Zokeeper简介

1. Zookeeper是什么?
   ❶Zookeeper是一个高效的分布式协调服务，它暴露了一些公用服务，比如命名/配置管理/同步控制/群组服务等，我们可以使用ZK来实现比如达成共识/集群管理/leader选举等。
   ❷Zookeeper是一个高可用的分布式管理与协调框架，基于ZAB算法（原子消息广播协议）的实现，该框架能够很好的保证分布式环境中数据的一致性，也正是基于这样的特性，使得ZK成为了解决分布式一致性问题的利器。
   ❸顺序一致性： 从一个客户端发起的事务请求，最终将会严格的按照其发起的顺序被应用到ZK中去。
   ❹原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有的机器都成功应用了某一事务，要么都没有应用，一定不会出现部分机器应用了该事务，而另一部分没有应用的情况。
   ❺单一视图： 无论客户端连接的是哪一个ZK服务器，其看到的服务器端数据模型都是一致的。
   ❻可靠性： 一旦服务器成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务器端状态将会被一致保留下来，除非有另外一个事务对其更改。
   ❼实时性： 通常所说的实时性就是指一旦事务被成功应用，那么客户端就能立刻从服务器上获取变更后的新数据，ZK仅仅能保证在一段时间内，客户端最终一定能从服务器端获取最新的数据状态
2. Zookeeper设计目标
   ❶目标一：简单的数据结构，ZK就是以简单的树形结构来进行相互协调的（也叫树形名字空间）。
   ❷目标二：可以构建集群，一般ZK集群通常由一组机器构成，一般3~5台机器就可以组成一个ZK集群了，只要集群中超过半数以上的机器能够正常工作，那么整个集群就能够正常对外提供服务。
   ❸目标三：顺序访问，对于来自每一个客户端的每一个请求，ZK都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用ZK的这个特性来实现更高层次的同步。
   ❹目标四：高性能，由于ZK将全量数据存储在内存中，并直接服务与所有的非事务请求，因此尤其是在读操作作为主的场景下性能非常突出，在JMater压力测试下（100%读请求场景下），其结构大约在12~13W的QPS。
3. Zookeeper的数据模型
   ❶每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1。
   ❷znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL类型的目录节点不能有子节点目录。
   ❸znode是由版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据。
   ❹znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode也将自动删除，ZK的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个链接状态称为session，如果znode是临时节点，这个session失败，znode也就删除了。
   ❺znode的目录名可以自动编号，如App1已经存在，再创建的话，将会自动命名为App2。
   ❻znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是ZK的核心特性。
4. Zookeeper组成
   ZK server根据其身份特性分为三种：leader，Follower，Observer，其中Follower和Observer又统称Learner（学习者）。
   Leader：负责客户端的writer类型请求。
   Follower：负责客户端的reader类型请求，参与leader选举等。
   Observer：特殊的"Follower"，其可以接受客户端reader请求，但不参与选举（扩容系统支撑能力，提高了读取速度，因为它不接受任何同步的写入请求，只负责与leader同步数据）。
5. 典型应用场景
   ZK从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZK就将负责通知已经在ZK上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式
   ❶配置管理：配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会配到这样的需求：如机器的配置列表、运行时的开关配置，数据库配置信息等，这些全局配置信息通常具备以下3个特性：
   ①数据量比较小
   ②数据内容在运行时动态发生变化
   ③集群中各个节点共享信息，配置一致
   ❷集群管理：ZK不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个"总管"，让这个总管来管理集群，这就是ZK的另一个功能Leader，并实现集群容错功能。
   ①希望知道当前集群中究竟有多少机器工作
   ②对集群中每天集群的运行时转态进行数据收集
   ③对集群中每台集群进行上下线操作
   ❸发布与订阅：ZK是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用它来进行分布式数据的发布与订阅。
   ❹数据库切换：比如我们初始化ZK的时候读取其节点上的数据库配置文件，当配置一旦发生变更时，ZK就能帮助我们把变更的通知发送到各个客户端，每个在接收到这个变更通知后，就可以从最新数据的获取。
   ❺分布式日志收集：我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理。
   ❻ZK的特性就是在分布式场景下高可用，但是原生的API实现分布式功能非常困难，团队去实现太浪费时间，即使实现了也未必稳定，那么可以采用第三方的客户端的完美实现，比如Curator框架。
6. java操作Zookeeper
   创建节点（znode）方法：create：
   提供了两套创建节点的方法，同步和异步创建节点方式。
   同步方式：
   参数1，节点路径（名称）：/nodeName（不允许递归创建节点，也就是说在父节点不存在的情况下，不允许创建子节点）
   参数2，节点内容： 要求类型是字节数组（也就是说，不支持序列化方式，如果需要实现序列化，可使用java相关序列化框架，如Hessian，Kryo框架）
   参数3，节点权限： 利用los.OPEN_ACL_UNSAFE开发权限即可。（这个参数一般在权限没有太高要求的场景下，没必要关注）
   参数4，节点类型： 创建节点的类型：CreateMode.*，提供四种节点类型
   ❶PERSISTENT（持久节点）
   ❷PERSISTENT_SEQUENTIAL（持久顺序节点）
   ❸EPHEMERAL（临时节点）
   ❹EPHEMEARL_SEQUENTIAL（临时顺序节点）
   异步方式：（在同步参数基础上增加两个参数）
   参数5，注册一个异步回调函数，要实现AsynCallBack.StringCallBack接口，重写processResult（int rc，String path，Object ctx，String name）方法，当节点创建完毕后执行此方法。
   ❶rc： 为服务端响应码0表示调用成功，-4表示端口连接，-110表示指定节点存在，-112表示会话已经过期
   ❷path： 接口调用时传入API的数据节点的路径参数
   ❸ctx： 为调用接口传入API的ctx值
   ❹name： 实际在服务器端创建节点的名称
   参数6，传递给回调函数的参数，一般为上下文（Context）信息