分布式系统的仲裁模式


任何分布式系统的常量之一是失败。我们构建的系统能够抵御故障。假设我们想要复制到集群中的不同节点以实现高可用性和容错。我们需要问的下一个问题是——
我们集群中有多少节点需要确认他们从原始服务器获得了复制副本,然后我们才能说对这个分布式系统的更新是成功的?
”Quorum 仲裁/法定人数“是上述问题的答案。Quorum 是在标记成功之前必须确认分布式操作成功的服务器的最小数量。
但为什么我们需要法定人数?如果我们选择不使用 Quorum 会怎样?

场景 1:将更改复制到集群中的所有节点
我们可以将更改复制到集群中的所有节点,而不是将更改复制到法定节点。然后源服务器等待所有服务器的确认。这可能会导致源服务器的确认缓慢(性能影响),也可能会影响应用程序的可用性,因为我们总是需要所有服务器来确认任何操作。如果任何服务器宕机/网络分区,操作将不会被成功确认。

场景 2:不要复制更改
我们可以选择根本不复制更改。在这种情况下,我们冒着丢失更新的风险(如果在我们的示例中数据没有刷新到 WAL)。这也会影响一致性,因为写入特定服务器的数据更改在服务器启动之前将不可用。
多少才够?
我们将 Quorum仲裁 定义为在操作成功之前需要确认操作的最小服务器数量。但是什么是一个好的数字,这样我们才能同时获得良好的应用程序性能和一致性。
我们通常更喜欢集群中的大多数节点确认任何操作以使其被认为是成功的。因此,对于一个 N 节点集群,Quorum 应该是 N/2 + 1 个节点。
如果我选择 Quorum > N/2 + 1 怎么办?好吧,您将有更多数量的节点来确认您的更改,因此与选择 N/2 + 1 作为 Quorum 相比,您的性能会受到影响。请参阅情景 1 了解影响。
如果我选择 Quorum < N/2 + 1 怎么办?在这种情况下,集群中只有少数节点可以保证发生变化。如果这些节点出现故障/网络分区,则最终用户将看不到更改并且会出现一致性问题。请参阅情景 2 了解影响。

法定人数和可容忍的失败
Quorum 还帮助我们根据集群大小确定可以容忍的节点故障数。
允许的故障服务器数 = 集群中的服务器数 - 仲裁中的服务器数
下表给出了一个表格,我们可以从中得出不同集群大小允许的故障节点数 -

您应该注意的一件事是奇数和偶数集群对中的仲裁是相同的(例如:4 和 5 节点集群都需要 3 个节点的仲裁)。这也意味着应该首选 Odd 集群大小,因为 Quorum 将与 Even偶数 节点集群相同,而 Odd奇数 集群大小的故障节点容忍度将更高。

现实生活中的使用

  • 1) Paxos 和 Raft 等共识算法都是基于 quorum 的。
  • 2) Cassandra 使用写入仲裁来确保数据一致性,其中写入只有在复制到至少一个仲裁的副本节点后才被认为是成功的。
  • 3) 仅当领导者从大多数服务器(即 Quorum)获得投票时才会进行领导者选举。

简而言之,Quorum 允许我们在分布式系统中实现一致性,并具有良好的吞吐量/性能。