共识算法的扩展性：第一部分 – 引言
请务必跟随这八部分系列文章的探索。在每篇文章底部都可以找到链接到整个系列的所有文章。
引言
理论与应用形式的共识算法可能让人感到难以理解。这些算法通常是一些不经意间解决了很棒问题的方法。然而，不幸的是，问题正在不断演变。我认为这些解决方案可能不会在未来很长时间内保持相关性。让我们首先定义它们解决的核心问题：
- 分布式持久性：在节点故障的情况下，数据会被保证出现在其他地方。
- 可用性：即使某些节点不可用，系统仍然能够继续服务。
- 自动化：如果发生故障，系统能够在无需人工干预的情况下自行修复。
严格来说，可以认为自动化是一个不同的理论问题，因为它需要故障检测。但现实情况是，今天的系统希望共识系统能满足上述所有属性。
我们换个角度思考：如果我们从这些需求开始，会不会最终选择像Paxos或Raft这样的方案作为最佳解决方案？要回答这个问题，我们需要更好地理解这些需求。
更重要的是，云服务提供商正在推出更复杂的拓扑结构，例如可用区（Zone），以及跨区域的架构（Region）。这些服务商的定价模式鼓励特定配置。我们构建的系统需要具备适应这些细微差别的能力。这些刚性算法的灵活性耗尽只是时间问题。
这里稍微透露一些：我们正在开发Vitess以构建这种灵活性。您可以指定对您来说重要的事项，以及您愿意接受哪些（合理的）权衡。Vitess将为您提供精确匹配这些参数的调节机制，同时不会在其他方面做出妥协。
然而，我们仍然需要回答持怀疑态度的人的问题：是否可以使用“原生的MySQL”构建这样的系统？简短的答案是：可以。
方法
在本系列博客文章中，我会带领大家一起探讨共识算法。我们将把它们拆分成更小的关注点，并使用一系列更灵活的算法来建立新的规则和原则。这些算法是我们可以构建的，最后我们将讨论如何在Vitess中实现这些目标。
作为一个免责声明，这是一个工程方法。因此，如果您期待看到理论证明，可能会感到失望。我会分享和运用从大规模存储系统实践中积累的直觉。基于此，我们对问题的处理方式会做出两点调整：
- 使用工程术语。这主要是为了我自己的便利，因为很难去理解学术概念如何映射到真实世界的场景中。
- 基于目标的解决方式：采用自上而下的方法来分析问题，明确关注点，并保持它们分离。
第二点至关重要，因为大多数共识算法会执行一些协同动作，这些动作同时达成多个目标。因此，如果采用另一种方法，很难知道某个决策为何以这种方式做出，以及它的权衡点是什么。
通过更好的理解各个关注点，我们可以做出更优的权衡，而不会被僵化的实现方式所困扰。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
