ZooKeeper简介说明

什么是ZooKeeper

• ZooKeeper是一个高效的分布式协调服务，它暴露了一些共用服务，比如：命名、配置管理、同步控制、群组服务等。我们可以使用ZooKeeper来实现比如：达成共识、集群管理、Leader选举等
• ZooKeeper是一个高可用的分布式管理与协调框架，基于ZAB【paxos算法】协议（原子消息广播协议）的实现。该框架能够很好地保证分布式环境中数据的一致性【奇数台服务器，偶数也可以不过不利于paxos算法进行选举服务：从奇数个节点选取一个作为Leader，其他节点为follower】。也正是基于这样的特性，使得ZooKeeper成为解决分布式一致性问题的利器

• 特性：

  • 顺序一致性：从一个客户端【Client】发起的事务请求，最终将会按照其发起的顺序被应用到ZooKeeper中去
  • 原子性：所有事务请求的处理结果在整个集群中所有的机器上的应用情况是一致的，也就是说，要么整个集群所有的机器都成功应用了某一事务，要么没有应用，一定不会出现部分机器应用了该事物，而一部分没有应用的情况
  • 单一视图：无论客户端连接的是哪一个ZooKeeper服务器，其看到的服务器端数据模型都是一致的
  • 可靠性：一旦服务器成功应用了一个事务，并完成对客户端的响应，那么该事物所引起的服务器端状态将会被一致保留下来，除非有另一个事务对其改变
  • 实时性：通常所说的实时性是指一旦事务被成功应用，那么客户端就能立刻从服务器上获取变更后的新数据，ZooKeeper仅仅能保证在一段时间内，客户端最终一定能从服务器端读取最新的数据状态

ZooKeeper设计目标

• 目标1：简单的数据结构。ZooKeeper就是以简单的树形结构来进行相互协调的（也叫树形名字空间）【父子关系】
• 目标2：可以构建集群。一般ZooKeeper集群通常由一组机器构成，一般3~5台机器就可以组成一个ZooKeeper集群了。只要集群中超过半数以上的机器能够正常工作，那么整个集群就能够正常对外提供服务
• 目标3：顺序访问。对于来自每一个客户端的每一个请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反应了所以事务操作的先后顺序，应用程序可以使用ZooKeeper的这个特性来实现更高层次的同步
• 目标4：高性能。由于ZooKeeper将全量数据存储在内存中，并直接服务于所有的非事务请求，因此尤其在读操作为主的场景下性能非常突出。在JMater压力测试下（100%读请求场景下），其结果大约在12~13w的QPS【对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准】

ZooKeeper的结构

• ZooKeeper会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统
•      

ZooKeeper数据模型

• 每个子目录项如NameService都被称为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1
• znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL类型的目录节点不能有子节点目录
• znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
• znode可以是临时节点，一旦创建了这个znode的客户端与服务器端失去联系，这个znode也将自动删除，ZooKeeper的客户端与服务器通信采用长连接方式，每个客户端与服务器通过心跳来保持连接，这个连接状态称为session，如果znode是临时节点，这个session失效，znode也就删除了
• znode的目录名可以自动编号，如App1已经存在，再创建的话，将会自动命名为APP2
• znode可以被监控，包括这个目录节点存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个ZooKeeper的核心特征，ZooKeeper的很多功能都是基于这个功能实现的

ZooKeeper组成

• ZooKeeper Server根据其身份特征分为三种：Leader，Follower，Observer，其中Follower和Observer右统称为Leader（学习者）
  • Leader：负责客户端的writer类型请求
  • Follower：负责客户端的reader类型请求，参与leader选举等
  • Observer：特殊的“Follower”，其可以接受客户端reader请求，但不参与选举。（扩容系统支持能力，提高读取进度。因为它不接受任何同步的写入请求，只负责与Leader同步数据）

ZooKeeper应用场景

• 典型应用场景
  • ZooKeeper从设计模式角度看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper就将负责通知已经在ZooKeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式
• 配置管理：配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会碰到这样的需求：如机器的配置列表、运行时的开关配置、数据库配置信息等。这些全局配置信息通畅具备以下三个特性：
  • ​​​​​​​数据量比较小
  • 数据内容在运行时动态发生变化
  • 集群中各个节点共享信息，配置一致
• 集群管理：ZooKeeper不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是ZooKeeper的另一个功能Leader，并实现集群容错功能
  • ​​​​​​​希望知道当前集群中有多少机器工作
  • 对集群中每天集群的运行时状态进行数据收集
  • 对集群中每台集群进行上下线操作
• 发布与订阅：ZooKeeper是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用它来进行分布式数据的发布与订阅
• 数据库切换：比如我们初始化ZooKeeper的时候读取其节点上的数据库配置文件，当配置一旦发生变更时，ZooKeeper就能帮助我们把变更的通知发送到各个客户端，每个互动在接收到这个变更通知后，就可以从新进行最新数据的获取
• 分布式日志的收集：我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理
• 分布式锁、队列管理等
•  
• ZooKeeper的特性就是在分布式场景下高可用，但是原生的API实现分布式功能非常困难，团队去实现也太浪费时间，即使实现了也未必稳定。那么可以采用第三方的客户端的完美实现，比如Curator框架，他是Apache的顶级项目

ZooKeeper开源框架应用

• ZooKeeper使用场景非常广泛：
  • 如Hadoop、Storm、消息中间件、RPC服务框架、数据库增量订单与消费组件（如MySQL Binlog）、分布式数据库同步系统，淘宝的Otter