Zookeeper原理 – 汪明鑫的个人博客

集群中的角色

群首 leader

作为中心点处理所有对Zookeeper系统变更的事务请求

他像一个定序器，建立了所有事务处理的顺序性

追随者 follower

处理非事务请求，转发事务请求给leader

参与leader选举

leader会向所有follower发送事务请求提议Proposal,过半的follower回复ACK，则事务才commit

观察者 observer

不参与投票，不处理事务请求且转发给leader

同步leader的状态

提高读请求的可扩展性

zookeeper集群一般是由2n+1台服务器组成

我是跑了三个虚拟机，部署了zookeeper集群（一主两从）

事务请求的细节

只读请求：exists,egtData,getChildren

事务请求：新增create，更新setData，删除delete

Zookeeper的事务请求具有幂等性

当群首产生一个事务，就会为该事务分配一个标识符

即Zookeeper会话id ——-zxid

通过zxid，事务就可以按照leader指定的顺序在各个服务器中按序执行。

服务器之间在进行新的leader选举时也会交换zxid信息,

这样就可以知道哪个无故障服务器接收了更多的事务，同步他们之间的状态信息。

leader选举

leader无疑时zookeeper集群中最重要的角色，那他是怎么产生的呢？

我之前写的有篇zookeeper投票机制是比较片面的，真正的leader选举是比较复杂的。

什么时候需要leader选举？

(1) zookeeper集群初始化启动，还没有leader，节点相互通信选举leader。

(2) 集群当前leader挂了，需要重新选举leader。

server的状态：Looking、 Following、Observering、Leading

Looking是选举状态，Following是Follower节点所处的状态，

Observering是Observer节点所处的状态，Leading是Leader节点所处的状态。

leader选举的过程也是zooker集群节点状态变化的过程。

每个服务器启动后进入LOOKING状态，开始选举一个新的leader或者查找已经存在的leader，

如果leader已经存在，其他服务器就会通知这个新启动的服务器哪个是leader,

新启动的服务器就可以和leader建立连接，同步leader的状态。

如果集群中所有节点都是LOOKING，这些服务器之间就会进行通信来选举一个leader。

一次投票发送的是什么？

在zookeeper的源码当中有这样一个类

org.apache.zookeeper.server.quorum.Vote

一次投票包含了id和zxid,作为投票的主要依据

还提供了其他Vote的构造函数

id：被推举的Leader的SID。zxid：被推举的Leader事务ID。　electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作。

peerEpoch：被推举的Leader的epoch。

state：当前服务器的状态。

/**
     * returns the highest zxid that this host has seen
     *
     * @return the highest zxid for this host
     */
    public long getLastLoggedZxid() {
        if (!zkDb.isInitialized()) {
            loadDataBase();
        }
        return zkDb.getDataTreeLastProcessedZxid();
    }

返回最新的事务请求的标识符zxid

源码我还看不太懂，不熟，暂时先看到这里，之后再慢慢研究。

leader选举过程：

每一次投票都会发给集群中的每一台服务器。

起初Zookeeper集群初次启动，zxid都为0

针对每一次投票，要和别人发来的投票和自己手里拽着的投票对比，

如果别人发来的投票的zxid大于我手里拽着的投票或者

zxid相等但发来的id大于myid，

修改我的投票Vote(myZxid,myId)为发来的投票Vote(zxid,id)。

即投票给zxid最大的(状态)最新的服务器

图解leader选举过程：

我们为了简单，先只分析2台服务器，实际上在集群中的分析方法是一样的，