Zookeeper简介

一、Zookeeper是什么东西？

（1）、ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步服务、组服务等。
（2）、ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
（3）、ZooKeeper包含一个简单的原语集，提供Java和C的接口。

（1）、领导者（leader）：负责进行投票的发起和决议，更新系统状态
（2）、学习者（learner）：包括跟随者（follower）和观察 者（observer），follower用于接受客户端请求并向 客户端返回结果，在选主过程中参与投票 ，Observer可以接受客户端连接，将写请求转发给 leader，但observer不参加投票过程，只同步leader 的状态，observer的目的是为了扩展系统，提高读取 速度
（3）、客户端（client）：请求发起

（1）、Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议（Zookeeper Atomic Broadcast协议）。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

（2）、为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

（3）、每个Server在工作过程中有三种状态：
        LOOKING：当前Server不知道leader是谁，正在搜寻
        LEADING：当前Server即为选举出来的leader
        FOLLOWING：leader已经选举出来，当前Server与之同步

1.1、Zookeeper特点

（1）、最终一致性：为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能
（2）、可靠性：如果消息被到一台服务器接受，那么它将被所有的 服务器接受。
（3）、实时性：Zookeeper不能保证两个客户端能同时得到刚更新 的数据，如果需要最新数据，应该 在读数据之前调 用sync()接口。
（4）、独立性：各个Client之间互不干预 原子性 更新只能成功或者失败，没有中间状态。
（5）、顺序性：所有Server，同一消息发布顺序一致。

1.2、Zookeeper 的读写机制

（1）、Zookeeper是一个由多个server组成的集群
（2）、一个leader，多个follower
（3）、每个server保存一份数据副本
（4）、全局数据一致
（5）、分布式读写
（6）、更新请求转发，由leader实施

1.3、Zookeeper 的保证　

（1）、更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
（2）、数据更新原子性，一次数据更新要么成功，要么失败
（3）、全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
（4）、实时性，在一定事件范围内，client能读到最新数据

1.4、Zookeeper节点数据操作流程

1、Client向Follwer发出一个写的请求
2、Follwer把请求发送给Leader
3、Leader接收到以后开始发起投票并通知Follwer进行投票
4、Follwer把投票结果发送给Leader
5、Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;
6、Follwer把请求结果返回给Client

Follower主要有四个功能：
（1）、向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
（2）、接收Leader消息并进行处理；
（3）、接收Client的请求，如果为写请求，发送给Leader进行投票；
（4）、返回Client结果。

Follower的消息循环处理如下几种来自Leader的消息：
（1）、PING消息： 心跳消息；
（2）、PROPOSAL消息：Leader发起的提案，要求Follower投票；
（3）、COMMIT消息：服务器端最新一次提案的信息；
（4）、UPTODATE消息：表明同步完成；
（5）、REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
（6）、SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

1.5、Zookeeper 的数据模型　

（1）、层次化的目录结构，命名符合常规文件系统规范
（2）、每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
（3）、节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
（4）、Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
（5）、客户端应用可以在节点上设置监视器
（6）、节点不支持部分读写，而是一次性完整读写

1.6、Observer

（1）、Zookeeper需保证高可用和强一致性；
（2）、为了支持更多的客户端，需要增加更多Server；
（3）、Server增多，投票阶段延迟增大，影响性能；
（4）、权衡伸缩性和高吞吐率，引入Observer
（5）、Observer不参与投票；
（6）、Observers接受客户端的连接，并将写请求转发给leader节点；
（7）、加入更多Observer节点，提高伸缩性，同时不影响吞吐率

        尽管通过Client直接连接到Zookeeper集群的性能已经非常好了，但是这种架构如果要承受超大规模的Client，就必须增加Zookeeper集群的Server数量，随着Server的增加，Zookeeper集群的写性能必定下降，我们知道Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因必然导致投票成本增加，从而导致写性能的下降。

        Observer是一种新型的Zookeeper节点，可以帮助解决上述问题，提供Zookeeper的可扩展性。Observer不参与投票，只是简单接收投票结果，因此我们增加再多的Observer，也不会影响集群的写性能。除了这个差别，其他的和Follower基本上完全一样。例如：Client都可以连接到他们，并且都可以发送读写请求给他们，收到写请求都会上报到Leader。

        Observer有另外一个优势，因为它不参与投票，所以他们不属于Zookeeper集群的关键部位，即使他们Failed，或者从集群中断开，也不会影响集群的可用性。根据Observer的特点，我们可以使用Observer做跨数据中心部署。如果把Leader和Follower分散到多个数据中心的话，因为数据中心之间的网络的延迟，势必会导致集群性能的大幅度下降。使用Observer的话，将Observer跨机房部署，而Leader和Follower部署在单独的数据中心，这样更新操作会在同一个数据中心来处理，并将数据发送的其他数据中心（包含Observer的），然后Client就可以在其他数据中心查询数据了。但是使用了Observer并非就能完全消除数据中心之间的延迟，因为Observer还得接收Leader的同步结果合Observer有更新请求也必须转发到Leader，所以在网络延迟很大的情况下还是会有影响的，它的优势就为了本地读请求的快速响应。

1.7、数据一致性与paxos 算法　　

（1）、据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。
（3）、Paxos算法解决的什么问题呢？解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一致性。没错，就是这样，可是如果master挂了呢。
（4）、Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。