zookeeper Leader Elections

     本文主要介绍zookeeper leader选举机制。

     zookeeper中leader主要处理来至客户端的写请求，包括create、setData、delete等改变数据的状态的写请求。在zookeeper集群中，每一个zookeeper Server节点开始的状态都是LOOKING,它必须选择一个新的Leader，或者找到已经存在的Leader。

     如果此时，集群中存在 Leader,其他集群的中节点将通知新进入的Server节点哪个是Leader节点，新节点将连接到Leader上，并且同步Leader的状态，使之一致。

      如果此时集群不存在Leader,都是LOOKING状态，它们将选举出新的Leader。节点通过相互发送消息，选举出Leader。选举出的节点将进入LEADING状态，其他的节点将进入FOLLOWING状态。

    leader选举消息又被叫作leader选举通知。当一个节点进入LOOKING状态时，它将发送给其他每一个节点通知。通知包含它当前的选举(vote)，由sid (Server Id) 和 zxid(zookeeper事务id,最新的事务id)组成。比如(1,5)通知代表被server id为1，最新事务id为5的节点放送的。

    当收到一个vote通知，节点将根据如下规则改变自己的vote：

    1设定 voteId 和 voteZxid 代表当前节点受到的vote标识，myZxid和mySid代表receiver自己本身的值。

    2 如果 voteZxid > myZxid 或者 (voteZxid==myZxid and voteId > mySid),receiver将保持当前的vote，也就是赞同当前的选举。

    3否者，receiver将改变自己的vote, 该vote 为（mySid,myZxid），也就是说我不赞同当前收到的vote,我要自己当领         导。

简而言之，就是最近发起的vote将会获胜，谁的zxid大，谁获胜，如果zxid相同，就只能比较节点标示id的大小了（同一辈子，嫡长子继承了，哈哈）。紧接着，如果receiver赞同收到的选举，它将向其他节点发送该通知。一旦有一个节点 收到  来至半数  以上的节点 同样的vote（sid,zxid）,该节点就声明LEADER选举出来了。如果LEADER是该节点本身，它将承担起Leader角色的功能。如果不是，它将变为一个Follower，并且连接LEADER,同步leader的状态，然后处理来至客户端的请求。

  通过如下图详解上述过程，假设集群中有三个节点：

         第一步：3个节点都将向其他节点 发送各自的选举vote ；

         第二步：通过我们刚才讲的规则，S2 和 S3的zxid比较小，所以它们的vote都变为(1,6)，并且通知其他节点;

         第三步：三个节点 都收到半数以上的对(1,6)选举。所以S1被选为Leader。

并不是所有的选举过程都像上面的过程那么顺利，往往由于网络delay,会造成不同上述的过程。如下：

     第一步：由于S1 到 S2 网络delay,当S2受到S3的vote(3,5)，并赞同该（3，5），发出通知，选举S3。

     第二步：S3受到(1,6),但是由于网络delay,它发出的通知到S1比较慢，而此时，S3已经有半数的投票了。所以S3被选为Leader。

    第三步：S1接到S3的投票，S1也有半数以上的投票，S1也被选为Leader。

这样会怎么办呢？？  在第二步的时候S3不响应S2提出选自己作为Leader,因为自己vote已经变为(1,6)了，所以S3不会相应S2提出自己作为Leader的要求。所有S2会等待超时，最终S1成为Leader。 

  这只是一种延时的例子，还有很多其他例子，就不一一列举了。

 该文章内容参照：ZooKeeper: Distributed Process Coordination 这本书。

 转发请标注来源：http://my.oschina.net/robinyao/blog/403215

END----------------------------------------------------------------------