Raft算法之成员关系变化

上一篇文章:Raft算法之日志复制

Raft算法之成员关系变化

  有时候可能会遇到须要对集群中的成员数量进行更新的操做，比较简单的作法将更新操做分为两个阶段进行，在第一个阶段将所有的使用旧的配置文件的集群C_old成员所有关闭，因此将不能对客户端的请求进行处理。而后在第二个阶段使用新的配置文件启动集群成员。一个很明显的劣势在于更新成员数量的时候有一段时间是没法对客户端请求进行处理的。
  Raft使用了一种新的方案对成员进行更新。在两阶段更新之间加入了一个配置转换阶段，称为联合共识。引入联合共识阶段，集群在进行成员关系变化的同时，不须要关闭集群成员，从而能够在更新成员数量的过程当中也能够对客户端的请求进行处理。
  在联合共识阶段具备如下几点属性:

• 日志条目均复制到使用两种配置的全部服务器。
• 来自任一配置的任何服务器均可以充当领导者.
• 选举和日志的提交须要分别来自新旧配置的大多数人接受。

  联合共识容许集群中的单个服务器在不一样的时间从旧的配置转换为新的配置，从而不会影响安全性。而且在整个配置更新期间能够继续为客户端提供服务。

1 配置更新过程

1.1 理想状况

  以向集群中添加新的成员为例，正常状况下假设该过程不涉及客户端发送的其余的新的请求:
  假设旧的配置文件称为C_o,新的配置文件称为C_n,旧的集群称为C_old,新添加的成员称为C_new.

• 当集群C_old在正常运行过程当中(当前使用旧的配置文件C_o)，接收到来自客户端关于添加新成员的请求。
  • Leader接收到则直接处理，Follower接收到则会重定向到Leader.
• Leader建立一个用于更新配置的新的日志文件C_o_n(该日志配置文件表示C_old与C_new成员共存)，该配置文件按照正常流程复制到集群中大多数服务器(包括C_old,C_new)
  • 包括新成员C_new，服务器始终使用其日志中的最新配置，而无论该条目是否被提交，Leader将使用C_o_n规则来肯定什么时候提交C_o_n的日志条目。
  • 也就是说本地只持有C_o配置日志文件的成员仍然使用旧的配置文件。当接收到C_o_n配置文件以后不管是否已经应用到复制状态机，都会使用C_o_n配置文件做为服务器的配置文件。
• 当新的日志文件C_o_n成功在集群中提交以后，进入了联合共识阶段。
• 进入联合共识阶段以后，Leader建立一个新的用于配置更新的新的配置文件C_n,并将该日志发送到大部分C_new服务器(文献中是这么说的，至此还没搞明白为何不是全部的服务器)。

• 当配置日志文件C_n成功提交以后，则代表成员更新过程结束，集群使用新的配置文件C_n按照正常的流程继续运行。

  若是不考虑客户端发送的新的请求以及服务器崩溃的状况下，能够把配置更新看作一个普通的日志文件，按照正常流程发送，提交，应用后便成功完成配置的更新。惟一不一样的是普通的日志文件须要提交事后才会应用到复制状态机，而配置文件日志则是当服务器接收到以后，不管是否已经提交，接收到的配置信息都会生效。

1.2 联合共识阶段

  联合共识阶段:指的是C_o_n配置日志文件成功提交到集群中的大多数服务器，且C_n配置日志文件尚未提交到集群中的大多数服务器之间的时间段。
  在该阶段，任何操做(选举或者是其余的日志请求)对于C_old和C_new的成员来讲都不能单独作出决策。即须要C_old与C_new中的大部分服务器同时作出决策。(由于日志的提交条件是成功复制到大多数的服务器，因此当C_o_n日志文件被提交以后，有可能还存在部分的服务器没有接收到C_o_n日志文件,仍然处于C_old阶段,C_new的成员也是如此)

2 Leader崩溃状况

  分别从如下几个时间点说一下Leader在各个阶段发生崩溃的措施:

1. C_o_n配置日志文件未提交以前.
2. C_o_n配置日志文件提交以后，且C_n配置日志文件未提交前之间(联合共识阶段)的时间段
3. C_n配置日志文件提交以后.

2.1 C_o_n配置日志文件未提交以前

  从集群初始正常运行状态一直到C_o_n配置日志文件被提交这段时间，若是Leader奔溃，那么当选Leader的成员多是使用C_o的成员，也多是接收到C_o_n配置日志文件的成员。由于C_o_n配置日志文件还未被提交，因此C_old的成员能够单独作出决策。而C_new的成员还不能单独作出决策。

2.2 联合共识阶段

   C_o_n配置日志文件提交以后，且C_n配置日志文件未提交前之间的时间段，因为C_o_n配置日志文件只有当复制到C_old和C_new二者中大多数成员以后才被提交，因此当提交C_o_n配置日志文件以后，使用C_o_n配置日志文件的成员占所有服务器成员的大多数，所以，若是Leader崩溃，那么只能从使用C_o_n配置日志文件的成员中选取Leader。此时对于C_old和C_new的成员来讲都不能单独作出决策，所以也不能在使用C_o以及C_n的成员中选取Leader.

2.3 C_n配置日志文件提交以后

  当该日志提交以后，实际上已经完成了网络中成员关系的更新。因此Leader的选举便可和正常运行阶段相同。

3 存在的问题

  在成员关系更新阶段，主要存在三个问题:

1. 新添加的成员可能不会存储任何以前的日志条目，若是将它们加入集群，在日志条目与Leader完成同步以前，是没法提交新的日志条目的。
2. Leader可能不属于新配置集群中的一部分。
3. 假设更新成员关系是对集群中的成员进行删除，那么被删除的节点可能会扰乱集群。

3.1 问题一

  针对该问题，Raft的作法是引入一个新的状态，即容许新的成员以一种不具有决策权(选举和参与日志提交)的身份加入集群，所以在选举Leader或者是统计日志是否已经分发到大部分红员时，将不会考虑该成员。一直到该成员的日志存储状态追遇上集群中的其余成员，再赋予该成员决策权。

3.2 问题二

缘由：  该问题产生的缘由是可能新添加到集群中的新成员的数量要远远多于旧集群的数量(我的理解，若是有错误欢迎指出)。因为以前说到的C_n配置日志文件须要发送到C_new中的大多数成员，而Leader并不属于C_new中的一员。因此在发送C_n配置日志文件的时段，Leader将会对C_new的成员进行管理。
解决方案:  当C_n日志成功完成提交时，该Leader自动转换身份为Follower，而后从C_new的成员中选举出一个新的Leader.

3.3 问题三

缘由:  被删除的服务器若是没有关闭，那么他们将不会接收到心跳信息和日志信息，从而不断发生超时，最后致使任期不断增长(高于集群中全部成员的任期)，而后不断向集群中发送请求投票消息。集群中的Leader将变为Follower，集群中将不断开始新的选举。从而扰乱集群的正常运行。
解决方案:   Raft引入了一个最小选举超时时间，意思是若是集群中存在Leader时，而且接收到心跳信息以后在最小选举超时时间内接受到请求投票消息，那么将会忽略掉该投票消息。

下一篇文章:Raft算法之日志压缩