mit6824-06-Raft学习记录01

文章目录

必要知识
- 单点故障
- 脑裂
- 多数原则

近日开始学习分布式共识算法Raft，慢慢记录一些自己能看懂的东西。

优质博客：

Raft原理详解

必要知识

单点故障

单点故障（single point of failure）：服务器中某台机器出现故障。
前面介绍过的复制系统，都存在单点故障问题(single point of failure)。

mapreduce中的cordinator
GFS的master
VM-FT的test-and-set存储服务器storage

而上诉的方案中，采用单机管理而不是采用多实例/多机器的原因，是为了避免脑裂(split-brain) 问题。

不过大多数情况下，单点故障是可以接受的，因为单机故障率显著比多机出现一台故障的概率低，并且重启单机以恢复工作的成本也相对较低，只需要容忍一小段时间的重启恢复工作。

脑裂

以VM-FT系统为例了解学习脑裂：
以VM-FT的test-and-set存储服务器storage举例。假设我们复制storage服务器，使其有两个实例机器S1、S2。（即打破单机管理的场景，看看简单的多机管理下有什么问题）

此时C1想要争取称为Primary，于是向S1和S2都发起test-and-set请求。假设因为某种原因，S2没有响应，S1响应，成功将0改成1，此时C1可能直接认为自己成为Primary。

这里S2没有响应可以先简单分析两种可能：

S2失败/宕机了，对所有请求方都无法提供服务：如果是这种情况，那么C1成为Primary不会有任何问题，S2就如同从来不曾存在，任何其他C同样只能访问到S1，他们都会知道自己无法成为Primary，并且整个系统只会存在C1作为Primary。
S2和C1之间产生了网络分区(network partition)，仅C1无法访问到S2：这时候如果存在C2也向S1和S2发出请求，此时S1虽然将0改成1会失败，但是S2会成功。如果我们的协议不够严谨，这里C2会认为自己成为了Primary，导致整个系统存在两个Primary。这也就是严重的脑裂问题。

产生这种问题的原因在于，对于请求方，无法简单地判断上诉两种情况，因为对他们来说两种情况的表现都是一样的。

为避免出现脑裂，我们需要先解决网络分区问题，下面的多数原则就很好解决了网络分区问题。

多数原则

诸如Raft一类的协议用于解决单点故障问题，同时也用于解决网络分区问题。这类解决方案的基本思想即：大多数原则(majority rule)，简单理解就是少数服从多数。

这里的majority指的是整个系统中无论机器的状态如何，只要获取到大于一半的赞成，则认为获取到majority。比如系统中有5台机器，2台宕机了，5台的一半为2.5，但2.5不为有效值，即获取3台机器赞成，认为获取到majority；如果5台中宕机3台，那么没有人能获取到至少3台的赞成，即无法得到majority。

同样以VM-FT的test-and-set存储服务器storage举例，这次storage不是复制出2个实例，而是总共复制出3个实例，S1、S2、S3。

此时C1同时向S1、S2、S3请求test-and-set，其中S1和S2成功将0改成1，S3因为其他问题没有响应，但是我们不关系为什么。这里按照majority rule，只要3个S中有2个给出成功响应，我们就认为C1能够成为Primary。此时就算同时有C2向S1、S2、S3发起请求，就算S3成功了，C2根据majorty rule，3台只成功1台，不能成为Primary。

为什么根据majority rule，这里就不会出现脑裂，因为能确保多个C之间的请求有重叠部分(overlap)，这样根据majority rule，多个C最后也能达成一致，因为只有1个C有可能成为多数的一方，其他C只能成为少数的一方。

在之后准备介绍的Raft，和这里描述的工作流程基本一致。

在majority rule下，尽管发生网络分区，只会一个拥有多数的分区，不会有其他分区具有多数，只有拥有多数的分区能继续工作（比如这里3台被拆成1台、2台的分区，只有和后者成功通信的能继续工作）。
而如果极端情况下所有分区都不占多数（比如这里3台被拆成1台、1台、1台的分区），那么整个系统都不能运行。
上诉3台的场景，只能容忍1台宕机，如果宕机2台，那么任何人都无法达到majorty的情况。这里通过2f+1拓展可容忍宕机的机器数，f表示可容忍宕机的机器数量。2f+1，即使宕机了f台，剩下的f+1>f，仍然可以组成majority完成服务。

例如，当f=2时，表示系统内最多可容忍2台机器处于宕机状态，那么至少需要部署5台服务器（2x2+1=5）。