eBay支付账务系统之从“容”不迫——一种简化的Raft集群扩容策略

导  读

1

背  景

Raft算法中多个节点管理一份复制的日志。该日志记录来自客户端的请求。图1展示了Goblin集群不同规模的构建情况。

图1：3节点和5节点Goblin集群结构及其quorum

正常状态下，其中一个节点承担leader角色，而其他节点则作为follower工作：请求发送到leader节点，然后leader将不断增长的日志复制给follower。如遇leader故障，follower将转变为candidate角色，启动新一轮leader选举。值得强调的是，日志复制和leader选举都依赖于集群中选举法定成员(quorum)的存活，否则无法成功执行。随着quorum的增加，集群对节点故障的容错能力也增强。例如，一个3节点的Raft集群(quorum=2)最多可以容忍1个节点故障，而一个5节点的Raft集群(quorum=3)可以容忍2个节点故障。扩容策略的主要目标是在确保可用性和安全性的同时，寻找可行的解决方案来将Goblin的3节点集群扩容到5节点。

Raft算法为分布式计算集群中的状态机提供了一种易于理解的共识方法，确保所有节点在相同的状态转换序列上达成一致性。在集群成员变更的情况下，Raft论文中提出了Joint Consensus[3]策略(RJCS)，来确保集群组成成员重新配置时的安全性，并防止在单个任期中出现多个leader(脑裂)的风险。RJCS无需任何节点的重启，通过向集群leader发送配置命令，然后leader向follower复制日志的方式来进行集群成员配置的状态转移。然而，Goblin节点目前的实现需要重启完成配置更新。在Goblin中实现RJCS会引入了额外的复杂性。

为了降低系统复杂性并保障Goblin集群节点个数扩容的平稳迅速落地，我们需要设计一种更简单直接的Raft集群扩容策略。该策略必须保证在单个节点逐一重启以进行配置变更的期间，集群也能保持不间断的可用性，并且在扩容过程中规避集群脑裂风险。

2

初始策略及其缺陷 

优先添加新节点

在扩容Goblin集群时，一种将一个3节点的Raft集群扩容为5节点的初步策略是优先添加两个具有5节点配置的新节点，然后更新原始3节点的配置。

然而按照这种方法，一旦添加了新节点，集群将无法保持可用性。在新添加的follower节点后，原始节点对集群成员变化不知情，原始集群中的leader不会将日志复制给新节点。同时，由于新添加的节点无法接收来自现有leader的日志追加请求，它们将持续不断地发送选举请求以启动新一轮的选举。Raft算法为解决非拜占庭问题的一致性而设计，它假设网络中不存在冲突或故意误导性的消息，所以这种持续的选举请求将导致原始集群中的leader被反复下台。由于集群在leader下台后的选举期间无法提供服务，集群变得不可用和不稳定，如图2所示：

图2: Leader节点被新增节点反复罢免的场景

优先配置原节点

为了解决上述问题，另一种初始策略是优先重新配置原始节点（S1、S2、S3），然后将两个新节点（S4、S5）添加到集群中，如图3中所示。然而该策略下，集群的可用性无法保障。在重新配置过程中，每个Goblin节点都需要重启以加载新配置。当S3停机时，集群中仅剩下S1、S2存活，并且它们已经是5节点集群中的成员，而选出leader至少需要3票(quorum)，所以无法选出leader，导致集群完全不可用，如图3中第3步所示。

图3: 集群扩容中的不可用场景

实际上，在完成集群扩容后，该策略还存在另一个缺陷。即使在原始的3节点集群中添加了两个节点，形成了一个5节点的集群，集群仍然在相当长的一段时间内容易出现不可用的情况，如图3中第4步所示。具体来说，新添加的S4和S5节点加入集群时没有任何现有的日志，这些节点需要时间从leader同步日志。在追赶的过程中，假如（S1、S2、S3）中的任何一个节点发生故障或停机，集群将无法提交新的日志。这是因为只有（S1、S2、S3）中的剩余两个节点可以接受新的日志，但它们在5节点集群中不构成选举法定成员个数(quorum)，导致日志无法提交，写入请求无法完成。

 使用 learner 节点

Raft learner节点

Learner角色在Raft集群中充当非选举成员。它的工作责任是只接受来自leader的日志，不参与竞选leader，也不进行投票，因此learner不计入集群的quorum，添加它们不会影响集群的可用性，如图4所示。

图4:带有learner节点的Goblin集群及其quorum

learner可以用于提高集群的读并发能力，在将状态复制到大量learner节点后，这些节点可以处理具有松散一致性要求的只读请求。此外，learner在集群成员配置变更方面发挥着关键作用。正如前面提到的，新添加的成员可能需要大量时间来追赶集群中现有的日志。为了解决这个问题，可以将这些新节点添加到集群中作为learner角色。一旦新节点成功追赶了集群中其余节点的日志，配置变更过程就可以继续进行。

结合learner的方案

基于上述learner节点的特性，我们在Goblin的底层Raft代码(名称Gringofts[4]，已由FAS团队开源)中开发了learner有关逻辑并将其应用于Goblin集群扩容。基于learner的优化策略如图5所示：

图5: 带有learner节点的优化策略的扩容步骤

首先添加两个新的learner节点（S4、S5），并使得原始节点（S1、S2、S3）知晓learner的加入，由于learner对原始集群的quorum毫无影响，也不会发送选举请求，因此添加learner过程和Goblin的版本升级并无差别。添加learner后，给予它们足够的时间来追赶日志。一旦learner的日志已经同步到最新，它们可以通过重新配置变更为follower节点。这种策略通过引入learner角色，防止前述的集群在完成配置之后出现不可用性缺陷。

在将（S4、S5）变更为follower之后，它们已经被配置为5节点集群中的成员，接下来只需要如图5的第四步所示，逐个重新配置原始节点（S1、S2、S3）。由于该过程中，集群中存活可用的节点个数始终大于quorum，确保集群可以选出leader，也可以进行日志提交，不会变为不可用状态。这解决了前述的在S3节点重启未就绪期间集群不可用的缺陷，通过精心管理重新配置步骤，保持了集群的可用性，实现了无缝的扩容过程。

此外，如图5中第三步所示，此操作还确保了将新添加的节点从learner变更为follower后不会导致leader反复下台问题（如图2所示）。即使此时新加入的follower节点能够发送选举请求，在原始节点（S1、S2、S3）的视角中，（S4、S5）仍然是learner角色。因此，原始节点（S1、S2、S3）中的leader角色仍然会将日志发送到（S4、S5），因此它们不会转换为candidate进而发送选举请求。极端情况下，可能由于网络故障，（S4、S5）在规定期限内未收到leader的日志追加请求从而转换为candidate开始发出选举请求，但来自被视为learner的节点发送的选举请求会被忽略，也就不会使得leader下台。这种方法保持了集群的稳定性和可用性，避免了前述的由于引入新节点导致的集群不稳定性缺陷。

脑裂风险

必须指出的是，上述基于learner的优化策略虽然解决了可用性问题，但仍然有自己的缺陷，那就是无法避免脑裂风险。

如果出现网络分区，脑裂的发生源于集群中存在总共5个有效的选举成员，即3节点集群成员和5节点集群成员同时存在，如图5的第4步所示。在这种情况下，来自3节点集群的leader只需要2票，而来自5节点集群的leader则需要3票，这5个节点可以形成两个quorum：一个3节点集群和一个5节点集群。例如，在图6中，S1重新配置后，S1、S4和S5可以构成5节点集群的主体，而S2和S3同时可以形成3节点集群的主体。这使得集群中有可能同时存在两个leader，导致在网络分区下出现脑裂情况。为了防止这种情况发生，需要仔细管理节点的变更，并找到一种方式，确保在任何情况下只有一组节点形成选举法定成员个数（quorum）。

Figure 6: 网络分区下的集群脑裂场景之一

4

最终推荐策略

规避脑裂风险

为了解决脑裂问题并在扩容过程中保持可用性，本文推荐的最终策略如图7所示。该策略和图5相比，在第3步时，只将learner S4变更为follower角色，最后在第5步中，完成对剩余的learner S5节点的变更。通过精心管理节点的变更过程，始终保持有效的可选举节点个数少于5，有效地避免了脑裂的情况。该策略确保没有机会出现两个leader共存，从而维护了变更时的安全性和稳定性。

该推荐策略和图5中的策略一样，通过learner的引入，解决了前述的新增节点导致的一系列缺陷。与此同时，虽然该策略扩容过程中，有效的可选举节点个数相比图5更少，但仍然可以解决可用性问题。如图7所示的第4步，在对S1、S2、S3进行重新配置的过程中，集群中有效可选举成员的最小数量为三个，即在（S1、S2、S3）中存在两个成员，而S4也是一个有效可选举成员。换句话说，它们始终可以构成一个5节点集群的quorum，这意味着可以选出leader，保障了集群的可用性。

图 7: 保障可用性以及规避脑裂风险的推荐策略的扩容步骤

结 语