品味Zookeeper之选举及数据一致性_3

品味Zookeeper之选举及数据一致性

本文思维导图

前言

为了高可用和数据安全起见，zk集群一般都是由几个节点构成(由n/2+1，投票机制决定，肯定是奇数个节点)。多节点证明它们之间肯定会有数据的通信，同时，为了能够使zk集群对外是透明的，一个整体对外提供服务，那么客户端访问zk服务器的数据肯定是要数据同步，也即数据一致性。

zk集群是Leader/Follower模式来保证数据同步的。整个集群同一时刻只能有一个Leader，其他都是Follower或Observer。Leader是通过选举选出来的，这里涉及到ZAB协议(原子消息广播协议)。

1.ZAB协议

1.1 概念理解

为了更好理解下文，先说ZAB协议，它是选举过程和数据写入过程的基石。ZAB的核心是定义会改变zk服务器数据状态的事务请求的处理方式。

ZAB的理解：所有事务请求是由一个全局唯一的服务器来协调处理，这个的服务器就是Leader服务器，

其它服务器都是Follower服务器或Observer服务器。Leader服务器负责将一个客户端的请求转换成那个一个事务Proposal?(提议)，将该Proposal分发给集群中所有的Follower服务器。然后Leader服务器需要等待所有Follower服务器的应答，当Leader服务器收到超过半数的Follower服务器进行了明确的应答后，Leader会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

注意事务提议这个词，就类似 人大代表大会提议 ，提议就代表会有应答，之间有通信。因此在zk的ZAB协议为了可靠性和可用性，会有投票，应答等操作来保证整个zk集群的正常运行。

总的来说就是，涉及到客户端对zk集群数据改变的行为都先由Leader统一响应，然后再把请求转换为事务转发给其他所有的Follower，Follower应答并处理事务，最后再反馈。如果客户端只是读请求，那么zk集群所有的节点都可以响应这个请求。

1.2 ZAB协议三个阶段

  • 1.发现(选举Leader过程)
  • 2.同步(选出Leader后，Follower和Observer需进行数据同步)
  • 3.广播(同步之后，集群对外工作响应请求，并进行消息广播，实现数据在集群节点的副本存储)

下面会逐点分析，但是在这之前先来了解了解zookeeper服务器的知识吧。

2.Zookeeper服务器

2.1 zk服务器角色

  • Leader
  • 事务请求的唯一调度和处理者，保证集群事务处理的顺序序性
  • 集群内部各服务器的调度者
  • Follower
  • 处理客户端非事务请求，转发事务请求给Leader服务器
  • 参与事务请求Proposal的投票
  • 参与Leader的选举投票
  • Observer
  • 处理客户端非事务请求，转发事务请求给Leader服务器
  • 不参加任何形式的投票，包括选举和事务投票(超过半数确认)
  • Observer的存在是为了提高zk集群对外提供读性能的能力

整个zk集群的角色作用如下图：

2.2 zk服务器状态

  • LOOKING
  • 寻找Leader状态
  • 当服务器处于这种状态时，表示当前没有Leader，需要进入选举流程
  • FOLLOWING
  • 从机状态，表明当前服务器角色是Follower
  • OBSERVING
  • 观察者状态，表明当前服务器角色是Observer
  • LEADING
  • 领导者状态，表明当前服务器角色是Leader
  • ServerState 类维护服务器四种状态。

zk服务器的状态是随着机器的变化而变化的。比如Leader宕机了，服务器状态就变为LOOKING，通过选举后，某机器成为Leader，服务器状态就转换为LEADING。其他情况类似。

2.3 zk服务器通信

集群嘛，节点之间肯定是要通信的。zokeeper通信有两个特点：

  • 1.使用的通信协议是TCP协议。在集群中到底是怎么连接的呢？还记得在配置zookeeper时要创建一个data目录并在其他创建一个myid文件并写入唯一的数字吗？zk服务器的TCP连接方向就是依赖这个myid文件里面的数字大小排列。数小的向数大的发起TCP连接。比如有3个节点，myid文件内容分别为1,2,3。zk集群的tcp连接顺序是1向2发起TCP连接，2向3发起TCP连接。如果有n个节点，那么tcp连接顺序也以此类推。这样整个zk集群就会连接起来。
  • 2.zk服务器是多端口的。例如配置如下： 
    tickTime=2000
dataDir=/home/liangjf/app/zookeeper/data
dataLogDir=/home/liangjf/app/zookeeper/log
clientPort=2181
initLimit=5
syncLimit=2
server.1=192.168.1.1:2888:3888
server.2=192.168.1.2:2888:3888
server.3=192.168.1.3:2888:3888
  • 第1个端口是通信和数据同步端口，默认是2888
  • 第2个端口是投票端口，默认是3888

3.选举机制

3.1 选举算法

从zookeeper开始发布以来，选举的算法也慢慢优化。现在为了可靠性和高可用，从3.4.0版本开始zookeeper只支持基于Tcp的FastLeaderElection选举协议。

  • LeaderElection
  • Udp协议
  • AuthFastLeaderElection
  • udp
  • FastLeaderElection
  • Udp
  • Tcp

FastLeaderElection选举协议使用TCP实现Leader投票选举算法。它使用了类对象quorumcnxmanager管理连接。该算法是基于推送的，可以通过调节参数来改变选举的过程。第一，finalizewait决定等到决定Leader的时间。这是Leader选举算法的一部分。

final static int finalizeWait = 200;（选举Leader过程的进程时间）

final static int maxNotificationInterval = 60000;(通知检查选中Leader的时间间隔)

final static int IGNOREVALUE = -1;

这里先不详细分析，下面3.5 选举算法源码分析及举栗子才分析。

3.2 何时触发选举

选举Leader不是随时选举的，毕竟选举有产生大量的通信，造成网络IO的消耗。因此下面情况才会出现选举：

  • 集群启动
  • 服务器处于寻找Leader状态
  • 当服务器处于LOOKING状态时，表示当前没有Leader，需要进入选举流程
  • 崩溃恢复
  • Leader宕机
  • 网络原因导致过半节点与Leader心跳中断

3.3 如何成为Leader

  • 数据新旧程度
  • 只有拥有最新数据的节点才能有机会成为Leader
  • 通过zxid的大小来表示数据的新，zxid越大代表数据越新
  • myid
  • 集群启动时，会在data目录下配置myid文件，里面的数字代表当前zk服务器节点的编号
  • 当zk服务器节点数据一样新时， myid中数字越大的就会被选举成ОLeader
  • 当集群中已经有Leader时，新加入的节点不会影响原来的集群
  • 投票数量
  • 只有得到集群中多半的投票，才能成为Leader
  • 多半即：n/2+1,其中n为集群中的节点数量

3.4 重要的zxid

由3.3知道zxid是判断能否成为Leader的条件之一，它代表服务器的数据版本的新旧程度。

zxid由两部分构成：主进程周期epoch和事务单调递增的计数器。zxid是一个64位的数，高32位代表主进程周期epoch，低32位代表事务单调递增的计数器。

主进程周期epoch也叫epoch，是选举的轮次，每选举一次就递增1。事务单调递增的计数器在每次选举完成之后就会从0开始。

如果是比较数据新旧的话，直接比较就可以了。因为如果是主进程周期越大，即高32位越大，那么低32位就不用再看了。如果主进程周期一致，低32位越大，整个zxid就越大。所以直接比较整个64位就可以了，不必高32位于高32位对比，低32位与低32位比较。

3.5 选举算法源码分析及举栗子

3.5.1 举栗子

zookeeper选举有两种情况：

  • 1.集群首次启动
  • 2.集群在工作时Leader宕机

选主原则如下(在选举时，对比次序是从上往下)

  • 1.New epoch is higher
  • 主周期更大，代所有一切是最新，就成为leader
  • 2.New epoch is the same as current epoch, but new zxid is higher
  • 主周期一致就是在同一轮选票中，zxid越大就成为leader，因为数据更新
  • 3.New epoch is the same as current epoch, new zxid is the same as current zxid, but server id is higher
  • 主周期和zxid一致，就看机器的id(myid)，myid越大就成为leader

同时，在选举的时候是投票方式进行的，除主进程周期外，投票格式为(myid,zxid)。

第一种情况，比较容易理解，下面以3台机器为例子。

  • 三个zk节点A，B，C，三者开始都没有数据，即Zxid一致，对应的myid为1，2，3。
  • A启动myid为1的节点，zxid为0，此时只有一台服务器无法选举出Leader
  • B启动myid为2的节点，zxid为0，B的zxid与A一样，比较myid，B的myid为2比A为1大，B成Leader
  • C启动myid为3的节点，因为已经有Leader节点，则C直接加入集群，承认B是leader

第二种情况，已5台机器为例子。

  • 五个节点A，B，C，D，E，B是Leader，其他是Follower，myid分别为1，2，3，4，5，zxid分别为3，4，5，6，6。运行到某个时刻时A，B掉线或宕机，此时剩下C D E。在同一轮选举中，C，D，E分别投自己和交叉投票。
  • 第一次投票，都是投自己。
  • 投票情况为：C:(3,5) D:(4,6) E:(5,6)。
  • 同时也会收到其他机器的投票。
  • 投票情况为：C:(3,5)(4,6)(5,6)，D:(4,6)(3,5)(5,6)，E:(5,6)(4,6)(3,5)
  • 机器内部会根据选主原则对比投票，变更投票，投票情况为：C:(3,5)(4,6)(5,6)【不变更】。 D:(4,6)(4,6)(5,6)【变更】。E:(5,6)(5,6)(5,6)【变更】
  • 统计票数，C-1票，D-3票，E-5票。因此E成为Leader。

接下来就是对新Leader节点的检查，数据同步，广播，对外提供服务。

3.5.1 选举算法源码分析

选举算法的全部代码在FastLeaderElection类中。其他的lookForLeader函数是选举Leader的入口函数。

//每一轮选举就会增大一次逻辑时钟，同时更新事务
synchronized(this){
    logicalclock++;
    updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch());
}

//一直循环选举直到找到leader,这里把打印和不相关的都删除了，方便分析。

while ((self.getPeerState() == ServerState.LOOKING) &&
        (!stop)){

    //从通知队列拉取一个投票通知
    Notification n = recvqueue.poll(notTimeout,
            TimeUnit.MILLISECONDS);

    if(n == null){
        //看是否选举时通知发送/接收超时
        int tmpTimeOut = notTimeout*2;
        notTimeout = (tmpTimeOut < maxNotificationInterval?
                tmpTimeOut : maxNotificationInterval);
    }
    else if(self.getVotingView().containsKey(n.sid)) {
        switch (n.state) {
        case LOOKING://只有zk服务器状态为LOOKING时才会进行选举
            // If notification > current, replace and send messages out
            if (n.electionEpoch > logicalclock) {
                //如果选举时的逻辑时钟大于发送通知来源的机器的逻辑时钟，就把对方的修改为自己的。
                logicalclock = n.electionEpoch;
                recvset.clear();
                //并统计票数，如果能成为leader就更新事务
                if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                        getInitId(), getInitLastLoggedZxid(), getPeerEpoch())) {
                    updateProposal(n.leader, n.zxid, n.peerEpoch);
                } else {
                    //否者更新事务为对方的投票信息
                    updateProposal(getInitId(),
                            getInitLastLoggedZxid(),
                            getPeerEpoch());
                }
                sendNotifications();
            } else if (n.electionEpoch < logicalclock) {
                //如果通知来演的机器的逻辑时钟比本次我的选举时钟低，直接返回，什么都不做。因为对方没机会成为leader
                if(LOG.isDebugEnabled()){
                    LOG.debug("Notification election epoch is smaller than logicalclock. n.electionEpoch = 0x"
                            + Long.toHexString(n.electionEpoch)
                            + ", logicalclock=0x" + Long.toHexString(logicalclock));
                }
                break;
            } else if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                    proposedLeader, proposedZxid, proposedEpoch)) {
                //如果Epoch一样，就看zxid的比较。不过还是会更新事务和回传通知
                updateProposal(n.leader, n.zxid, n.peerEpoch);
                sendNotifications();
            }

            //把所有接收到的投票信息都放到recvset集合
            recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

            //统计谁的投票超过半数，就成为leader
            if (termPredicate(recvset,
                    new Vote(proposedLeader, proposedZxid,
                            logicalclock, proposedEpoch))) {

                //验证一下，被选举的leader是否有变化，就是看符不符合
                while((n = recvqueue.poll(finalizeWait,
                        TimeUnit.MILLISECONDS)) != null){
                    if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch,
                            proposedLeader, proposedZxid, proposedEpoch)){
                        //符合就放进recvqueue集合
                        recvqueue.put(n);
                        break;
                    }
                }

                //改变选举为leader的机器的状态为LEADING
                if (n == null) {
                    self.setPeerState((proposedLeader == self.getId()) ?
                            ServerState.LEADING: learningState());

                    Vote endVote = new Vote(proposedLeader,
                            proposedZxid, proposedEpoch);
                    leaveInstance(endVote);
                    return endVote;
                }
            }
            break;
        case FOLLOWING:
        case LEADING:
            //在同一轮选举中，判断所有的通知，并确认自己是leader
            if(n.electionEpoch == logicalclock){
                recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));
                if(termPredicate(recvset, new Vote(n.leader,
                                n.zxid, n.electionEpoch, n.peerEpoch, n.state))
                                && checkLeader(outofelection, n.leader, n.electionEpoch)) {
                    self.setPeerState((n.leader == self.getId()) ?
                            ServerState.LEADING: learningState());

                    Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
                    leaveInstance(endVote);
                    return endVote;
                }
            }
            //在对外提供服务前，先广播一次自己是leader的消息给所有follower，让大家认同我为leader。
            outofelection.put(n.sid, new Vote(n.leader, n.zxid,
                    n.electionEpoch, n.peerEpoch, n.state));
            if (termPredicate(outofelection, new Vote(n.leader,
                    n.zxid, n.electionEpoch, n.peerEpoch, n.state))
                    && checkLeader(outofelection, n.leader, n.electionEpoch)) {
                synchronized(this){
                    logicalclock = n.electionEpoch;
                    self.setPeerState((n.leader == self.getId()) ?
                            ServerState.LEADING: learningState());
                }
                Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
                leaveInstance(endVote);
                return endVote;
            }
            break;
        }
    }
}

比较重要的子函数有以下这些：

  • 1.totalOrderPredicate。(投票比较变更原则，选举的核心)

    ___________________________________

    protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {

    LOG.debug("id: " + newId + ", proposed id: " + curId + ", zxid: 0x" +

    Long.toHexString(newZxid) + ", proposed zxid: 0x" + Long.toHexString(curZxid));

    if(self.getQuorumVerifier().getWeight(newId) == 0){

    return false;

    }

    //按照这样的顺序比较优先：Epoch > Zxid > myid

    return ((newEpoch > curEpoch) ||

    ((newEpoch == curEpoch) &&

    ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId)))));

    }

  • 2.termPredicate。(最终的计算票数。先把投票放到集合中，然后再统计。集合能去重)

    ___________________________________

    private boolean termPredicate(

    HashMap

    HashSet<Long> set = new HashSet<Long>();
for (Map.Entry<Long,Vote> entry : votes.entrySet()) {
    if (vote.equals(entry.getValue())){
        set.add(entry.getKey());
    }
}
return self.getQuorumVerifier().containsQuorum(set);

    }

  • 3.Messenger。(构造Messenger的时候创建2条线程WorkerSender和WorkerReceiver用于整个选举的集群投票通信)

    ___________________________________

    Messenger(QuorumCnxManager manager) {

    this.ws = new WorkerSender(manager);

    Thread t = new Thread(this.ws,

    "WorkerSender[myid=" + self.getId() + "]");

    t.setDaemon(true);

    t.start();

    this.wr = new WorkerReceiver(manager);
t = new Thread(this.wr,
        "WorkerReceiver[myid=" + self.getId() + "]");
t.setDaemon(true);
t.start();

    }

其他细节不多说了，主要是sendqueue和recvqueue队列存放待发送投票通知和接收投票通知，WorkerSender和WorkerReceiver两条线程用于投票的通信，QuorumCnxManager manager用于真正和其他机器的tcp连接维护管理，Messenger是整个投票通信的管理者。

3.数据同步机制

3.1 同步准备

完成选举之后，为了数据一致性，需要进行数据同步流程。

3.1.1 Leader准备
  • Leader告诉其它follower当前最新数据是什么即zxid
  • Leader构建一个NEWLEADER的包，包括当前最大的zxid，发送给所有的follower或者Observer
  • Leader给每个follower创建一个线程LearnerHandler来负责处理每个follower的数据同步请求，同时主线程开始阻塞，等到超过一半的follwer同步完成，同步过程才完成，leader才真正成为leader
3.1.2 Follower准备
  • 选举完成后，尝试与leader建立同步连接，如果一段时间没有连接上就报连接超时，重新回到选举状态FOLLOWING
  • 向leader发送FOLLOWERINFO包，带上follower自己最大的zxid

3.2 同步初始化

同步初始化涉及到三个东西：minCommittedLog、maxCommittedLog、zxid

– minCommittedLog:最小的事务日志id，即zxid没有被快照存储的日志文件的第一条，每次快照存储

完，会重新生成一个事务日志文件

– maxCommittedLog:事务日志中最大的事务，即zxid

4.数据同步场景

  • 直接差异化同步(DIFF同步)
  • 仅回滚同步TRUNC?，即删除多余的事务日志，比如原来的Leader宕机后又重新加入，可能存在它自己写

    入提交但是别的节点还没来得及提交

  • 先回滚再差异化同步(TRUNC+DIFF同步)
  • 全量同步(SNAP同步)

不同的数据同步算法适用不同的场景。

5.广播流程

  • 集群选举完成，并且完成数据同步后，开始对外服务，接收读写请求
  • 当leader接收到客户端新的事务请求后，会生成对新的事务proposal，并根据zxid的顺序向所有的

    follower分发事务proposal

  • 当follower收到leader的proposal时，根据接收的先后顺序处理proposal
  • 当Leader收到follower针对某个proposal过半的ack后，则发起事务提交，重新发起一个commit的

    proposal

  • Follower收到commit的proposal后，记录事务提交，并把数据更新到内存数据库
  • 补充说明
  • 由于只有过半的机器给出反馈，则可能存在某时刻某些节点数据不是最新的
  • 如果需要确定读取到的数据是最新的，则可以在读取之前，调用sync方法进行数据同步

6.小结

在zookeeper中，除了watcher机制，会话管理，最重要的就是选举了。它是zookeeper集群的核心，也是广泛应用在商业中的前提。洋洋洒洒一大篇，可能存在一些不足，后面更加深入理解再来补充吧。

原文地址：https://www.cnblogs.com/liangjf/p/8552554.html

时间： 2024-10-05 00:04:05

品味Zookeeper之选举及数据一致性_3的相关文章

品味ZooKeeper之纵古观今_1

品味ZooKeeper之纵古观今 本章思维导图 这一系列主要是从整体到细节来品味Zookeeper,先从宏观来展开,介绍zookeeper诞生的原因,接着介绍整体设计框架,接着是逐个细节击破. 本章是首篇,主要是探究zookeeper的由来和整体框架,同时是一些自己的观点,本人也是在学习大数据的路上,难免有错,希望各位认真指出,一起进步. 1.何来何去? 1.1需求引起技术变化 每位程序猿都知道,需求是驱动技术发展的源泉动力.同样的,这句话放在zookeeper也适用,若不是需要zookeepe

品味ZooKeeper之Watcher机制_2

品味ZooKeeper之Watcher机制 本文思维导图如下: 前言 Watcher机制是zookeeper最重要三大特性数据节点Znode+Watcher机制+ACL权限控制中的其中一个,它是zk很多应用场景的一个前提,比如集群管理.集群配置.发布/订阅. Watcher机制涉及到客户端与服务器(注意,不止一个机器,一般是集群,这里先认为一个整体分析)的两者数据通信与消息通信,除此之外还涉及到客户端的watchManager. 下面正式进入主题. 1.watcher原理框架 由图看出,zk的w

Zookeeper leader选举

Zookeeper leader选举 由 xpproen 创建,youj 最后一次修改 2016-12-27 让我们分析如何在ZooKeeper集合中选举leader节点.考虑一个集群中有N个节点.leader选举的过程如下: 所有节点创建具有相同路径 /app/leader_election/guid_ 的顺序.临时节点. ZooKeeper集合将附加10位序列号到路径,创建的znode将是 /app/leader_election/guid_0000000001,/app/leader_el

图解zookeeper FastLeader选举算法【转】

转自:http://codemacro.com/2014/10/19/zk-fastleaderelection/ zookeeper配置为集群模式时,在启动或异常情况时会选举出一个实例作为Leader.其默认选举算法为FastLeaderElection. 不知道zookeeper的可以考虑这样一个问题:某个服务可以配置为多个实例共同构成一个集群对外提供服务.其每一个实例本地都存有冗余数据,每一个实例都可以直接对外提供读写服务.在这个集群中为了保证数据的一致性,需要有一个Leader来协调一些

图解zookeeper FastLeader选举算法

zookeeper配置为集群模式时,在启动或异常情况时会选举出一个实例作为Leader.其默认选举算法为FastLeaderElection. 不知道zookeeper的可以考虑这样一个问题:某个服务可以配置为多个实例共同构成一个集群对外提供服务.其每一个实例本地都存有冗余数据,每一个实例都可以直接对外提供读写服务.在这个集群中为了保证数据的一致性,需要有一个Leader来协调一些事务.那么问题来了:如何确定哪一个实例是Leader呢? 问题的难点在于: 没有一个仲裁者来选定Leader 每一个

zookeeper leader选举机制

最近看了下zookeeper的源码,先整理下leader选举机制 先看几个关键数据结构和函数 服务可能处于的状态,从名字应该很好理解 public enum ServerState { LOOKING, FOLLOWING, LEADING, OBSERVING; } 选票参数,还有Notification,参数也都差不多 static public class ToSend { long leader; //leader id long zxid; //选票的zxid long electio

zookeeper的选举机制

1)半数机制:集群中半数以上机器存活,集群可用.所以zookeeper适合装在奇数台机器上. 2)Zookeeper虽然在配置文件中并没有指定master和slave.但是,zookeeper工作时,是有一个节点为leader,其他则为follower,Leader是通过内部的选举机制临时产生的 3)以一个简单的例子来说明整个选举的过程. 假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器

ZooKeeper Lead选举

前段时间学习了zookeeper,对其中比较难理解并且容易忘掉的知识点做一个记录~ 关键词: myId:表示在集群中,自身对应的id zxId:节点状态发生改变时,产生的一个时间戳,并且这个时间戳全局有序 leader选举发生的时机: 在集群启动时和leader节点不可用时发生(连接断开) leader选举算法: basic paxos和fast paxos,系统默认fast paxos 关于选举过程: 流程图来源:https://blog.csdn.net/kevinlynx/article/

Zookeeper学习(十三)：Zookeeper的选举算法

1.ZAB(原子广播协议) 2.服务器角色 3.服务器状态 4.集群通信 5.选举触发的时机 6.影响成为Leader的因素 7.初次启动 8.运行投票过程 8.投票 9.广播流程