美文网首页
Part 12:Raft论文翻译-《CONSENSUS BRID

Part 12:Raft论文翻译-《CONSENSUS BRID

作者: Number9527 | 来源:发表于2021-08-07 00:31 被阅读0次

Part 12:Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》(基础Raft-小结)
3.11 Conclusion(小结)
本章讨论了基于共识系统的所有核心问题。Raft超越了就单个值达成共识,就像在单个提案的Paxos算法中一样;它对不断增长的命令日志达成了共识,这是构建一个复制状态机所必需的。它还包括在达成协议后传播信息,以便其他服务器学习已提交的log entry。Raft通过选择一个集群Leader来单方面做出决定,并在一个新的Leader胜选时只传输必要的log entry,以一种实际和有效的方式达成共识。我们已经在LogCabin中实现了Raft算法,LogCabin是一个复制状态机(在第10章描述)。

Raft只使用了少量的机制来解决共识涉及的全部问题。例如,它只使用两个RPC(RequestVote和AppenEntries)。也许令人惊讶的是,创建一个紧凑的算法/实现并不是Raft的首要目标。相反,这是我们设计的可理解性的附带结果,其中每一个具体机制的选择都必须得到充分的激励和解释。

除非我们确信某个特定的问题会很大程度的影响Raft的部署,否则我们就不在Raft中解决它。因此,Raft的部分算法会显得很直白。例如,Raft中的服务器通过等待选举超时来检测分裂投票;原则上,他们通常可以通过计算投给任何Candidate的选票来更早地发现甚至解决分裂选票。我们选择不为Raft涉及相应优化方法,因为它增加了复杂性,但可能没有带来实际的好处:在配置良好的部署中,分裂投票很少见。Raft的其他部分可能显得过于保守。例如,Leader只能直接提交其当前term的log entry,即使在某些特殊情况下,它可以安全地提交前任Leader的log entry。应用更复杂的承诺规则将损害可理解性,并不会对性能产生重大影响;当前规则的承诺只会短暂延迟。在与他人讨论Raft时,我们发现许多人不禁想到这样的优化并提出它们,但当目标是可理解的时,应该忽略过早的优化。

不可避免地,本章可能会遗漏了一些在实践中有用的特性或优化。随着实现者在Raft方面获得更多的经验,他们将学习何时以及为什么某些附加特性可能有用,并且他们可能需要在一些实际部署中实现这些特性。在本章中,我们概述了一些我们目前认为不必要的可选扩展,但如果有需要,这可能有助于指导实现者。聚焦于可理解性,我们希望为有经验的实现者提供了坚实的Raft基础。由于Raft在我们的测试环境中工作,我们期望仅仅作为扩展而不是彻底的改变在Raft中采用。

<< 上一章:Raft算法-Leader转换
下一章:Raft算法-集群变更总述 >>

相关文章

网友评论

      本文标题:Part 12:Raft论文翻译-《CONSENSUS BRID

      本文链接:https://www.haomeiwen.com/subject/zxubvltx.html