一步一步学ZooKeeper-ZooKeeper初了解

Posted 2020-10-04

角色

         Zookeeper中的角色主要有以下三类

         领导者（Leader）

                   领导者负责进行投票的发起和决议，更新系统状态

         学习者（Learner）

                   跟随者（Follwer）

                            Follwer用于接收客户请求并向客户端返回结果，在选主过程中参与投票

                   观察者（ObServer）

ObServer可以接收客户端连接，将写请求转发给leader节点。但ObServer不参加投票过程，只同步leader的状态。ObServer的目的是为了扩展系统，提高读取速度。

         客户端（Client）

                   请求发起方

Zookeeper的工作原理

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

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

每个Server在工作过程中有三种状态：

         LOOKING:当前Server不知道leader是谁，正在搜寻。

         LEADING:当前Server即为选举出来的leader。

         FOLLOWING:leader已经选举出来，当前Server与之同步。

选主流程

         当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

         Fast paxos流程是在选举过程中，某Server首先向所有的Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接收对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选出Leader。

    设计目的

　　1、  最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

　　2、  可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接收，那么它将被所有服务器接受。

　　3、  实时性：ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效信息，但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口

　　4、  等待无关：慢的或者失效的client不得干预快速的client请求，使得每个client都能有效的等待。

　　5、  原子性：更新只能成功或者失败，没有中间状态。

　　6、  顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将消息b前被发布；偏序是指如果一个消息b在消息a后备同一个发送者发布，a必将排在b前面。

 

Zookeeper系统架构

        

 

         Zookeeper架构图中我们需要掌握

　　1、  Zookeeper分为服务器端和客户端，客户端可以连接到整个Zookeeper服务的任意服务器上（除非leaderServers参数显示设置，leader不予许接收客户端连接）。

　　2、  客户端使用并维护一个TCP连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个TCP连接中断，客户端将自动尝试连接到另外的Zookeeper服务器。客户端第一次连接到Zookeeper服务器时，接受这个连接的ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话被新的服务器重新建立。

　　3、  上图中的每一个Server代表一个安装ZooKeeper服务的机器，即是整个提供ZooKeeper服务的集群（或者是由为集群组成）

　　4、  组成Zookeeper服务的服务器必须彼此了解。它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照，只要大多数服务器可用，ZooKeeper服务就可用。

　　5、  ZooKeeper启动时，将从实例中选举一个leader，Leader服务处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server在内存中存储了一份数据。

　　6、  Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

　　7、  Zab协议包括两个阶段：leader election阶段和Atomic Broadcast阶段

　　a)         集群中将选举一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过broadcast将所有的更新告诉给follower。

　　b)         当leader崩溃或者leader失去大多数follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。

　　c)         当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leadder election的过程就结束了，就将会进入到Atomic broadcast的过程。

　　d)         Atomic Broadcast同步leader和follower之间的信息，保证leader和follower具有相同的系统形态。

Zookeeper的Server数目一般为奇数

         Zookeeper中Leader选举算法采用了Zab协议。Zab核心思想是当多数Server写成功，则任务数据写成功。

      容错性

　　1、  如果有3个Server，则最多允许1个Server挂掉。

　　2、  如果有4个Server，则同样最多允许1个Server挂掉。

　　既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。

　　 防止脑裂发生

Zookeeper的写数据流程主要分为以下几步

　　1、  比如Client向ZooKeeper的Server1上写数据，发送一个写请求。

　　2、  如果Server1不是Leader，那么Server1会把接收到的请求进一步转发给Leader，因为每个Zookeeper的Server里面有一个是Leader，这个Leader会将写请求广播给各个Server，比如Server1和Server2，各个Server写成功后就会通知Leader。

　　3、  当Leader收到大多数Server数据写成功了，那么久说明数据写成功了，写成功之后，Leader会告诉Server1数据写成功了。

　　4、  Server1会进一步通知Client数据写成功了，这是就认为整个写操作成功。