Raft算法之集群成员变化篇

一、集群成员变化可能带来的问题

集群成员变化是一个常见操作,主要是增加、删除节点,主要的场景有升级、服务器老化等,当然如果我们对服务的SLA没太大要求,直接关闭集群是最简单的办法。但如果要保证系统的可用性而动态地添加、删除节点并且保证不会脑裂等问题则需要一个安全的算法,所以Raft算法把这一部分也纳入其中。

直接将集群成员配置从旧配置切到新配置会有脑裂问题,举个例子:

Raft算法之集群成员变化篇_第1张图片

上图中集群原来有3个节点:Server1、Server2、Server3,现在要增加2个节点:Server4、Server5,我们来设想下具体的操作步骤:

1、Server4和Server5是新节点,所以这2台机器启动的时候认为集群中有5个节点;

2、然后修改Server3的配置,改成5节点;

这时发生选举,即上图中红色箭头所指的位置,这时候每个节点看到的集群成员如下,为了方便描述,统一将Server字样去掉,即只保留1、2、3、4、5,1表示Server1:

1:1、2、3

2:1、2、3

3:1、2、3、4、5

4:1、2、3、4、5

5:1、2、3、4、5

这时1通过2的投票可以被选举为Leader,因为1和2认为集群只有1、2、3总共3个节点;

3通过3,4,5这3个节点的投票被选举为Leader;

这样集群同时存在1和3两个Leader了。

二、变更方案

官方给的方案是二阶段变更:

集群先从旧成员配置Cold切换到一个过渡成员配置,称为共同一致(joint consensus),共同一致是旧成员配置Cold和新成员配置Cnew的组合Cold U Cnew,一旦共同一致Cold U Cnew被提交,系统再切换到新成员配置Cnew。

具体过程如下:

Leader收到从Cold切成Cnew的成员变更请求,Leader分两步操作:

1、提交配置Cold U Cnew

Leader在本地生成一个新的日志,这个日志的类型是成员配置,其内容是Cold∪Cnew,代表当前时刻新旧成员配置共存,写入本地日志,但并不提交;

Leader同时将该日志复制至Cold∪Cnew中的所有副本,在此之后新的日志同步需要保证得到Cold和Cnew两个多数派的确认;

Follower收到Cold∪Cnew的日志后更新本地日志,并且马上就以该配置作为自己的成员配置;

如果Cold和Cnew中的两个多数派确认了Cold U Cnew这条日志,Leader就提交这条日志;

2、提交Cnew

接下来Leader生成一条新的日志条目,类型也是成员变更,其内容是新成员配置Cnew,同样将该日志条目先写入本地日志,同时复制到Follower上;

Follower收到新成员配置Cnew后,将其写入日志,并且马上就以该配置作为自己的成员配置,并且如果发现自己不在Cnew这个成员配置中会自动退出。

可以看到,Raft算法将成员配置的变化也作为一条日志,需要经过一轮Raft过程像应用操作一样只要大多数节点确认了就肯定不会出出脑裂了。注意Follower收到配置后马上就变更,而不需要等Leader下次发送commitIndex的时候才提交,这点是和正常应用提交不一样的地方。

这里不去做详细的证明,官方有详细说明,我们可以看下几个异常,还是以上面的例子,当前集群有3个节点:1、2、3,现在要增加2个节点:4、5,假设当前Leader为1,具体过程如下:

1)节点1收到成员变更的请求,生成一条日志类型为成员变更,内容为:1、2、3、4、5,节点1将这条日志先保存到本地,但不马上更改成员配置;

2)节点1将上述日志同步给2,3,4,5四个节点;

3)2、3、4、5节点收到配置后做2件事:追加日志,马上变更自己的成员配置为:1、2、3、4、5;

4)节点1只要收到2个以上节点回复马上将自己成员配置为:1、2、3、4、5.

我们看有哪些异常:

如果有1-2过程中失败了,则整个过程就算失败,则需要管理员重新发起成员变更操作;

如果第3步只有1个节点即不是集群多数节点收到变更,这个时候节点1挂了,如果收到日志的先发起选举则有可能推进这条日志,否则就不成功,即有可能丢失;

如果在第4步节点1挂了的话,新集群肯定是有这个配置的,因为根据日志最新原则,新选举出来的Leader肯定包含上面成员变更的日志。

三、其它问题

1、新加的成员入无日志

一开始的时候新的服务器可能没有任何日志条目,如果它们在这个状态下加入到集群中,那么它们需要一段时间来更新追赶,在这个阶段它们还不能提交新的日志条目,这个时候节点没有投票权,有的文章说叫Catch-Up。

2、移除不在 Cnew 中的服务器可能会扰乱集群

主要是移除的情况,设想一个集群有5个节点:1,2,3,4,当前Leader是2,现在要把1移除掉,假如2已经将新的成员配置:2,3,4已经同 步给3和4了,如果配置不发给1,因为2认为集群中1不存在了,所以不会向1发心跳,而1没收到2的心跳,会增加自己的Term发起选举,其它成员收到后会退化成Follower,不过不会给1投票,因为1的日志不是最新的,不过这会影响集群的可用性。

针对这个问题,官方给的是PreVote,即在发起投票的RequestVote RPC请求之前再发一个PreVote请求,只有通过这个才正式发起RequestVote,这样可以大大提升系统的可用性。其实还有1个更简单的办法,直接将1关机或者将服务程序Kill掉。

image.png

你可能感兴趣的:(raft,分布式)