分布式系统的一致性与共识(1)-综述

分布式系统中的许多事情可能出错，最简单方法是让整个服务失效，并向用户显示错误消息。若无法接受，就得找到容错方法：即使某些内部组件出现故障，服务也能正常运行。

本文讨论构建容错分布式系统的算法和协议的一些案例。假设所有问题都可能发生：网络中的数据包可能会丢失、重新排序、重复推送或任意延迟；时钟只是尽其所能近似；节点可以暂停（如GC）或随时崩溃。

构建容错系统的最好方法，是找到一些带有实用保证的通用抽象，实现一次，然后让应用依赖这些保证。和事务处理方法相同：使用事务，应用可假装没有崩溃（原子性），没有其他人同时访问DB（隔离），存储设备完全可靠（持久性）。即使崩溃，竞态条件和磁盘故障，事务抽象隐藏了这些问题，因此应用不必担心。

现寻求可让应用忽略分布式系统部分问题的抽象概念。如分布式系统最重要的抽象之一：共识：让所有节点对某件事达成一致。正如我们在本章中将会看到的那样，要可靠地达成共识，且不被网络故障和进程故障所影响，是一个令人惊讶的棘手问题。

一旦达成共识，应用可以将其用于各种目的。假设你有一个单主复制的数据库。如果主库挂掉，并且需要故障切换到另一个节点，剩余的数据库节点可以使用共识来选举新的领导者。重要的是只有一个领导者，且所有的节点都认同其领导。如果两个节点都认为自己是领导者-脑裂，会导致数据丢失。正确实现共识有助避免这问题。

我们需要了解可以做什么和不可以做什么的范围：在某些情况下，系统可以容忍故障并继续工作；在其他情况下，这是不可能的。我们将深入研究什么可能而什么不可能的限制，既通过理论证明，也通过实际实现。我们将在本章中概述这些基本限制。

分布式系统领域的研究人员几十年来一直在研究这些主题，所以有很多资料 —— 我们只能介绍一些皮毛。在本书中，我们没有空间去详细介绍形式模型和证明的细节，所以我们会按照直觉来介绍。如果你有兴趣，参考文献可以提供更多的深度。

1 一致性保证

数据库复制中发生的一些时序问题。同一时刻查看两个数据库节点，则可能在两个节点上看到不同的数据，因为写请求在不同的时间到达不同的节点。无论数据库使用何种复制方法（单主复制，多主复制或无主复制），都会出现这些不一致。

大多数复制的数据库至少提供最终一致性，即若停止向DB写并等待一段不确定时间，则最终所有读取请求都会返回相同值。即不一致现象只是暂时，最终会达到一致。最终一致性意味着收敛（convergence），即预期所有副本最终会收敛到相同值。

但这是个很弱保证，不知何时系统收敛。收敛前，读可能会返回任何值甚至读失败。如若你写入了一个值，然后立即再次读取，这并不能保证你能看到刚才写入的值，因为读请求可能会被路由到其它副本。

对于SE，最终一致性很难，和普通的单线程程序中变量读写行为很不同，若将一个值赋给某变量，再很快读取，不可能读到旧的值或读取失败。而DB表面上看起来像个可读写的变量，其实有更复杂的语义。

和只提供弱保证DB打交道时，需始终意识其局限性。当系统故障（如网络中断）或高并发时，最终一致性的边缘情况才会凸显。

因此，本文探索数据系统更强的一致性模型，可能会比保证较差系统具有更差性能或更低容错性。但更强的保证能吸引人，因为它们不容易出错。熟悉不同的一致性模型，才能更好地决定最适合的。

分布式一致性模型和之前讨论的事务隔离级别的层次结构有相似。尽管两者有一部分内容重叠，但它们大多是无关问题：事务隔离主要是为避免由于同时执行事务而导致的竞争状态，而分布式一致性主要关于在面对延迟和故障时如何协调副本间的状态。

本章涵盖广泛话题，但我们将会看到这些领域实际上紧密联系在一起：

• 最强的一致性模型：线性一致性（linearizability）
• 然后检查分布式系统中事件顺序问题，特别是因果关系和全局顺序
• 最后探讨如何原子地提交分布式事务，最终引领我们走向共识问题的解决方案