分布式系统中的一致性模型

开发 前端 分布式
最近看到的一篇超棒的关于分布式系统中强一致性模型的blog,实在没有不分享的道理。最近比较闲,所以干脆把它翻译了,一是为了精读,二是为了更友好地分享。

[[413697]]

最近看到的一篇超棒的关于分布式系统中强一致性模型的blog,实在没有不分享的道理。最近比较闲,所以干脆把它翻译了,一是为了精读,二是为了更友好地分享。其中会插入一些乱七八糟的个人补充,评论区的精彩讨论也会有选择性的翻译。原文在这: https://aphyr.com/posts/313-st ... odels

网络分区是大概率会 发生 的。交换机,网络接口控制器(NIC,Network Interface Controller),主机硬件,操作系统,硬盘,虚拟机,语言运行时,更不用说程序语义本身,所有的这些将导致我们的消息可能会延迟,被丢弃,重复或被重新排序。在一个充满不确定的世界里,我们希望程序保持一种 直观的正确性 。

是的,我们想要直观的正确性。那就做正确的事吧!但什么是正确的事?我们如何描述它?在这篇文章里,我们会见到一些“强”一致性模型,并且看到他们是如何互相适应的。

正确性(Correctness)

其实有很多种描述一个算法抽象行为的方式——但为了统一,我们说一个系统是由 状态 和一些 导致状态转移的操作 组成的。在系统运行期间,它将随着操作的演进从一个状态转移到另一个状态。

uniprocessor history

举个例子,我们的状态可以是个变量, 操作 可以是对这个变量的读和写。在这个简单的Ruby程序里,我们会对一个变量进行几次读写,以输出的方式表示写。

  1. x = "a"; puts x; puts x 
  2.  
  3. x = "b"; puts x 
  4.  
  5. x = "c" 
  6.  
  7. x = "d"; puts x 

我们对程序的正确性已经有了一个直观的概念:以上这段程序应该输出 “aabd” 。为什么呢?因为它们是有序发生的。首先我们 写入值a ,然后 读到值a ,接着 读到值a , 写入值b ,如此进行。

一旦我们把变量写为某个值,比如 a ,那么读操作就应该返回 a ,直到我们再次改变变量。读到的值应该总是返回最近写入的值。我们把这种系统称为——单值变量——单一 寄存器 (并不单指硬件层次的寄存器,而是 act like a register )。

从编程的第一天开始,我们就把这种模型奉为圭臬,像习惯一样自然——但这并不是变量运作的唯一方式。一个变量可能被读到任何值: a , d ,甚至是 the moon 。这样的话,我们说系统是 不正确 的,因为这些操作没有与我们模型期望的运作方式对应上。

这引出了对系统 正确性 的定义:给定一些涉及操作与状态的 规则 ,随着操作的演进,系统将一直 遵循这些规则 。我们把这样的规则称为 一致性模型 。

我们把对寄存器的规则用简单的英语来陈述,但它们也可以是任意复杂的数学结构。“读取两次写入之前的值,对值加三,如果结果为4,读操作可能返回cat或dog”,这也可以是一种一致性模型(作者只是为了表名一致性模型的阐述原则,后同)。也可以是“每次读操作都会返回0”。我们甚至可以说“根本没有什么规则,所有操作都是允许的”。这就是 最简单 的一致性模型,任何系统都能轻易满足。

更加正式地说,一致性模型是 所有被允许的操作记录 的集合。当我们运行一个程序,经过一系列集合中允许的操作,特定的执行结果总是 一致 的。如果程序意外地执行了  集合中的操作,我们就称执行记录是 非一致 的。如果 任意 可能的执行操作都在这个被允许的操作集合内,那么系统就 满足 一致性模型。我们希望实际的系统是满足这样“直观正确”的一致性模型的,这样我们才能写出可预测的程序。

并发记录(Concurrent histories)

假设有一个用Node.js或Erlang写的并发程序。现有多个逻辑线程,我们称之为“多进程”。如果我们用2个进程运行这个并发程序,每个进程都对同一个寄存器进行访问(读和写),那么我们之前认为的寄存器系统的不变性(指顺序不变性)就会被 改写 。

multiprocessor history

两个工作进程分别称为“top”和“bottom”。Top进程尝试执行 写a ,  ,  。Bottom进程同时尝试执行  , 写b ,  。因为程序是并发的,所以两个进程之间互相交错的操作将导致 多个执行顺序 ——而在单核场景下,执行顺序总是程序里指定的那一个逻辑顺序。图例中,top写入 a ,bottom读 a ,top读 a ,bottom写 b ,top读 b ,bottom读 b 。

但是并发会让一切表现的不同。我们可以 默认 地认为每个 并发 的程序——一旦执行,操作能以任意顺序发生。一个 线程 ,或者说是一个 逻辑进程 ,在执行记录层面的做了一个 约束 :属于同一个线程的操作 一定 会按顺序发生。逻辑线程对允许操作集合中的操作强加了部分顺序保证。(一个逻辑线程即一个执行实体,即使编译器重排了指令,单个线程中的同步workflow顺序是不会颠倒的。但是不同线程之间的事件顺序无法保证。)

即使有了以上的保证,从独立进程的角度来看,我们的寄存器不变性也被破坏了。Top写入 a ,读到 a ,接着读到 b ——这 不再 是它写入的值。 我们必须使一致性模型更 宽松 来有效描述并发。现在,进程可以从其他任意进程读到最近写入的值。寄存器变成了两个进程之间的 协调地 :它们共享了状态。

光锥(Light cones)

> 读写不再是一个瞬时的过程,而是一个类似光传播->反射面->反向传播的过程。

light cone history

现实往往没有那么理想化:在几乎每个实际的系统中,进程之间都有一定的 距离 。一个没有被缓存的值(指没有被CPU的local cache缓存),通常在距离CPU 30厘米 的DIMM内存条上。光需要整整一个纳秒来传播这么长的距离,实际的内存访问会比光速慢得多。位于不同数据中心某台计算机上的值可以相距几千公里——意味着需要几百毫秒的传播时间。我们没有更快传播数据的方法,否则就违反了物理定律。(物理定律都违反了,就更别谈什么现代计算机体系了。)

这意味着我们的操作 不再是瞬时的 。某些操作也许快到可以被近乎认为是瞬时的,但是通常来说,操作是 耗时 的。我们 调用 对一个变量的写操作;写操作传播到内存,或其他计算机,或月球;内存改变状态;一个确认信息回传;这样我们才 知道 这个操作真实的发生了。

concurrent read

不同地点之间传送消息的延迟会在操作记录中造成 歧义 。消息传播的快慢会导致预期外的事件顺序发生。上图中,bottom发起一个读请求的时候,值为 a ,但在读请求的传播过程中,top将值写为 b ——写操作偶然地比读请求  到达寄存器。 Bottom最终读到了 b 而不是 a 。

这一记录破坏了我们的寄存器并发一致性模型。Bottom并没有读到它在发起读请求时的值。有人会考虑使用 完成时间 而不是 调用时间 作为操作的 真实时间 ,但反过来想想,这同样行不通:当读请求比写操作先到达时,进程会在当前值为 b 时读到 a 。

在分布式系统中,操作的耗时被放大了,我们必须使一致性模型 更宽松 :允许这些有歧义的顺序发生。

我们该如何确定宽松的程度?我们必须允许 所有 可能的顺序吗?或许我们还是应该强加一些合理性约束?

线性一致性(Linearizability)

finite concurrency bounds

通过仔细的检查,我们发现事件的顺序是有边界的。在时间维度上,消息不能被逆向发送,因此 最先到达 的消息会即刻接触到数据源。一个操作不能在它 被调用之前 生效。

同样的,通知完成的消息也不能回传,这意味着一个操作 不能 在它 完成之后 生效。

如果我们假设有一个全局的状态与每个进程通信;继续假设与这个全局状态交互的操作都是 原子的 ;那我们可以排除很多可能发生的记录。 每个操作会在它调用和完成之间的某个时间点原子地生效 。

我们把这样的一致性模型称为 线性一致性模型 。尽管操作都是并发且耗时的,但每一个操作都会在某地以严格的线性顺序发生。

linearizability complete visibility

“全局单点状态”并不一定是一个单独的节点,同样的,操作也并不一定全是原子的,状态也可以被分片成横跨多台机器,或者分多步完成——只要从进程的角度看来,外部记录的表现与 一个原子的单点状态等效 。通常一个可线性化的系统由一些更小的协调进程组成,这些进程本身就是线性的,并且这些进程又是由更细粒度的协调进程组成,直到 硬件提供可线性化的操作 。

线性化是强大的武器。一旦一个操作完成,它或它之后的某一状态将对 所有参与者 可见。因为每个操作 一定 发生在它的 完成时间 之前,且任何之后被调用的操作 一定 发生在 调用时间 之后,也就是在原操作本身之后。 一旦我们成功写入 b ,每个之后调用的读请求都可以读到 b ,如果有更多的写操作发生的话,也可以是 b 之后的某个值。

我们可以利用线性一致性的原子性约束来 安全地修改状态 。我们定义一个类似 CAS(compare-and-set) 的操作,当且仅当寄存器持有某个值的时候,我们可以往它写入新值。 CAS 操作可以作为互斥量,信号量,通道,计数器,列表,集合,映射,树等等的实现基础,使得这些共享数据结构变得可用。线性一致性保证了变更的 安全交错 。

此外,线性一致性的时间界限保证了操作完成后,所有变更都对其他参与者可见。于是线性一致性禁止了过时的读。每次读都会读到某一介于 调用时间 与 完成时间 的状态,但永远不会读到读请求调用之前的状态。线性一致性同样禁止了 非单调 的读,比如一个读请求先读到了一个新值,后读到一个旧值。

由于这些强约束条件的存在,可线性化的系统变得更容易推理,这也是很多并发编程模型构建的时候选择它作为基础的原因。Javascript中的所有变量都是(独立地)可线性化的,其他的还有Java中的volatile变量,Clojure中的atoms,Erlang中独立的process。大多数编程语言都实现了互斥量和信号量,它们也是可线性化的。强约束的假设通常会产生强约束的保证。

但如果我们无法满足这些假设会怎么办?

(线性一致性模型提供了这样的保证:1.对于观察者来说,所有的读和写都在一个单调递增的时间线上串行地向前推进。 2.所有的读总能返回最近的写操作的值。)

顺序一致性(Sequential consistency)

sequencial history

如果我们允许进程在时间维度发生偏移,从而它们的操作可能会在调用之前或是完成之后生效,但仍然保证一个约束——任意进程中的操作必须按照进程中定义的顺序(即编程的定义的逻辑顺序)发生。这样我们就得到了一个稍弱的一致性模型: 顺序一致性 。

顺序一致性允许比线性一致性产生更多的记录,但它仍然是一个很有用的模型:我们每天都在使用它。举个例子,当一个用户上传一段视频到Youtube,Youtube把视频放入一个处理队列,并立刻返回一个此视频的网页。我们并不能立刻看到视频,上传的视频会在被充分处理后的几分钟内生效。队列会以入队的顺序 同步 地(取决于队列的具体实现)删除队列中的项。

很多缓存的行为和顺序一致性系统一直。如果我在Twitter上写了一条推文,或是在Facebook发布了一篇帖子,都会耗费一定的时间渗透进一层层的缓存系统。不同的用户将在不同的时间看到我的信息,但每个用户都以 同一个顺序 看到我的操作。一旦看到,这篇帖子便不会消失。如果我写了多条评论,其他人也会按顺序的看见,而非乱序。

(顺序一致性放松了对一致性的要求:1. 不要求操作按照真实的时间序发生。2. 不同进程间的操作执行先后顺序也没有强制要求,但必须是原子的。3. 单个进程内的操作顺序必须和编码时的顺序一直。)

因果一致性(Casual consistency)

我们不必对一个进程中的 每个 操作都施加顺序约束。只有 因果相关 的操作必须按顺序发生。同样拿帖子举例子:一篇帖子下的所有评论必须以同样的顺序展示给所有人,并且只有帖子可见  ,帖子下的回复才可见(也就是说帖子和帖子下的评论有因果关系)。如果我们将这些因果关系编码成类似“我依赖于操作X”的形式,作为每个操作明确的一部分,数据库就可以将这些操作延迟直到它们的依赖都就绪后才可见。

因果一致性比同一进程下对每个操作严格排序的一致性(即顺序一致性)来的更宽松——属于同一进程但不同因果关系链的操作能以相对的顺序执行(也就是说按因果关系隔离,无因果关系的操作可以并发执行),这能防止许多不直观的行为发生。

串行一致性(Serializable consistency)

serializable history

如果我们说操作记录的发生等效于某些单一的原子序,但和调用时间与完成时间无关,那么我们就得到了名为 串行一致性 的一致性模型。这一模型比你想象的更强大同时也更脆弱。

串行一致性是 弱约束 的,因为它能允许多种类型的记录发生,且对时间或顺序不设边界。在上面的示意图中,消息看似可以被任意地发送至过去和未来,因果关系也可以交错。在一个串行数据库中,即使在0时刻, x 还没被初始化,一个类似 read x 的读事务也是允许执行的。 或者它也会被延迟到无限远的未来执行。类似 write 2 to x 的写事务可以立即执行,也可能永远都不会执行。

举个例子,在一个串行系统中,有这么一段程序:

  1. x = 1 
  2.  
  3. x = x + 1 
  4.  
  5. puts x 

这段程序可以输出 nil , 1 或 2 ,因为操作能以任意顺序发生。 这是十分弱的约束!这里可以把每一行代码看作是单个操作,所有操作都成功执行了。

另一方面,串行一致性也是 强约束 的,当它要求一个线性顺序时,它能拦截很大一部分操作记录。看以下程序:

  1. print x if x = 3 
  2.  
  3. x = 1 if x = nil 
  4.  
  5. x = 2 if x = 1 
  6.  
  7. x = 3 if x = 2 

这段程序只有一种输出可能。它并不按我们 编写 的顺序输出,但 x 会从 nil 开始变化: nil -> 1 -> 2 -> 3 ,最终输出 3 。

因为串行一致性允许对操作顺序执行任意的重排(只要操作顺序是原子序的), 它在实际的场景中并不是十分有用。大多数宣称提供了串行一致性的数据库实际上提供的是 强串行一致性 ,它有着和线性一致性一样的时间边界。让事情更复杂的是,大多数SQL数据库宣称的串行一致性等级比 实际的更弱 ,比如可重复读,游标稳定性,或是快照隔离性。

(关于线性一致性和串行一致性,看似十分相似,其实不然。串行一致性是数据库领域的概念,是针对事务而言的,描述对一组事务的执行效果等同于某种串行的执行,没有ordering的概念,而线性一致性来自并行计算领域,描述了针对某种数据结构的操作所表现出的顺序特征。 串行一致性是对多操作,多对象的保证,对总体的操作顺序无要求;线性一致性是对单操作,单对象的保证,所有操作遵循真实时间序 。详见: http://www.bailis.org/blog/lin ... lity/ )

一致性的代价(Consistency comes with costs)

之前说了“弱”一致性模型比“强”一致性模型 允许 更多的操作记录发生(这里的强与弱是相对的)。比如线性一致性保证操作在调用时间与完成时间之间发生。不管怎样, 需要协调来达成对顺序的强制约束 。不严格地说,执行越多的记录,系统中的参与者就必须越谨慎且通信频繁。

也许你听说过 CAP理论 ,CAP理论声明给定一致性( C onsistency),可用性( A vailability)和分区容错性( P artition tolerance),任何系统 至多 能保证以上三项中的 两项 而不可能满足全部三项。这是Eric Brewer的CAP猜想的非正式说法,以下是准确的定义:

  • 一致性(Consistency)意味着线性化,具体说,可以是一个可线性化的寄存器。寄存器可以等效为集合,列表,映射,关系型数据库等等,因此该理论可以被拓展到各种可线性化的系统。
  • 可用性(Availability)意味着向非故障节点发出的每个请求都将成功完成。因为网络分区可以持续 任意长的时间 ,因此节点不能简单地把响应推迟到分区结束。
  • 分区容错性(Partition tolerance)意味着分区很可能发生。当网络 可靠 的时候,提供一致性和可用性将变得十分 简单 ,但当网络 不可靠 时,同时提供一致性和可用性将变得 几乎不可能 。然而网络总不是完美可靠的,所以我们不能选择CA。所有实际可用的商用分布式系统至多能提供AP或CP的保证。

family tree

也许你会说:“等等!线性化并不是一致性模型的终极解决方案!我能围绕着CAP理论提供顺序一致性,串行一致性或是快照隔离性!”

没错,CAP理论只声称 我们不能构建一个完全可用的线性化系统 。但问题是我们又有了其他证据表明我们同样不能利用顺序化,串行化,可重复读,快照隔离,游标稳定或是其它任意一个比这些强的约束来构建完全可用的系统。在Peter Bailis的Highly Available Transactions这篇论文中,红色阴影标注的模型就不能是 完全 可用的。

如果我们 放松 对可用性的定义,只要求client节点能够一直与同一server保持通信,某种一致性就被达成了。我们能以此为基础提供因果一致性,PRAM(pipelined random access memory)一致性和“读你所写”一致性。

如果我们要求 完全可用 ,那就能提供单调读,单调写,读的提交,单调且原子的视角等等。这些一致性模型是由如Riak和Cassandra这样的分布式存储系统,低隔离性设置的ANSI SQL数据库提供的。这些一致性模型并没有保证线性顺序,而是在批处理任务或网络场景下提供 部分 顺序保证。只能保证部分顺序是因为它们准许更丰富的记录。

一种混合方法(A hybrid approach)

weak not unsafe

一些算法依赖于线性化提供安全性。例如当我们想构建分布式锁的服务时,我们就需要线性化,如果没有硬性的时间边界的话,我们就可以持有一把将来的锁或是过去的锁。而另一方面,很多算法根本 不需要 线性化。即使仅提供“弱”一致性模型,比如有 最终一致性 保证的集合,列表,树,映射等结构也能被安全地表示为 CRDTs (Commutative Replicated Data Types)

更强约束的一致性模型需要更多的协调——需要更多的消息交互,确保操作在正确的顺序发生。这不仅意味着更低的可用性,还会被 导致更高的延迟 。这也是为什么现代CPU内存模型默认不是线性化的,除非显示指定。(x86-64架构的CPU通常以Sequential consistency作为默认的memory order),现代CPU会在核之间重排内存操作,甚至更糟糕。虽然(程序的行为)更难以推理,但带来的性能提升是惊人的。在地理位置上零落的分布式系统,数据中心通常有几百毫秒的延迟,通常和CPU的场景类似,代价也相似。

因此在实践中,通常会用 混合 数据存储,在数据库之间混用不同的一致性模型来权衡冗余度,可用性,性能和安全性等目标。可能的话就为了可用性和性能选择“弱”一致性模型。必要的话就选择“强”一致性模型,因为某些算法对操作顺序有严格要求。我们可以向S3,Riak,Cassandra等数据库写入大量数据,然后线性地向Postgres,ZooKeeper或etcd写入指向数据的 指针 。一些数据库准许多种一致性模型共存,比如关系数据库中的可调节隔离等级,Cassandra和Riak中的线性化事务,减少了使用的系统数量。但底线是: 任何人宣称它的一致性模型是最优解,那么他一定是个大猪蹄子 。

接下来是精彩评论时间

Colin Scott:当你提到“属于同一进程但不同因果关系链的操作”的时候,是否对潜在的因果关系(happens before)作了更保守的假设?我在苦想一个case,当来自同一台机器上的两个存在潜在因果关系(A必须先于B发生)的操作并发时,会发生什么?

Aphyr(作者):尽管来自同一个进程的操作在某一节点上按顺序发生,但它们并不需要在 任何地方都 按序发生。顺序一致性(Sequential consistency)作了这样的约束,但因果一致性(Casual consistency)并没有。只有 显式 的因果关系在因果一致性系统中才是顺序不变的,而 隐式 的因果关系在顺序一致性系统中作了保证。(因为都来自同一进程,通过pid区分)

Aurojit Panda:实际上你对 Colin Scott 的回复和你在文章中的 一致性层级示意图 是自相矛盾的。 PRAM一致性模型约定:所有节点都能按同一顺序从一个给定节点观测到它的写操作(Lipton,Sandberg 1988)。而你描述的因果一致性是某一比PRAM一致性更弱的一致性模型,并不是经典的因果一致性模型。并且你描述中出现的隐式因果关系也是PRAM一致性模型约束中的一部分。如果因果一致性比PRAM一致性更强,PRAM一致性就应该用任何因果一致性系统来实现,利用因果一致性对单节点的写操作进行正确排序,使得其他节点的观测结果一致。

Aphyr(作者):请参考: https://projects.ics.forth.gr/ ... s.pdf ,获得为什么因果一致性比PRAM更强的详细解释。具体地说,有因果关系的操作可以在中间节点之间 传递 ,但是PRAM并没有对因果一致性的传递性作任何定义。

Prakash:关于问题“在你串行一致性的示例中,各种 if 假设是如何对顺序进行约束的?”你的回答中提到“这些操作发生的顺序有且只有一种可能。”而我的问题是,当我们考虑在并发环境下执行某种操作时,是怎么做到“串行有且只有一种可能”的?举个例子,我们有不同的线程,其中一个检查 x 值是否为3并把它打印,另一个将 x 的值设为2。你能解释一下在这种场景中是如何维护顺序的?

Aphyr(作者):串行的操作记录实际上会转化为单道线程下的操作记录,单道线程下的操作记录就是我们之前的讨论中发挥作用的 状态转移方程 。如果以 恒等函数 作为你的模型,操作记录中 任何 可能的路径都是有效的,它们并不会改变状态。为了让某些操作记录永远不可串行化(限制那些非法的可能造成状态转移的操作发生),不得不声明一些等效于单线程执行的操作无效,这就是条件语句( if )强制部分操作有序的原因。

 

责任编辑:张燕妮 来源: DockOne
相关推荐

2017-09-21 10:59:36

分布式系统线性一致性测试

2019-10-11 23:27:19

分布式一致性算法开发

2019-09-05 08:43:34

微服务分布式一致性数据共享

2017-09-22 12:08:01

数据库分布式系统互联网

2021-11-22 16:30:30

分布式一致性分布式系统

2018-03-19 09:50:50

分布式存储系统

2021-06-03 15:27:31

RaftSOFAJRaft

2022-06-07 12:08:10

Paxos算法

2017-04-06 11:59:19

分布式服务化系统

2024-01-31 09:54:51

Redis分布式

2021-06-06 12:45:41

分布式CAPBASE

2023-11-06 09:06:54

分布式一致性数据

2018-03-13 08:20:48

区块链数据安全

2020-10-28 11:15:24

EPaxos分布式性算法

2021-08-13 11:50:23

AnalyticDB 分布式数据库

2020-05-29 14:46:23

3PC协议分布式系统

2021-06-16 08:33:02

分布式事务ACID

2020-05-11 10:30:57

2PC分布式协议

2015-10-19 10:42:37

分布式一致性应用系统

2021-01-21 07:34:16

分布式系统场景
点赞
收藏

51CTO技术栈公众号