zookeeper简介

2019独角兽企业重金招聘Python工程师标准>>>

1. zookeeper介绍

• zookeeper的设计目标是将那些复杂切容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
• zookeeper是一个典型的分布式数据的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。zookeeper可以保证如下分布式一致性特性：
  • 顺序一致性：从一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到zookeeper中去；
  • 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况；
  • 单一视图：无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的；
  • 可靠性：一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更；
  • 实时性：通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端读取到这个事务变更后的最新数据状态。这里需要注意的是，zookeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

2. zookeeper的设计目标

• 简单的数据模型：zookeeper使得分布式程序能够通过一个共享的、树形结构的名字空间来进行相互协调。这里所说的树形结构的名字空间，是指zookeeper服务器内存中的一个数据模型，其由一系列被称为ZNode的数据节点组成，总的来说，其数据模型类似于一个文件系统，而ZNode之间的层级关系，就像文件系统的目录结构一样。不过和传统的磁盘文件系统不同的是，zookeeper将全量数据存储在内存中，以此来实现提高服务器吞吐、减少延迟的目的；
• 可以构建集群：zookeeper可以通过多台服务器构建成一个集群，只要集群中存在超过一半的机器能够正常工作，那么整个集群就能够正常对外服务。zookeeper客户端程序会选择和集群中任意一台机器共同来创建一个TCP连接，而一旦客户端和某台zookeeper服务器之间的连接断开后，客户端会自动连接到集群中的其他机器；
• 顺序访问：对于来自客户端的每个更新请求，zookeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用zookeeper的这个特性来实现更高层次的同步原语；
• 高性能：zookeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。

3. zookeeper的基本概念

• 集群角色
  • zookeeper集群中存在三种角色：Leader，Follower和Observer。zookeeper集群中的所有机器通过一个leader选举的过程来选定一台被称为Leader的机器，Leader服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和Observer。Follower和Observer都能够提供读服务，唯一的区别在于Observer机器不参与Leader的选举过程，也不参与写操作的”过半写成功“策略，因此Observer可以在不影响写性能的情况下提升集群的读性能；
• 会话（Session）
  • 会话指的是客户端与服务器之间的会话连接，其是一个TCP长连接，客户端与服务器通过会话发送和接收消息，发送心跳检测，以及接收服务器的监听事件等操作；
• 数据节点（ZNode）
  • 在zookeeper中，节点分为两类，第一类是指构成集群的机器，我们称之为机器节点，第二类则是指数据模型中的数据单元，我们称之为数据节点——ZNode；
  • 在zookeeper中，数据节点分为两类：持久节点和临时节点。并且zookeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上该属性，那么在这个节点被创建的时候，zookeeper会自动在其节点名后追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字；
    • 持久节点：其是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在zookeeper上；
    • 临时节点：其声明周期与具体的会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。
• 版本
  • zookeeper的每个ZNode上都会存储数据，对应于每个ZNode，zookeeper都会为其维护一个叫做Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）、和aversion（当前ZNode的ACL版本）。
• Watcher
  • Watcher，也称为事件监听器，是zookeeper中的一个很重要的特性。zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，zookeeper服务端会将事件通知到感兴趣的客户端上去，该机制是zookeeper实现分布式协调服务的重要特性。
• ACL
  • zookeeper采用ACL策略来进行权限控制，其定义了5中权限：
    • CREATE：创建子节点的权限；
    • READ：获取节点数据和子节点列表的权限；
    • WRITE：更新节点数据的权限；
    • DELETE：删除子节点的权限；
    • ADMIN：设置节点ACL的权限；

4. ZAB协议

• 在zookeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。

• ZAB协议的核心是定义了那些会改变zookeeper服务器数据状态的事务请求的处理方式，即：

  • 所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则称为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal提交。

• 消息广播

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

• 整体流程

  • 发现
    • 当系统启动或者Leader服务器宕机时，就会进入此阶段，在这个阶段，所有的Follower服务器首先会生成一张投选自己为Leader的选票，然后将该选票广播给其他所有的Follower，其也会收到其他的Follower的选票。在Follower收到其他Follower的选票之后，其会将收到的选票与自己投的选票进行对比，比较方式就是首先对比收到的选票与自己的选票的ZXID，谁大就将选票投给谁，如果ZXID相同，那么就比较收到的选票与自己的服务ID大小，选择ID大的一个作为自己的选票。如果经过对比之后，当前Follower更改了自己的投票，那么它就会将其广播出去，如果没有更改，则不进行广播。如此一段时间之后，当某个Follower收到的票数超过了集群Follower数目的一半时，该Follower就会成为准Leader；
    • 当产生一个准Leader之后，该leader服务器就会根据选票中的epoch信息，对其进行自增，生成一个新的epoch，并且将这个消息广播出去；
    • 当Follower收到leader广播的epoch消息之后，会对自身的epoch进行更新，然后向leader返回Ack消息，并且该消息中包含了历史事务的集合。
  • 同步
    • leader收到Follower发送的事务消息之后，其会选择其中事务ZXID最大的Follower的事务集合作为最新的事务集合，然后向各个Follower发送NEWLEADER的消息，该消息中包含了Follower缺少的事务集合，Follower收到消息之后会将这些事务进行应用，最后Follower会反馈给Leader，其已经处理完了所有的事务Proposal；
    • 当leader收到超过半数的Follower的反馈消息之后，其就会向Follower广播一个Commit消息，以告知其数据同步和leader选举完毕，可以进行消息处理了；
  • 广播
    • Leader收到客户端的新事务请求后，会生成对应事务的Proposal，并且根据ZXID向所有的Follower发送提案；
    • Follower按照消息接收的顺序处理这些提案，首先将其记录到事务日志中，记录完成后直接返回给Leader以Ack消息，然后将事务应用到当前Follower中；
    • 当Leader收到超过半数的Follower针对该Proposal的消息之后，就会发送Commit消息给所有的Follower，要求它们进行事务提交；
    • 当Follower收到Leader的commit消息之后，就会开始提交事务proposal，并且返回Leader以Ack消息，leader收到过半的消息之后也会在当前机器中提交事务。

转载于:https://my.oschina.net/zhangxufeng/blog/2995597