1.1-Zookeeper简介
什么是Zookeeper？
Zookeeper是一个高效的分布式协调服务，它暴露了一些公共服务，比如命名/配置/管理/同步控制/群组服务等。我们可以使用ZK来实现比如达成共识/集群管理/leader选举等。
Zookeeper是一个高可用的分布式管理与协调框架，基于ZAB算法（原子消息广播协议）的实现。该框架能够很好地保证分布式环境中数据的一致性。也正是基于这样的特性，使得Zookeeper成为了解决分布式一致性问题的利器。
特性：
1，顺序一致性：从一个客户端发起的事物请求，最终将会严格地按照其发起的顺序被应用到Zookeeper中去。
2，原子性：所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有的机器都成功应用了某一事物，要么就没有应用，一定不会出现部分机器应用了该事物，而另一部分没有应用的情况。
3，单一视图：无论客户端连接的是哪一个zookeeper服务器，其看到的服务器端数据模型都是一致的。
4，可靠性：一旦服务器成功地应用了一个事物，并完成了对客户端的响应，那么该事物所引起的服务器端状态将会被一致保留下来。除非有另一个事物对其更改。
5，实时性：通常所说的实时性就是指一旦事物被成功应用，那么客户端就能立刻从服务器上获取变更后的新数据，zookeeper仅仅能保证在一段时间内，客户端最终一定能从服务器端读取最新的数据状态。
举例说明上述特性：
3个节点通过paxos算法，ZAB协议选举出1个leader，2个follower，假如leader挂了，只要半数以上节点是好的就能对外提供服务。
顺序一致性、原子性：三个节点构成集群，相当于一个整体，如果有一个client端发起一个请求把某个节点的数据1改为2，zk会把通过ZAB把修改的消息发给其他节点，用的同步算法就是paxos算法。同步数据期间不允许其他client修改数据。
可靠性：事物成功后会给client反馈，一问一答的形式
1.2-Zookeeper设计目标
目标1：简单的数据结构。zookeeper就是以简单的树形结构来进行相互协调的（也叫树形命名空间）
目标2：可以构建集群。一般zookeeper集群通常由一组机器构成，一般3~5台机器就可以组成一个zookeeper集群了。只要集群中超过半数以上的集群能够正常工作，那么整个几圈就能够正常对外提供服务。
目标3：顺序访问。对于来自每一个客户端的每一个请求，zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事物操作的先后顺序，应用程序可以使用zookeeper的这个特性来实现更高层次的同步。
目标4：高性能。由于zookeeper将全量数据存储在内存中，并直接服务于所有的非事物请求，因此尤其在读操作为主的场景下性能非常突出。
1.3-Zookeeper的数据结构
Zookeeper会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统。
1.4-Zookeeper的数据模型
1，每个子目录项如 NameService 都被称作znode，这个znode是被它所在的路径唯一标识，如Server1这个 znode的标识为 /NameService/Server1
2，znode 可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL类型的目录节点不能有子节点目录
3，znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径可以存储多份数据
4，znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode也将自动删除，Zookeeper的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为session，如果znode是临时节点，这个session失效，znode也就删除了。
5，znode 的目录名可以自动编号，如App1 已经存在，再创建的话，将会自动命名为App2
6，znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性，Zookeeper的很多功能都是基于这个特性实现的
1.5-Zookeeper组成
ZK Server根据其身份特性分为三种，Leader ，Follower，Observer，其中Follower和Observer又统称为Learner（学习者）。
Leader：负责客户端的writer 类型请求
Follower：负责客户端的reader 类型请求，参与leader选举等。
Observer：特殊的“Follower“，其可以接受客户端reader 请求，但不参与选举。（扩容系统支撑能力，提高了读取速度。因为它不接受任何同步的写入请求，只负责与leader同步数据）
1.6-Zookeeper典型应用场景
Zookeeper 从设计模式的角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在Zookeeper 上注册的哪些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。
1，配置管理
2，集群管理
3，发布与订阅
4，数据库切换
5，分布式日志的收集
6，分布式锁、队列管理等
1.7- Zookeeper 应用场景说明
一：配置管理：配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会遇到这样的需求，如机器的配置列表、运行时的开关配置、数据库配置信息等。这些全局配置信息通常具有以下3个特性：
1，数据量比较小
2，数据内容在运行时动态发生变化
3，集群中各个节点共享信息，配置一致
二：集群管理，Zookeeper 不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管” ，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader，并实现集群容错功能。
1，希望知道当前集群中究竟有多少机器工作
2，对集群中每天集群的运行状态进行数据收集
3，对集群中每台集群进行上下线操作
三：发布与订阅， Zookeeper 是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用它来进行分布式数据的发布与订阅
四：数据库切换，比如我们初始化Zookeeper 的时候读取节点上的数据库配置文件，当配置一旦发生变更时，zookeeper 就能帮我们把变更的通知发送到各个客户端，每个客户端在接收到这个变更后，就可以从新进行最新数据的获取。（数据库properties配置在zk，挂了的话切换到另一个）
五：分布式日志收集，我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理。
六：Zookeeper 的特性就是在分布式场景下高可用，但是用原生的API 实现的分布式功能非常困难，可以使用第三方客户端的完美实现，比如Curator框架，它是 Apache 的顶级项目
1.8 - Zookeeper开源框架的应用
zookeeper 使用场景非常广泛，如 Hadoop、Storm、消息中间件、RPC服务框架、数据库增量订阅与消费组件（如mysql binlog）、分布式数据库同步系统，淘宝的Otter。