【分布式协调器】Paxos的工程实现-Cocklebur状态转移

  集群中的主机通过选举过程由Looking状态变为了LeaderingFollowing状态。而这些状态之间转移的条件是什么呢?先来个直观的,上状态图。node

 

图 4.1 Cocklebur选举过程当中的状态图算法

 

  接下来咱们对上面的状态图进行逐个分析,而且作出简要的解释说明。若是你对一些概念有所遗忘,请查阅“Cocklebur选举”一章中的名词解释。spa

Cocklebur状态转义描述

表 4-1 状态转移连接表3d

状态转移连接日志

条件对象

解释blog

Start->Looking进程

启动同步

主机进程实例一旦被启动都设置为Looking状态源码

Looking->Following

收到对本身加ACK锁主机的Lead消息,或者肯定已经存在一个稳定的正常工做的多数派

发现以前给本身加ACK锁的候选者已经成为Leader,说明必定存在一个多数派以其做为Leader,故能够变为Following。另外当一个Looker发现已经存在一个稳定的服务集群(有稳定的LeaderFollower),则它会自动变为Follower加入集群

Looking->Leadering

得到多数派的ACK

改进段属于Paxos的第二阶段,候选者赢得了多数派(包括本身)的投票,那么他就多数派申请ACK锁,若是应答容许的节点依然可构成多数派,则说明候选者能够作为Leader

Following->Looking

Leader状态改变为非Leadering或向Leader申请租约超时

当发现Leader已经不是Leader,或者在超时内链接不到Leader,那么说明Leader已经失效,则须要从新选举

Leadering->Looking

租约有效的Follower不足majority-1

Leader维护这租约表,若是有效的Follower很多于majority-1,那么算上Leader本身可构成多数派。若是不知足此条件,则从新选举

*->end

宕机

主机宕机,任何状态归于结束

 

  状态转移控制流程在源码的Cocklebur.cpp中的process方法中,只用到了一个switch语句。lookForLeader()Following()Leadering(),这三个方法完成了三态的运行流程,而每个方法结束以前,已经确保了全局状态是否改变,这样在某个方法结束后,process方法就能够直接运行当前状态应该运行的控制流程。

  lookForLeader()的算法逻辑咱们已经在选举一章中分析过,接下来介绍一下Following()Leadering()两个方法。这两个方法分别属于Follower对象与Leader对象。

Follower的实现

  Follower每隔一段时间向Leader申请租约。所谓申请租约本质上是一种超时锁,而Follower申请的像是一种读锁,拥有租约以后Follower才能保证能从Leader同步到最新数据。Follower经过心跳的方式向Leader发送一个消息,Cocklebur中消息的结构以下:

 

struct HBMSG {

    1: string my_host_name, 

    2: i32 cur_node_mode,

    3: i64 xid,

}

  这是使用thrift脚本格式去定义的结构体,它包含三个部分:消息发送者的主机名my_host_name、当前状态cur_node_mode、发送者的数据版本xid

  Follower根据配置定时向Leader发送一个HBMSG,同时也接收一个Leader返回的HBMSG。若是发现返回的HBMSGLeader状态已经改变,那么它将结束Following流程。FollowerClient实现了一种超时机制,若是链接超时,HBMSGmy_host_name将被置为空串,这说明Leader失效,那么也将结束Following流程。

  而xid的做用就是告知FollowerLeader双方是否须要同步数据。若是Follower发现数据版本xid小于Leader,而且Follower接到Client的同步(sync方法的调用)请求,那么则能够主动的去Leader同步。通常状况下Followerxid可能会小于Leader一段时间,由于向Follower推送数据是Leader主动完成的。

  当集群刚刚选举完毕,Leader每每还不会对外提供读写服务,由于Cocklebur认为在对外服务以前还有可能加入xid更大的Follower。那么此时Leader便会主动的去pull数据。也就是说Follower只有在client请求其向Leader同步时,Follower才会pull数据。

Leader的实现

  Leader刚刚进入Leadering状态时会为每一个多数派其余成员初始化一个租约列表,每一个成员的租约期限有个默认值。以后就是不停的去减小租约表中的租约。若是接到了某个Follower申请租约的请求,Leader会为其从新审定租约期限。租约表就好像是一排沙漏,不停的漏沙子,而Follower按照必定时间间隔往本身漏斗中填一把沙子,保证不漏光。若是漏光了,那么Leader则会将其拿掉。若是有新的Follower加入,Leader则为其申请一个新的租约计时器。

  当租约表中的Follower与本身构不成一个多数派时,Leader将会退出Leadering流程。固然这里面能够对一些超时选项加以配置。好比租约表为空以后能够不当即退出,租约被申请屡次以后能够提升租约期限等等。

  上文中提到了Leader在决定是否要对外服务以前同步数据的问题。选举完成后,Leader不立刻让集群对外服务,而是等待一段时间看看时候还有新的Follower加入。若是这期间加入了FollowerLeader会轮流对其监察(经过HBMSG的方式),若检查发现xid比本身的大,则开始pull数据。数据操做后文会逐渐讲解。

  最后你们可能会有一些疑问,Xid较大,必定表明他数据最新且正确吗?其实在进行同步时Leader会有一些机制去监察数据是不是正确的,整个集群在写数据时每一个操做都记录在日志中,在任什么时候候集群中的每一个节点都是一个状态机,只要经历的步骤顺序正确,那么必定能够保证xid的正确性(经历有限相同状态转移以后状态一致)。该部分也将会在后文中阐述。

相关文章
相关标签/搜索