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中采用。
