作者: Unmesh Joshi
译者: java达人
通过要求法定多数做出每个决策,以避免两组服务器独自决策。
问题
在分布式系统中,每当服务器执行操作时,都需要确保在发生崩溃的情况下,客户端可以使用这些操作的结果。这可以通过将结果复制到集群中的其他服务器来实现。但是,这引出了一个问题:需要多少其他服务器确认复制,原服务器的更新才会被认可。如果原始服务器等待太多复制,则它将响应缓慢-活跃性减少。但是,如果没有足够的复制,则更新可能会丢失-失去安全性。在整体系统性能和系统连续性之间取得平衡是至关重要的。
解决方案
当集群中的大多数节点已确认更新时,集群同意已收到更新。我们称这个数字为quorum法定数。因此,如果我们有五个节点的集群,则需要quorum 3。(对于n个节点的集群,quorum 为n / 2 +1。)quorum 表明可以容忍多少个故障-即集群的大小减去quorum。五个节点的集群可以容忍其中两个故障。通常,如果我们要容忍“f”个故障,则需要一个2f +1的集群大小
考虑以下两个需要quorum的示例:
• 更新服务器集群中的数据。High-Water Mark用于确保只有保证在大多数服务器上可用的数据才对客户端可见。• 领导者选举。在“领导者和追随者”模式中,仅当领导者从大多数服务器中获得选票时才被选择。
确定集群中的服务器数量
仅当大多数服务器都已启动并正在运行时,集群才能运行。在进行数据复制的系统中,需要考虑两件事:
•写操作的吞吐量。每次将数据写入集群时,都需要将其复制到多个服务器。每个附加的服务器都会增加一些开销,以完成此写操作。数据写入的等待时间与构成quorum的服务器数量成正比。正如我们将在下面看到的,将集群中的服务器数量加倍会使吞吐量降低到原始集群值的一半。
• 需要容忍的故障数量。允许的服务器故障数取决于集群的大小。但是,仅将一台服务器添加到现有集群并不总是能提供更多的容错能力:将一台服务器添加到三台服务器集群并不能提高容错能力。
考虑到这两个因素,大多数实际的基于quorum的系统的集群大小为3或5。一个由五台服务器组成的集群可承受两台服务器故障,并且每秒可处理数千个请求的数据写入吞吐量。
这是一个根据可容忍的故障数以及对吞吐量的大致影响来选择服务器数量的示例。吞吐量列显示近似的相对吞吐量,以突出显示吞吐量如何随服务器数量而降低。实际数量因系统而异。
例如,读者可以参考Raft Thesis和Zookeeper原创论文中发布的实际吞吐量数据。
例子
• Zab,Raft,Paxos等所有共识实现都是基于quorum的。• 即使在未使用共识的系统中,quorum也可用于确保在出现故障或网络分区时至少一台服务器可以使用最新更新。例如,在像Cassandra这样的数据库中,可以将数据库更新配置为仅在大多数服务器成功更新了记录之后才返回成功。
