凡是做服务器开发的技术同学,估计都对分布式系统以及相关的理论感兴趣。而对于分布式理论,大家讨论的最多的恐怕就是「分布式一致性」问题了。然而,不管是学术界还是业界的发展历史上,对于「一致性」这个概念的理解,始终充满了混乱。

如果你问一个技术同学,到底什么是分布式一致性,估计会得到五花八门的答案。这其中比较常见的说法可能是这样的:一致性就是多个服务器节点中的数据保持一致(至少百度百科上差不多就是这么说的)。而如果再讨论得深入一点,可能就会谈到所谓的分布式一致性协议,比如Paxos之类的;还有CAP定理,也跟「一致性」有关。

但是,「一致性」这个词是非常有迷惑性的。如果用英文来表达的话,跟「一致性」有关的至少有两个词:consistencyconsensus。它们经常都被翻译成「一致性」,这进一步加剧了这个概念被滥用的程度。为了接下来讨论方便,我们先简单地澄清一下:

  • 网上通常提到的诸如Paxos之类的分布式一致性协议,其实是consensus这个词。它如果被翻译成「共识」,可能会更好一些。为了表达清晰,本文后面在讨论consensus问题的时候,尽量使用「共识」这个词。
  • ACID或CAP里C,用的都是consistency这个词,但真实含义迥然不同。
  • 此外,还经常会听到人们关于「强一致性」的说法,而且这种说法通常都会牵涉到CAP定理或者「分布式事务」的概念。「强一致性」与CAP定理确实关系密切,但与「分布式事务」的关系却不知从何而来。

下面,我们就对这些概念进行详细的解析。

ACID中的一致性

ACID是数据库事务的四个特性,分别是原子性 (Atomicity)、一致性 (Consistency)、隔离性 (Isolation)和持久性 (Durability)。

我们现在关注的是其中的C,即一致性Consistency。它是什么意思呢?通俗地说,它指的是任何一个数据库事务的执行,都应该让整个数据库保持在「一致」的状态。那怎样的状态才算「一致」呢?举个例子,假设在银行账户之间进行转账。显然,「转账」这个操作应该确保在转账前后账户总额保持不变,这是任何一个转账操作必须要遵守的规定。现在假设要从账户A向账户B转账100元,于是我们启动了一个数据库事务。在这个事务中,可以先从账号A中减去100元,再往账户B中增加100元。这样的一个事务操作,满足了“转账前后账户总额保持不变”的规定,因此我们说:这个事务操作保持了数据库的「一致性」;同时,在这个事务执行前后,数据库都处于一种「一致」的状态。

从上一段的描述中,我们容易看出:

  • ACID中的「一致性」,是对于整个数据库的「一致」状态的维持。抽象来看,对数据库每进行一次事务操作,它的状态就发生一次变化。这相当于把数据库看成了状态机,只要数据库的起始状态是「一致」的,并且每次事务操作都能保持「一致性」,那么数据库就能始终保持在「一致」的状态上 (Consistency Preservation)。
  • 所谓状态是不是「一致」,其实是由业务层规定的。比如前面这个转账的例子,“转账前后账户总额保持不变”,这个规定只对于「转账」这个特定的业务场景有效。如果换一个业务场景,「一致」的概念就不是这样规定了。所以说,ACID中的「一致性」,其实是体现了业务逻辑上的合理性,并不是由数据库本身的技术特性所决定的。

我们再来看一下,为了让事务总是能保持ACID的一致性,我们需要在实现上考虑哪些因素呢?

至少两个方面需要考虑:一个是出错情况 (failure/error);一个是并发 (concurrency) 行为。

首先,对于任何系统来说,错误都是在所难免的。而错误又可以细分为两类。

第一类,事务本身的实现逻辑可能存在错误。比如,从账户A向账户B转账100元,在这个事务中,如果我们只从账号A中减去了100元,但忘记了往账户B中增加100元,那么这个事务就是错误的。显然,避免第一类错误,是保持一致性的前提,这需要应用层进行恰当的编码来保证。

第二类,则是意想不到的各种软硬件错误。比如,还是从账户A向账户B转账100元,事务本身的实现逻辑没有问题,它先执行了从账号A中减去了100元,但在执行往账户B中增加100元之前,却发生了意想不到的错误,比如进程突然crash了,或是磁盘满了,或是网络突然不通了,或是其它任何可能的硬件错误。这时候,事务只执行了前一半,势必会破坏数据库整体状态的一致性。那怎么办呢?这其实就需要ACID中的A(原子性)来保障了。简言之,原子性保障了事务的执行要么全部成功,要么全部失败,而不允许出现“只执行了一半”这种“部分成功”的情况。

其次,并发行为也可能会影响事务的一致性。在数据库系统中,并发行为体现在可能存在多个事务同时操作同一份数据的情况。还是拿前面转账的例子来说,假设有两个事务:事务1从账户A向账户B转账100元,事务2从账户A向账户C转账50元。如果两个事务先后顺序执行,自然没有问题。但如果两个事务同时执行了,那么可能会出现下面的执行序列(假设账号A的初始余额为x元):

  1. <事务1>:读取账户A的余额,读到了x元;
  2. <事务2>:读取账户A的余额,也读到了x元;
  3. <事务1>:向账户A中写入(x-100)元;
  4. <事务2>:向账户A中写入(x-50)元;
  5. ……

上面的执行过程,账户A中最后被写入的值是(x-50)元,显然是不对的(事务的一致性会被破坏)。如果两个转账的事务能正确执行完,那么账户A的余额应该是(x-150)元才对。

这个并发的问题怎么处理呢?这就需要ACID中的I(隔离性)来保障了。什么是隔离性呢?它对于并发执行的多个事务进行合理的排序,保障了不同事务的执行互不干扰。换言之,隔离性这种特性,能够让并发执行的多个事务就好像是按照「先后顺序」执行的一样。

经过上面的分析,现在关于ACID中的一致性,我们可以得到一些结论了:

  • ACID中的一致性,是个很偏应用层的概念。这跟ACID中的原子性、隔离性和持久性有很大的不同。原子性、隔离性和持久性,都是数据库本身所提供的技术特性;而一致性,则是由特定的业务场景规定的。怪不得《Designing Data-Intensive Applications》[1]一书的作者在书中写道:“The letter C doesn’t really belong in ACID”。
  • 要真正做到ACID中的一致性,它是要依赖数据库的原子性和隔离性的(应对错误和并发)。但是,就算数据库提供了所有你所需要的技术特性,也不一定能保证ACID的一致性。这还取决于你在应用层对于事务本身的实现逻辑是否正确无误。
  • 最后,ACID中的一致性,甚至跟分布式都没什么直接关系。它跟分布式的唯一关联在于,在分布式环境下,它所依赖的数据库原子性和隔离性更难实现。

总之,ACID中的一致性,是一个非常特殊的概念。除了数据库事务处理,它很难扩展到其它场景,也跟分布式理论中的其它「一致性」概念没有什么关系。

分布式事务与共识算法的关系

先说共识问题 (consensus problem)。这是分布式系统中的一个十分基础而核心的问题,它表示如何在分布式系统中的多个节点之间就某事达成共识。

网上通常提到的「分布式一致性协议」,或者「分布式一致性算法」,一般来说就是解决这里的共识问题的算法。用词的不同,是由于中英文翻译造成的。这些算法或协议,经常包含Paxos之类,但也可能包括两阶段提交协议(2PC)或三阶段提交协议(3PC)。

人们既然经常将Paxos、2PC、3PC这些算法放在一起讨论,那么它们之间势必存在着某种相似性的。但这种相似性是怎么来的呢?我们仔细分析一下。Paxos,是解决共识问题的通用算法。它允许每个节点提出自己的提议(称为proposal),而Paxos算法能够不借助于任何中心化节点,保证各个节点之间对于提议最终达成一致。这里的proposal,是一个抽象的概念,它可以包含任何你想达成共识的数值。2PC和3PC,则是为了解决分布式事务提交问题的。

这样从表面看起来,Paxos和2PC、3PC,这两类算法似乎没有多少相似性。2PC和3PC是跟分布式事务强相关的,而Paxos跟分布式事务没有什么特别的关系。为了分析更深层次的本质,我们探究一下2PC和3PC产生的背景。

回到事务的概念。事务本来和分布式没什么直接关系的,就算在一个单节点的数据库上,要实现出事务的ACID特性,也不是那么容易的。只是,如同在前一章节的结尾我们提到的,在分布式环境下,事务的ACID特性更难实现。在前一章中我们主要关注ACID中的一致性,现在我们关注一下ACID中的原子性 (Atomicity)。

ACID中的原子性,要求事务的执行要么全部成功,要么全部失败,而不允许出现“部分成功”的情况。在分布式事务中,这要求参与事务的所有节点,要么全部执行Commit操作,要么全部执行Abort操作。换句话说,参与事务的所有节点,需要在“执行Commit还是Abort”这一点上达成一致(其实就是共识)。这个问题在学术界被称为原子提交问题(Atomic Commitment Problem)[2],而能够解决原子提交问题的算法,则被称为原子提交协议(Atomic Commitment Protocal,简称ACP[3]。2PC和3PC,属于原子提交协议两种不同的具体实现。

分析到这里,我们似乎发现了原子提交问题共识问题的关联性:

  • 共识问题,解决的是如何在分布式系统中的多个节点之间就某个提议达成共识。
  • 原子提交问题,解决的是参与分布式事务的所有节点在“执行Commit还是Abort”这一点上达成共识。
  • 所以,原子提交问题是共识问题的一个特例。

这个酷似「三段论」式的论述,看起来“合情合理”。实际上,学术界在很长一段时间内都认为,分布式事务的原子提交问题是拜占庭将军问题(Byzantine Generals Problem)的一个退化形式[4]。什么是拜占庭将军问题呢?简单来说,它也是分布式系统的一种共识问题,而且是容错性要求最高的一种共识问题。我们在这里不展开讨论拜占庭将军问题了,如果你对细节感兴趣,欢迎阅读我之前的另一篇文章“漫谈分布式系统、拜占庭将军问题与区块链”。总之,学术界以前的这种观点,跟我们刚刚分析得到的结论(原子提交问题是共识问题的一个特例)差不多。

但是,分布式系统的诡异之处就要体现在这里,一些细节的不同,可能导致非常大的差异。如果你仔细看前文的描述,会发现这样一个细节:当我们描述共识问题的时候,我们说的是在多个节点之间达成共识;而当我们描述原子提交问题的时候,我们说的是在所有节点之间达成共识。这个细微的差别,让这两类问题,几乎变成了完全不同的问题(谁也替代不了谁)。

从两类问题各自的应用场景来看,这个差异是合理的,也是容易理解的。以解决共识问题的Paxos协议为例,它只要求网络中的大部分节点达成共识就可以了,这样Paxos才能提供一定的容错性,只要网络中发生故障的节点不超过一半仍然能够正常工作(不会被阻塞)。然而,解决原子提交问题的2PC或3PC则不同。即使只有一个节点发生故障了,其它节点也不能擅自决策进行Commit操作。因为这样的话,这个事务就只是「部分地执行成功了」,违反了ACID原子性的要求。所以,原子提交协议必须保证在参与分布式事务的所有节点(包括故障的节点)上对于“执行Commit还是Abort”达成共识。

故障的节点可能什么都做不了,如何参与达成共识呢?这里的意思是,等故障节点恢复之后,它的决策(Commit或是Abort)必须与其它所有节点保持一致。那么,这是不是意味着,只要有节点发生故障,原子提交协议就一定会阻塞呢?这里有点让人奇怪,答案是「不一定」。根源就在于Abort和Commit并不是对等的决策。假设有一个节点宕机了,其它节点大可以选择Abort决策(注意不能选择Commit),从而让整个事务Abort掉(没有被阻塞住,等待宕机的节点恢复)。等宕机的那个节点恢复了,它会发现相应的事务已经执行Abort了,那么它也按照Abort处理就好了。在这个过程中,参与分布式事务的所有节点(包括宕机的这个节点)对于“执行Commit还是Abort”也是达成了共识的(这个共识是Abort)。正是这些细微却至关重要的细节,让2PC和3PC这种看似简单的协议实现起来没有那么容易。

论文[5]进一步澄清了这一问题,原子提交问题被抽象成一个新的一致性问题,称为uniform consensus问题,它是与通常的共识问题(consensus problem)不同的问题,而且是更难的问题。uniform consensus,要求所有节点(包括故障节点)都要达成共识;而consensus问题只关注没有发生故障的节点达成共识。

至此,我们总结一下本章节的结论:

  • 共识问题(consensus problem),解决的是如何在分布式系统中的多个节点之间就某个提议达成共识。它只关注没有发生故障的节点达成共识就可以了。
  • 在分布式事务中,ACID中的原子性,引出了原子提交问题,它解决的是参与分布式事务的所有节点在“执行Commit还是Abort”这一点上达成共识。原子提交问题属于uniform consensus问题,要求所有节点(包括故障节点)都要达成共识,是比consensus问题更难的一类问题。
  • Paxos和解决拜占庭将军问题的算法,解决的是consensus问题;2PC/3PC,解决的是一个特定的uniform consensus问题。

CAP与线性一致性

CAP的三个字母分别代表了分布式系统的三个特性:一致性(Consistency)、可用性(Availability)和分区容错性(Partition-tolerance)。而CAP定理指出:任何一个分布式系统只能同时满足三个特性中的两个。但是,这一描述曾经引发了非常多的误解。

为了进一步展开讨论,我们先关注CAP中的C,也就是一致性。它是什么意思呢?在证明CAP定理的原始论文中[6],C指的是linearizable consistency,也就是「线性一致性」。更精简的英文表达则是linearizability

这听起来可能稍微有点奇怪,但事实就是这样。线性一致性linearizability)是CAP中的C的原始定义。而很多人在谈到CAP时,则会把这个C看成是强一致性strong consistency)。这其实也没错,因为线性一致性的另一个名字,就是强一致性[1]。只不过,相比「线性一致性」来说,「强一致性」并不是一个好名字。因为,从这个名字你看不出来它真实的含义(到底「强」在哪?)。在下面的讨论中,我们统一使用线性一致性(linearizability)这个词汇。

那线性一致性是什么意思呢?它精确的形式化定义[7]非常抽象,且难以理解。大体上是说,在一个并发执行的环境中,不同的操作之间可能是有严格的先后关系的(一个操作执行结束之后另一个操作才开始执行),也可能是并发执行的(一个操作还没执行结束,另一个操作就开始执行了);如果能够把所有操作排列成一个「合法」的全局线性顺序,那么这些操作就是满足线性一致性的。当然,在这个重新排列的过程中,原来就存在的严格的先后关系,必须得以保持。

但是,怎么才算合法呢?我们具体到一个存储系统中通过例子来说明。假如我们先往某个数据对象中写入了一个值(假设是1),然后在写入操作结束之后,我们再把这个数据对象读出来(在写入和读取操作之间没有其它的写入操作了)。如果我们发现读取到的值是1,那么就是合法的;而如果读出来的值不是1,那么就是非法的。再假设,我们又执行了一次读取操作,发现读出来的值仍然是1,那么就是合法的;否则就是非法的。也就是说,如果一个读操作已经读到了某个值,那么下一个对于同一个数据对象的读操作就必须读取到同样的值(除非在两次读操作之间还存在别的写入操作)。

这些例子都比较容易理解,因为站在观察者的角度它们是符合逻辑的。因此,对于一个分布式存储系统来说,线性一致性的含义可以用一个具体的描述来取代:对于任何一个数据对象来说,系统表现得就像它只有一个副本一样[1]。“表现得像只有一个副本”,也就相当于满足了前面的「合法」条件。显然,如果系统对于每个数据对象真的只存一个副本,那么肯定是满足线性一致性的。但是单一副本不具有容错性,所以分布式存储系统一般都会对数据进行复制(replication),也就是保存多个副本。这时,在一个分布式多副本的存储系统中,要提供线性一致性的保证,就需要付出额外的成本了。

网上对于CAP的一致性的通俗解释,通常有两种:

  1. 一致性是指:在分布式系统完成某写操作后的任何读操作,都应该获取到该写操作写入的那个最新的值。显然,如果系统“表现得像只有一个副本”一样,这个描述是成立的。不过这只是描述了线性一致性的一个特例而已,有以偏概全的嫌疑。
  2. 一致性是指:保持所有节点在同一个时刻具有相同的、逻辑一致的数据。显然这种解释并不是从观察者的角度来描述的,而是试图从系统内部的行为(内部实现)来描述的。「所有节点」,可能指的是「所有副本」;至于“在同一个时刻具有相同的、逻辑一致的数据”这个说法,则似乎离线性一致性的本来含义偏离太远了。从逻辑上说,“表现得像只有一个副本”,并不一定需要系统“在同一个时刻具有相同的、逻辑一致的数据”。线性一致性可能有很多种实现方式,而这种解释规定了一种具体的系统实现,同样有以偏概全的嫌疑。

我们前面提到,线性一致性,也被称为强一致性。之所以这么说,大概是因为线性一致性要求多个副本上的数据必须保持如此之「强」的一致性,以至于“让系统表现得就像只有一个副本”。

另外,网上的资料提到强一致性的时候,还有可能会关联到分布式事务上面,比如2PC/3PC这些原子提交协议。但把它们关联到一起的说法,其深层次含义到底是什么,只能靠猜测。分布式事务处理的并不是同一个数据对象的多个副本的问题,而指的是将针对多个数据对象的各种操作组合起来,提供ACID的特性。将分布式事务看成是强一致性的保证,猜测可能实际上指的就是ACID的原子性。总之,「强一致性」这个词很容易产生误解,所以建议谨慎使用。

在历史上,CAP定理具有巨大的知名度,但它实际的影响力却没有想象的那么大。随着分布式理论的发展,我们逐渐认识到,CAP并不是一个「大一统」的理论,远不能涵盖分布式系统设计中方方面面的问题。相反,CAP引发了很多误解和理解上的混乱(细节不讨论了)。因此,可以预见到,未来CAP定理的影响将会进一步被削弱。

小结

本文我们辨析了分布式系统中的诸多被称为「一致性」的概念。但这个话题还没有完,我将在下一篇文章中跟大家继续讨论顺序一致性、线性一致性、最终一致性等概念。

(正文完)

参考文献:
  • [1] Martin Kleppmann,《Designing Data-Intensive Applications》, 2017.
  • [2] Vassos Hadzilacos, “On The Relationship Between The Atomic Commitment And Consensus Problems”, 1990.
  • [3] Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman, 《Concurrency Control And Recovery in Database Systems》, 1987.
  • [4] Jim Gray, “A Comparison Of The Byzantine Agreement Problem And The Transaction Commit Problem”, 1988.
  • [5] Bernadette Charron-Bost, André Schiper, “Uniform Consensus Is Harder Than Consensus”, 2001.
  • [6] Seth Gilbert, Nancy Lynch, “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web”, 2002.
  • [7] MAURICE P. HERLIHY, JEANNETTE M. WING, “Linearizability: A Correctness Condition for Concurrent Objects”, 1990.

其它精选文章


原文链接:http://zhangtielei.com/posts/blog-distributed-consistency.html
欢迎关注博主的微信公众号 ↓↓↓

              ██████    ██████  ████              ██
  ██████████  ██    ██  ██  ██████          ████  ██  ██████████
  ██      ██  ████████████████████████████████    ██  ██      ██
  ██      ██  ██  ██  ████  ████    ████  ██  ██  ██  ██      ██
  ██      ██  ██      ██  ████    ████  ██      ████  ██      ██
  ██████████  ██    ████        ██████  ██  ██  ████  ██████████
              ██  ██  ██  ██  ██  ██  ██  ██  ██  ██
██████████████████████████    ██  ██          ████████████████████
██  ██    ██        ██  ██████  ██  ████    ██████  ██      ██  ██
██      ██████      ████  ████      ████  ████    ██      ██████
    ████████  ██    ████████    ██  ██████  ████  ████  ██████  ██
    ██████  ██  ██████  ██    ██    ██    ██      ██████████  ████
  ██████  ██      ████  ████████  ██      ██  ████  ██    ████  ██
██          ████████    ████      ██    ████████  ██    ██      ██
██████████    ██  ██    ██        ██  ████    ██  ████    ██  ██
██  ██  ██  ████        ████████                      ████    ████
  ██  ██  ██  ████        ██  ████████████  ████      ████      ██
    ████  ██████    ████  ██          ██  ████████████  ██  ██  ██
██                  ██  ██  ██  ██        ██        ██  ██    ██
██  ██      ██  ██  ██████  ██████    ████        ██    ████    ██
████  ██████    ██  ██  ██████      ████  ██      ██      ██    ██
  ██    ██  ████████      ██  ████  ████  ██  ████    ██    ██████
  ██    ████  ██████  ████    ██  ██  ██  ██████  ██████    ██████
████    ██  ██  ██      ██  ████  ██  ██      ████        ██  ██
    ██            ████  ██████    ██    ████  ██            ████
████████████████        ██  ██    ████  ██        ██████      ████
              ██  ██  ██  ██████    ██  ██    ██  ██  ██  ████
  ██████████  ████  ██            ████  ██    ██  ██████  ██  ██
  ██      ██  ██      ██  ██        ██        ██          ██    ██
  ██      ██  ██      ██████      ██      ██████  ████████████  ██
  ██      ██  ████      ████            ██  ██  ██      ████    ██
  ██████████  ██        ████████████████  ██  ████████    ██    ██
              ██████  ██  ████  ████      ██  ██    ██████      ██