zookeeper简介

 

1.什么是zookeeper    

        zookeeper是一个高效可靠的分布式协调服务，提供了诸如统一命名服务、配置管理和分布式锁等分布式服务。是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、分布式协调通知、Master选举、分布式锁和分布式队列等功能。zookeeper可以保证如下分布式一致性特性。

      顺序一致性

             从同一个客户端发起的事务请求，最终将会严格的按照发起顺序应用到zookeeper中去。

     原子性

            所有事务请求的处理结果在整个集群中的所有机器上应用情况是一致的，也就是说，要么整个集群所有机器都成功应用到了某个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。

2.zookeeper基本概念（整体介绍）

      集群角色

      最典型的集群模式就是Master/Slave模式（主备模式）。在zookeeper中，这些概念被颠覆了 。它没有引用Master/Salve概念，而是引入了Leader、Follower和Observer三种角色。Zookeeper集群中所有机器通过一个Leader选举过程来选定一台Leader服务器，Leader服务器为客户端提供读和写服务。除Leader服务外，其它机器包括Follower和Observer，只能提供读服务。Observer机器不参与Leader选举，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

    会话（Session）

    Session是指客户端会话。在Zookeeper中，一个客户端连接是指客户端和服务端之间的一个tcp长连接。Zookeeper对外的默认端口是2181，客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次建立连接，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话。不仅可以向服务器发送请求，也可以接收来自服务器的Watch事件通知。

    数据节点（Znode）

    zookeeper节点分为两类，第一类☞构成集群的机器，机器节点；第二类☞数据模型中的数据单元，我们称之为数据节点-Znode。Zookeeper将所有数据存储在内存中，数据模型是一颗树，由斜杠（/）进行分割的路径就是一个节点。节点可以分为持久节点和临时节点。持久节点一旦被创建，除非主动移除，否则将一直保存在Zookeeper上；临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话实现，那么这个客户端创建的所有临时节点都会被移除。另外，Zookeeper还允许用户为每个节点添加一个特殊属性：sequential。一旦这个节点被标记上这个属性，节点被创建的时候，Zookeeper会自动在其节点后面追加一个整数型字，这个整数型字是一个由父节点维护的自增数字。

    版本

    Zookeeper的每个Znode上都会存储数据。数据中记录了Znode的三个数据版本，分别是version（当前Znode的版本）、cversion（当前Znode子节点的版本）、aversion（当前Znode的ACL版本）。

     ACL

    权限控制。Zookeeper定义了5中权限

               create：创建子节点的权限。

               read：获取节点数据和子节点列表的权限。

               writer：更新节点数据的权限。

               delete：删除子节点的权限。

               admin：设置节点acl的权限。

   Watch（事件监听）

          Zookeeper允许用户在指定节点上注册一些Watch，并且在一些特定事件触发的时候，Zookeeper服务会将事件同时到感兴趣的客户端上去。

3. Zookeeper的ZAB协议

       ZAB（Zookeeper atomic broadcast）协议是分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。用来实现集群中各个副本的数据一致性。

      ZAB协议的核心是定义了那些改变Zookeeper服务器数据状态事务请求处理方式：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称之为Leader服务器，而余下的其他服务器则成为Follower服务器。leader服务器负责将一个客户端事务请求转换为一个事务proposal（提议），并将该proposal分发给集群中所有的Follower服务器。之后leader服务器要等待所有follower服务器的反馈，一旦超过半数的follower服务器进行了正确的反馈后，那么leader就会再次向所有的follower服务器发送分发commit消息，要求将前一个proposal进行提交。

     ZAB协议两种基本模式：分别是崩溃恢复和消息广播。

     消息广播协议

      是一个原子广播协议，类似于一个二阶段提交过程。针对客户端的事务请求，leader服务器会为其生成对应的事务proposal，并将其发送给集群中其余多有的机器，然后再分别收集各自的选票，最后进行事务提交。ZAB协议涉及的二阶段提交过程则与其略有不同。在ZAB协议中二阶段提交中，移除了中断逻辑，所有服务器要么正常反馈，要么抛弃leader服务器。同时ZAB协议将二阶段提交中的中断逻辑移除，意味着我们可以在过半的Follower服务器已经反馈ack之后就开始提交事务proposal，而不需要等待集群中所有的follower服务器都反馈响应。此模式下无法解决leader服务器崩溃带来的数据不一致问题，解决方案：崩溃恢复协议。另外广播协议基于具有FIFO特性的TCP协议来进行通信的。保证了消息广播过程中消息的接收和发送的顺序性。在整个广播协议中，leader服务器会为每个事物请求生成对应的proposal来进行广播，并且在广播之前，首先为这个事务proposal分配一个全局单调递增的唯一ID，称之为事务ID（ZXID 64位前32位记录当前朝代，后32位记录事务id 在广播协议中事务id是递增的）。由于ZAB协议需要保证每一个消息严格的因果关系，因此必须将每一个事务proposal按照其zxid的先后顺序来进行排序和处理。

     在消息广播过程中，Leader服务器会为每一个Follower服务器都各自分配一个单独的队列，然后将需要的广播事务proposal一次放入这些队列中去，并且根据FIFO策略进行消息发送。每一个Follower服务器在接收到这个事务proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去，并且成功写入后反馈给leader服务器一个ack响应。当leader服务器接收到超过半数Follower的ack响应收，就会广播一个commit消息给所有的follower服务器通知其进行事务提交，同时leader自身也会完成对事物的提交，而每个follower服务器在接收到commit消息后，也会完成对事物的提交。

     崩溃恢复协议

     选举

     基本特性

           ZAB协议需要确保那些已经在Leader服务上提交的事务proposal最终被所有机器提交。

           假设一个事务在leader服务器上被提交了，并且已经得到过半的Follower服务器的ack返回，但是在它将commit消息发送给所有的follower机器之前（部分机器收到 部分没有收到），leader服务器挂了。ZAB协议需要确保事务proposal在所有的服务器上提交成功

            ZAB协议需要确保丢弃那些只在leader服务器上被提出的事务

            leader服务在发出commit之前挂掉了，需要确保选举后以及该服务器重新连接后，整个集群丢弃该事务proposal。

    数据同步

        完成Leader选举之后没在这是开始工作（即接收客户端的事务请求，然后提出新的提案）之前，Leader服务器会首先确认事务日志中的所有proposal是否都已经被集群中过半的机器提交了，即是否完成数据同步。

        Leader服务器会为每一个Follower服务器都准备一个队列，并将哪些没有被各个Follower服务器同步的事务以proposal消息逐个发送给Follower服务器，并在每一个proposal消息后面紧接着在发送一个commit消息，以表示该事物已经被提交。等待Follower服务器将所有其尚未同步的事务proposal都从Leader服务器同步过来并成功应用到本地数据库中后，leader服务器就会将该Follower服务器加入到真正可用的follower列表中，并开始之后的其他流程。

     事务丢弃

            ZAB处理丢弃的事务proposal。在ZAB协议的事务编号ZXID设计中，是一个由64位的数字，低32位可以看做一个简单的递增的计数器，针对客户端的每一个事务请求，Leader服务器在产生一个新的事务proposal时，都会对计数器进行加1操作。而高32位则代表了Leader周期epoch朝代的编号。每当选举一个新的Leader服务器，就会总这个Leader服务器中取出本地日志中最大事务Proposal的ZXID，并解析出epoch，然后对其进行加一，并将低32位设置为0，最为新的事务ZXID。基于这样的策略，当包含上一个Leader周期中尚未提交的事务Proposal的服务器启动时，其肯定无法成为leader，原因集群中一定包含一个Quorum（集群中处于过半UP（活跃）状态的进程组成的子集）集合该集合中的机器一定包含了了更高epoch的事务提议。同时Leader服务器会根据自己服务器上最后被提交的proposal来和Follower服务器进行比对，比对结果是Leader会要求Follower进行一个回退，回退到一个确实已经被集群中过半提价的最新事务中（即会退到Leader与该Follower服务器同朝代的最大的事务id ）