CAP理论十二年回看亚洲必赢app在哪下载

By admin in 亚洲必赢app在哪下载 on 2019年1月26日

正文头阵于 
Computer侧记,由InfoQ和IEEE显示给你。

CAP理论断言任何按照网络的多寡共享系统,最八只能够满意数码一致性、可用性、分区容忍性三要素中的五个因素。但是通过显式处理分区情况,系统设计师可以做到优化数据一致性和可用性,进而获取三者之间的平衡。

自打引入CAP理论的十几年里,设计师和探讨者已经以它为辩解基础探索了各式各个新颖的分布式系统,甚至到了滥用的档次。NoSQL运动也将CAP理论作为对抗传统关系型数据库的按照。

CAP理论主张任何按照网络的数量共享系统,都最多只好拥有以下三条中的两条:

  • 数量一致性(C),等同于所有节点访问同一份最新的多寡副本;
  • 对数据更新具有高可用性(A);
  • 能容忍网络分区(P)。

CAP理论的表述很好地劳动了它的目的,即开展设计师的思绪,在多样化的取舍方案下统筹出多样化的系统。在过去的十几年里确实涌现了浩如烟海的新系统,也随着在多少一致性和可用性的周旋关系上发出了一对一多的争议。“三选二”的公式平昔存在着误导性,它会过度简单化各性质之间的相互关系。现在大家有需要辨析其中的细节。实际上只有“在分区存在的前提下显现周到的多寡一致性和可用性”那种很少见的图景是CAP理论分化意现身的。

即便如此设计师依然必要在分区的前提下对数码一致性和可用性做采用,但具体怎么处理分区和还原一致性,那些中有多重的变迁方案和灵活度。当代CAP实践应将目的定为针对具体的选择,在合理限定内最大化数据一致性和可用性的“合力”。那样的思绪延伸为如何设计分区时期的操作和分区之后的复原,从而诱发设计师加深对CAP的认识,突破过去由于CAP理论的宣布而发生的思考局限。

Why “2 of 3” is missleading 为何“三选二”公式有误导性

清楚CAP理论的最简便方法是想象五个节点分处分区两侧。允许至少一个节点更新情况会造成数据不同,即丧失了C性质。若是为了有限接济数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非四个节点可以相互通信,才能既保障C又有限支撑A,那又会造成丧失P性质。一般的话跨区域的系统,设计师无法屏弃P性质,那么就只好在多少一致性和可用性上做一个不方便接纳。不确切地说,NoSQL运动的主题其实是成立种种可用性优先、数据一致性其次的方案;而传统数据库听从ACID特性(原子性、一致性、隔离性、持久性),做的是倒转的政工。下文“ACID、BASE、CAP”小节详细表明了它们的异样。

实质上,CAP理论本身就是在相近的座谈中诞生的。早在1990年份中叶,我和同事构建了一层层的按照集群的跨区域系统(实质上是初期的云计算),包罗搜索引擎、缓存代理以及内容分发系统1。从受益目的以及合同规定来讲,系统可用性是任重(英文名:rèn zhòng)而道远目的,由此大家正常会利用缓存或者以后校核更新日志来优化系统的可用性。尽管那个方针升高了系统的可用性,但那是以献身系统数据一致性为代价的。

关于“数据一致性 VS
可用性”的率先回合争持,表现为ACID与BASE之争2。当时BASE还有点被众人接受,紧如果豪门重视ACID的助益而不甘于扬弃。提出CAP理论,目标是阐明有必不可少开拓更普遍的宏图空间,因而才有了“三选二”公式。CAP理论最早在1998年冬日提议,1999年专业刊出3,并在2000年登上Symposium
on Principles of Distributed
Computing大会的要旨发言4,最后确立了该理论的没错。

“三选二”的理念在多少个方面起了误导作用,详见下文“CAP之惑”小节的诠释。首先,由于分区很少爆发,那么在系统不存在分区的气象下没什么理由就义C或A。其次,C与A之间的抉择能够在相同系统内以相当细小的粒度反复暴发,而每五遍的决定可能因为具体的操作,乃至因为牵涉到特定的数目或用户而有所不相同。最终,那三种特性都得以在档次上衡量,并不是非黑即白的有或无。可用性鲜明是在0%到100%之间延续变化的,一致性分很多级别,连分区也得以细分为分化含义,如系统内的不一致部分对于是还是不是留存分区可以有差别等的体味。

要追究那几个一线的差距,就要突破传统的分区处理方式,而那是一项根本性的挑衅。因为分区很少出现,CAP在多数时候允许完美的C和A。但当分区存在或可感知其影响的状态下,就要预备一种政策去探知分区并显式处理其震慑。那样的方针应分为多个步骤:探知分区暴发,进入显式的分区方式以限制某些操作,启动复苏进程以平复数据一致性并补丰盛区时期发生的谬误。

ACID、BASE、CAP

ACID和BASE代表了三种截然相反的宏图经济学,分处一致性-可用性分布图谱的两极。ACID器重一致性,是数据库的传统设计思路。我和同事在1990年间前期提议BASE,目的是诱惑当时正逐步成型的局地针对高可用性的规划思路,并且把差别性质之间的选项和消长关系摆上台面。现代大面积跨区域分布的连串,包含云在内,同时接纳了这二种思路。

那多少个术语都好记有余而准确不足,出现较晚的BASE硬凑的感觉更令人侧目,它是“Basically
Available, Soft state, 伊夫ntually
consistent(基本可用、软状态、最后一致性)”的首字母缩写。其中的软状态和终极一致性那三种技术擅于对付存在分区的场所,并由此提升了可用性。

CAP与ACID的关系更扑朔迷离一些,也就此引起越来越多误解。其中一个原因是ACID的C和A字母所代表的概念不一致于CAP的C和A。还有一个缘故是选拔可用性只有些地影响ACID约束。ACID四项特征分别为:

原子性(A)。所有的种类都受惠于原子性操作。当大家着想可用性的时候,没有理由去改变分区两侧操作的原子性。而且满意ACID定义的、高抽象层次的原子操作,实际上会简化分区苏醒。

一致性(C)。ACID的C指的是业务不可能破坏其余数据库规则,如键的唯一性。与之相比较,CAP的C仅指单一副本那几个意思上的一致性,由此只是ACID一致性约束的一个凶暴的子集。ACID一致性不容许在分区进度中保持,因而分区苏醒时索要重建ACID一致性。推而广之,分区时期可能不容许保持某些不变性约束,所以有必不可少仔细考虑怎么样操作应该禁止,分区后又怎么苏醒那个不变性约束。

隔离性(I)。隔离是CAP理论的中坚:若是系统要求ACID隔离性,那么它在分区时期最多可以在分区一侧维持操作。事务的可串行性(serializability)要求全局的通信,因此在分区的场地下无法树立。只要在分区苏醒时展开补给,在分区前后保持一个较弱的不易定义是可行的。

持久性(D)。捐躯持久性没有意义,理由和原子性一样,尽管开发者有理由(持久性开销太高)接纳BASE风格的软状态来防止已毕持久性。那里有一个细节,分区苏醒可能因为回退持久性操作,而无心中损坏某项不变性约束。但借使苏醒时给定分区两侧的持久性操作历史记录,破坏不变性约束的操作仍能被检测出来并更正的。经常来讲,让分区两侧的事情都满意ACID特性会使得后续的分区恢复变得更便于,并且为分区恢复生机时工作的互补工作奠定了大旨的尺度。

CAP和延期的维系

CAP理论的经典解释,是忽视网络延迟的,但在实际上中延迟和分区紧密有关。CAP从理论变为具体的景象发生在操作的中止,系统需求在那段时间内做出关于分区的一个最首要决定:

  • 废除操作由此下跌系统的可用性,还是

  • 后续操作,以冒险损失系统一致性为代价

器重数十次品尝通讯的章程来已毕一致性,比如Paxos算法或者两等级工作提交,仅仅是推迟了仲裁的年月。系统终究要做一个控制;无限期地品尝下去,本身就是拔取一致性捐躯可用性的显现。

故而以实际效果而言,分区相当于对通讯的期限必要。系统一旦不能在限期内完结数据一致性,就代表爆发了分区的事态,必须就当下操作在C和A之间做出选拔。那就从延迟的角度抓住了陈设的着力问题:分区两侧是还是不是在无通讯的情形下持续其操作?

从那个实用的洞察角度出发可以导出若干重中之重的测算。第一,分区并不是全部节点的相同看法,因为有点节点检测到了分区,有些可能没有。第二,检测到分区的节点即进入分区情势——那是优化C和A的宗旨环节。

最后,这些观望角度还代表设计师可以依照期望中的响应时间,有意识地设置时限;时限设得越短,系统进入分区方式越频仍,其中多少时候并不一定真的发生了分区的景况,可能只是网络变慢而已。

偶然在跨区域的连串,废弃强一致性来幸免保持数据一致所带动的高延迟是不行有意义的。Yahoo的PNUTS系统因为以异步的法门保证远程副本而带来多少一致性的问题5。但便宜是主副本就放在地面,减小操作的等候时间。那么些策略在事实上中很实用,因为一般来讲,用户数据差不离会依据用户的(常常)地理地点做分区。最美好的现象是每一位用户都在她的多少主副本附近。

Facebook使用了反倒的方针6:主副本被固定在一个地点,由此远程用户一般访问到的是离他较近,但可能早已过时的数量副本。不过当用户更新其页面的时候是一贯对主副本进行革新,而且该用户的有所读操作也被急促转向从主副本读取,尽管那样延迟会相比高。20秒后,该用户的流量被另行切换回离他较近的副本,此时副本应该已经一同好了刚刚的更新。

CAP之惑

CAP理论常常在不一致地方被人误解,对于可用性和一致性的功力范围的误会尤为严重,可能造成不希望寓目的结果。如若用户根本获取不到劳动,那么实际上谈不上C和A之间做取舍,除非把一些劳务放在客户端上运行,即所谓的无连接操作或称离线情势7。离线形式正变得越发首要。HTML5的有的特征,越发是客户端持久化存储特性,将会推进离线操作的前进。匡助离线格局的系统平日会在C和A中甄选A,那么就只可以在长日子处于分区状态后开展回复。

“一致性的效益范围”其实反映了这么一种观念,即在必然的分界内情状是平等的,但不止了边界就无从谈起。比如在一个主分区内足以有限辅助完备的一致性和可用性,而在分区外服务是不可用的。Paxos算法和原子性多播(atomic
multicast)系统一般符合那样的场景8。像谷歌(Google)的一半做法是将主分区归属在单一个多少主旨内部,然后提交Paxos算法去化解跨区域的问题,一方面有限协助全局协商一致(global
consensus)如Chubby9,一方面促成高可用的持久性存储如梅格astore10

分区期间,独立且能自我有限协助一致性的节点子集合可以继续执行操作,只是不可以确保全局范围的不变性约束不受破坏。数据分片(sharding)就是如此的事例,设计师预先将数据划分到不相同的分区节点,分区时期单个数据分片多半可以再三再四操作。相反,借使被分区的是内在提到密切的意况,或者有几许全局性的不变性约束非维持不可,那么最好的场所是只有分区一侧可以进行操作,最坏情形是操作完全不能够开展。

“三选二”的时候取CA而舍P是否合理?已经有探讨者提出了里面的重大——怎么着才算“舍P”含义并不显明11,12。设计师可以选用不要分区吗?哪怕原来选了CA,当分区出现的时候,你也只可以回头重新在C和A之间再选四次。我们最好从概率的角度去了然:选拔CA意味着我们只要,分区出现的可能要比其余的系统性错误(如自然魔难、并发故障)低很多。

这种理念在实质上中很有含义,因为一些故障组合可能引致同时丢掉C和A,所以说CAP四个属性都是一个度的题材。实践中,一大半公司认为(位于单一地点的)数据焦点内部是从未分区的,因此在单纯数据基本之内可以选用CA;CAP理论出现从前,系统都默许那样的规划思路,包涵传统数据库在内。可是就算可能性不高,单一数据基本完全有可能出现分区的事态,一旦出现就会动摇以CA为主旋律的安顿性基础。最终,考虑到跨区域时出现的高延迟,在数码一致性上和解来换取更好性能的做法相对比较宽泛。

CAP还有一个上面许多个人认识不清,那就是扬弃一致性其实有藏匿负担,即需求明确询问系统中存在的不变性约束。满意一致性的种类有一种保持其不变性约束的本来倾向,固然设计师不领会系统中颇具的不变性约束,卓殊部分理所当然的不变性约束会活动地维持下去。相反,当设计师选取可用性的时候,因为急需在分区截至后复原被损坏的不变性约束,显明必须将各个不变性约束一一列举出来,由此可见这件工作很有挑衅又很不难犯错。扬弃一致性为啥难,其基本仍然“并发立异问题”,跟三三十二线程编程比顺序编程难的原委是一致的。

管制分区

何以缓和分区对一致性和可用性的震慑是对设计师的挑衅。其重即使以丰硕显明、公开的办法去管理分区,不仅要求积极发现分区的发出,还亟需为分区时期有所可能受伤害的不变性约束预备专门的复原进度和陈设。管理分区有多个步骤:

(点击看大图)

亚洲必赢app在哪下载 1

  • 亚洲必赢app在哪下载,检测到分区开首
  • 明明进入分区情势,限制某些操作,并且
  • 当通讯复苏后启动分区恢复生机进度

最终一步的目标是过来一致性,以及补充在系统分区时期先后暴发的谬误。

图1凸现分区的衍变过程。普通的操作都是各类的原子操作,由此分区总是在两笔操作之间开首。一旦系统在操作停顿检测到分区暴发,检测方一侧即进入分区情势。即使的确发生了分区的情况,那么一般分区两侧都会进入到分区格局,不过另一方面落成分区也是唯恐的。单方面分区必要在对方按须求通讯的时候,本方要么能科学响应,要么不要求通讯;总而言之操作不得损坏一致性。但不论是什么样,由于检测方可能有分裂等的操作,它必须进入分区格局。采纳了quorum决定机制的种类即为单方面分区的例子。其中一方拥有“法定通过节点数”,由此得以推行操作,而另一方不得以推行操作。协助离线操作的系统明显地蕴藏“分区情势”的概念,一些支撑原子多播(atomic
multicast)的系统也包括那些定义,如Java平台的JGroups。

当系统进入到分区情势,它有二种有效的策略。其一是限制部分操作,因而会收缩可用性。其二是外加记录一些便宜后边分区复苏的操作新闻。系统可经过不停尝试復苏通讯来察觉分区什么时候甘休。

何以操作可以推行?

操纵限制哪些操作,主要在于系统必要保持哪几项不变性约束。在给定了不变性约束原则之后,设计师需求控制在分区情势下,是还是不是百折不挠不激动某项不变性约束,抑或以事后卷土重来为前提去冒险触犯它。例如,对于“表中键的惟一性”那项不变性约束,设计师一般都拔取在分区时期放宽需要,容许重复的键。重复的键很不难在平复阶段检查出来,假设重复键可以统一,那么设计师简单復苏那项不变性约束。

对于分区期间必须维持的不变性约束,设计师应当禁止或转移可能触犯该不变性约束的操作。(一般而言,大家无法知道操作是不是真正会破坏不变性约束,因为不可能知晓分区另一侧的场所。)信用卡扣费等有着外部化特征的风浪常以那种方法行事。适合那种气象的国策,是记录下操作意图,然后在分区复苏后再实践操作。那类事务往往从属于有些更大的工作流,在工作流明确涵盖类似“订单处理中”状态的意况下,将操作推迟到分区停止并无强烈的坏处。设计师以用户不利察觉的主意捐躯了可用性。用户只晓得自己下了指令,系统稍后会履行。

说得更包蕴一点,分区情势给用户界面提出了一种根本性的挑衅,即什么传达“任务正在开展尚未形成”的音讯。探讨者已经从离线操作的角度对此题材展开了一些深入的探赜索隐,离线操作能够当作时间很长的一回分区。例如Bayou的日历程序用颜色来不一样突显可能(暂时)分裂的条规13。工作流应用和带离线方式的云服务中也普遍类似的提醒,前者的例证如交易中的电子邮件文告,后者的事例如谷歌Docs。

在分区情势的座谈中,大家将关怀点放在有显然意义的原子操作而非单纯的读写,其中一个原因是操作的悬空级别越高,对不变性约束的熏陶经常就越简单分析清楚。大体来说,设计师要创立一张保有操作与拥有不变性约束的叉乘表格,观看并确定里面每一处操作可能与不变性约束相龃龉的地点。对于那一个冲突景况,设计师必须控制是还是不是禁止、推迟或改动相应的操作。在实践中,那类决定还受到分区前景况和/或环境参数的震慑。例如有些系统为特定的数码设立了主节点,那么一般允许主节点实施操作,不容许其余节点操作。

对分区两侧跟踪操作历史的最佳艺术是行使版本向量,版本向量可以反映操作间的因果报应信赖关系。向量的因素是(节点,
逻辑时间)数值对,分别对应一个翻新了目标的节点和它最终更新的日子。对于同样对象的八个给定的版本A和B,当有着结点的本子向量一致有A的时光超出或等于B的年华,且至少有一个节点的版本向量有A的流年较大,则A新于B。

设若不能对版本向量排序,那么更新操作是出现的,而且有可能出现不均等的处境。只要了然分区两侧版本向量的沿革。系统简单断定哪些操作的执行种种是确定的,哪些操作是出现的。近来的探讨成果注脚14,当设计师选取可用性优先,一般最八只可以将一致性收紧到这般的档次。

分区恢复生机

到了某个时刻,通讯复苏,分区截至。由于每一侧在分区时期都是可用的,其场地仍持续上前进展,可是分区会推迟某些操作并侵犯一些不变性约束。分区截至的随时,系统精通分区两侧的当前事态和历史记录,因为它在分区方式下记录了详细的日志。当前状态不如历史记录有价值,因为经过历史记录,系统可以断定什么操作违反了不变性约束,暴发了何种外在的后果(如发送了响应给用户)。在分区復苏进度中,设计师必须解决四个问题:

  • 分区两侧的意况最后必须保持一致,
  • 与此同时必须补偿分区时期暴发的谬误。

平凡情状,校对当前状态最不难易行的缓解情势是回退到分区起初时的事态,以特定措施推动分区两侧的一多重操作,并在进程中直接保持一致的状态。Bayou就是这些完成机制,它会回滚数据库到正确的随时并按无歧义的、确定性的次第重新履行所有的操作,最后使拥有的节点达到相同的气象15。同样地,并发版本决定体系CVS在统一分支的时候,也是从从一个共享的情事一致点早先,逐步将履新合并上去。。

一大半系统都存在不可能自动合并的争持。比如,CVS时不时有些顶牛必要手动出席,带离线方式的wiki系统连接把冲突留在发生的文档里给用户处理16

相反,有些系统用了限定操作的格局来确保争执总能合并。一个事例就是谷歌(Google)Docs将其文本编辑操作17简单为运用样式、添加文(加文)本和删除文本。因而,纵然总的来说争执问题不可解,但现实中设计师能够选拔在分区时期限制使用部分操作,以便系统在还原的时候可以活动合并状态。假使要履行这种方针,推迟有高风险的操作是周旋简便易行的落到实处方式。

再有一种方式是让操作可以交流顺序,这种措施最相近于形成一种缓解机关状态合并问题的通用框架。此类系统将线性合并各日志不分畛域排操作的逐条,然后实施。操作知足调换率,意味着操作有可能重新排列成一种全局一致的一级顺序。不幸的是,只允许知足互换率的操作那么些想法兑现起来没那么简单。比如加法操作可以换成顺序,不过进入了越界检查的加法就越发了。

Marc
Shapiro及其INRIA同事近期的行事18,19对于可沟通顺序的操作在状态合并方面的使用起了很大的促进功用。该集体指出一种从理论上证实可以有限协理分区后统一的数据类型,称为可沟通多副本数据类型(commutative
replicated data types,CRDTs)。他们介绍了什么样利用此类数据结构来

  • 管教分区时期举行的富有操作都是可交流顺序的,或者
  • 用“格(lattice)”的数学概念来代表数据,并保管相对于“格”来说,分区时期的装有操作都是单调递增的。

用后一种艺术统一状态会集中分区两边的最大集合。那种措施是对亚马逊购物车合并算法20的方式化计算和创新,合并后的数据是两边购物车的并集,而并运算是一种干燥的会晤运算。那种方针的流弊是删掉的购物车货物有可能再度出现。

实质上CRDTs完全能够兑现同时帮衬增、删操作的分区耐受集合。此形式的精神是维护多个汇集:一个放增加的品种,一个放删除的花色,两会晤之差即为真正的集结成员。增集合、删集合分别合并起来都不困难,由此增删集合之差合并起来也不困难。在某个时刻点上,系统可以从三个会聚中清理掉删除的数量项。假诺根据一般的布署,像那种清理操作仅在系统没分区的时候才有效,属于设计师必须在分区时期禁止或延迟的特定操作,不过CRDTs的清理操作并不会对可用性暴发外在的影响。由此通过CRDTs来完毕动静,设计师既有限帮助了可用性,又有限支撑了分区后系统自动合并状态。

增补错误

比估算分区后情形更难解决的题材是何等弥补分区时期造成的谬误。跟踪和范围分区情势下的操作,这三种格局得以使设计师确知哪些不变性约束可能被违反,然后分别为它们制定恢复生机策略。一般系统在分区復苏时期检查违反意况,修复工作也不可以不在那段时光内形成。

卷土重来不变性约束的方式有为数不少,粗陋一点的方法如“最终写入者胜”(因而会忽略部分更新),聪喜宝(Hipp)点的办法如合并操作和人造跟进事态(human
escalation)。人为跟进事态的例证如飞机航班“超售”的意况:可以把游客登机看作是对前面售票情状的分区復苏,必须復苏“座位数不少于游客数”那项不变性约束。那么当乘客太多的时候,有些游客将错过座位,客服最好能想法补偿他们。

航班的事例揭发了一个外在错误(externalized
mistake):如若航空集团没说过游客一定有坐席,那个题材会好解决得多。由此我们来看推迟有高风险的操作的又一个理由——到了分区復苏的时候,大家才知晓真实的情景。考订此类错误的着力概念是“补偿(compensation)”;设计师必须设置补偿操作,除了回复不变性约束,还要改进外在错误。

技能上CRDTs只同意有的可验证的不变性约束,所以没有补偿的不可或缺,尽管那种范围下落了CRDTs方法本身的能力。用了CRDTs来拍卖状态合并的设计方案可以允许临时违反全局性的不变量约束,分区截止后才联合状态,以及实践要求的填补。

卷土重来外在错误经常须要精通有些关于外在输出的野史新闻。以“喝醉酒打电话”为例,一位老兄不记得自己明儿早上喝高了的时候打过多少个电话,即使她第二天白天上升了例行意况,但打电话日志上的笔录都还在,其中有些通话很可能是一无可取的。拨出的对讲机就是这位兄长的景观(喝高了)的外在影响。而鉴于那位兄长不记得打过什么电话,也就很难补偿其中可能造成的麻烦。

又以机械为例,电脑可能在分区时期把一份订单执行了几回。倘使系统能分别两份一样的订单是蓄意的要么重新了,它就能收回掉一份重复的订单。倘诺本次错误暴发了外在影响,补偿政策能够是自动生成一封电子邮件,向消费者解释系统竟然将订单执行了五回,现在不当已经被修正,附上一张打折券下次可以用。假诺尚未健全的历史记录,就只能靠顾客亲自去发现错误了。

早已有人专业切磋过将补偿性事务作为处理长寿命事务(long-lived
transactions)的一种手段21,22。长日子运作的事务见面临另一种形象的分区决策:是长日子持有锁来确保一致性比较好啊?仍旧尽早释放锁向其余工作暴光未提交的多少,进步并发能力比较好吧?比如在单笔事务中更新具有的员工记录就是一个非凡例证。根据一般的法子串行化这笔业务,将招致所有的笔录都被锁定,阻止并发。而补偿性事务接纳另一种格局,它将大事务拆成八个分级交付的子事务。假设要中断大事务,系统必须发起一笔新的、起考订功用的政工,逐一废除所有曾经付诸的子事务,那笔新业务就是所谓的补偿性事务。

由此看来,补偿性事务的目的是防止中止其余用了未正确提交数据的工作(即不允许级联打消)。那种方案不借助于串行化或切断的手腕来保持科学,其不易取决于事务体系对情况和输出所暴发的净影响。那么,经过补充,数据库的景色究竟是或不是一对一于这几个子事务根本没实施过相同吗?考虑分外必须连外在表现也囊括在内;举个例子,把重复扣取的交易款退还给顾客,很难说成等于一始发就没多收顾客的钱,但从结果上看勉强算扯平了。分区恢复生机也继续同样的笔触。即使服务不肯定总能直接取消其错误,但至少承认错误并做出新的填补作为。怎么样在分区恢复生机中使用那种思路效果最好,那几个题材并未稳定的答案。“自动柜员机上的补偿问题”小节以一个很小的应用领域为例点出了有些构思方向。

当系统中留存分区,系统设计师不该盲目地捐躯一致性或可用性。运用以上商量的不二法门,设计师通过周到地保管分区时期的不变性约束,两上边的习性都足以获得最佳的显现。随着版本向量和CRDTs等相比新的技术逐步被纳入一些简化其用法的框架,这上边的优化手段会收获相比普遍的行使。但引入CAP实践毕竟不像引入ACID事务那么粗略,实施的时候须要对过去的政策举行完善的考虑,最佳的实施方案极大地依赖于现实服务的不变性约束和操作细节。

机关柜员机上的补给问题

以自动柜员机(ATM)的规划来说,强一致性看似符合逻辑的抉择,但现实景况是可用性远比一致性主要。理由很简短:高可用性意味着高收入。不管怎么样,研讨哪些补丰硕区时期被毁掉的不变性约束,ATM的布置性很符合当作例子。

ATM的基本操作是存款、取款、查看余额。关键的不变性约束是余额应超出或等于零。因为只有取款操作会触犯那项不变性约束,也就唯有取款操作将受到越发对待,其余二种操作随时都得以执行。

ATM系统设计师可以选用在分区时期禁止取款操作,因为在这段时光里不能够知道真实的余额,当然如此会损伤可用性。现代ATM的做法正相反,在stand-in格局下(即分区格局),ATM限制净取款额不得高于k,比如k为$200。低于限额的时候,取款完全健康;当跨越限额的时候,系统拒绝取款操作。那样,ATM成功将可用性限制在一个创建的品位上,既允许取款操作,又限定了高风险。

分区为止的时候,必须有部分办法来復苏一致性和补丰硕区时期系统所导致的不当。状态的东山再起比较不难,因为操作都是切合互换率的,补偿就要分两种状态去考虑。最终的余额低于零违反了不变性约束。由于ATM已经把钱吐出去了,错误成了外部实在。银行的填补措施是收纳透支费并希望顾客偿还。因为风险已经备受限制,问题并不严重。还有一种情景是分区时期的某说话余额已经低于零(但ATM不领悟),此时一笔存款重新将余额变为正的。银行可以追溯发生透支费,也得以因为消费者曾经缴纳而忽视该违反情形。

由此可见,因为通讯延迟的存在,银行系统不借助一致性来担保科学,而越来越多地依靠审计和增补。“空头支票诈骗”也是相仿的例子,顾客赶在多家支行对账以前分别取出钱来然后逃之夭夭。透支的百无一用过后才会被察觉,对不当的补偿或者显示为法律行动的款式。

致谢

感谢迈克 Dahlin、汉克(Hank) Korth、Marc Shapiro、Justin(Justin) Sheehy、Amin
Vahdat、Ben Zhao以及IEEE Computer
Society的志愿者们,感谢他们对本文的便利反馈。

作者简介

Eric Brewer是University of California,
伯克利的总计机科学教师,在谷歌(Google)担任基础设备方面的VP。他的钻研兴趣包蕴云总计、可伸缩的服务器、传感器网络,还有符合发展中地区利用的技能。他还扶持建立了美联邦政坛的门户网站USA.gov。Brewer从MIT得到电子工程和处理器科学的学士学位。他是National
Academy of Engineering的院士。联系方式:brewer@cs.berkeley.edu

亚洲必赢app在哪下载 2Computer侧记是IEEE
Computer
Society的旗舰刊物,发表经过同行评议的高品位文章,读者和小编都是从事种种计算科技(science and technology)相关领域的专业人士,小说包括的限量包涵软硬件的新切磋和新应用。那本杂志比经贸杂志更讲求技术内涵,比切磋期刊更器重实用思维。Computer为您传递工作中用得上的音讯。

参考文献

  1. E. Brewer, “Lessons from Giant-Scale Services,” IEEE Internet
    Computing
    , July/Aug. 2001, pp. 46-55.
  2. A. Fox et al., “Cluster-Based Scalable Network Services,” Proc. 16th
    ACM Symp. Operating Systems Principles (SOSP 97), ACM, 1997, pp.
    78-91.
  3. A. Fox and E.A. Brewer, “Harvest, Yield and Scalable Tolerant
    Systems,” Proc. 7th Workshop Hot Topics in Operating Systems (HotOS
    99), IEEE CS, 1999, pp. 174-178.
  4. E. Brewer, “Towards Robust Distributed Systems,” Proc. 19th Ann. ACM
    Symp.Principles of Distributed Computing
    (PODC 00), ACM, 2000, pp.
    7-10; on-line
    resource
    .
  5. B. Cooper et al., “PNUTS: Yahoo!’s Hosted Data Serving Platform,”
    Proc. VLDB Endowment (VLDB 08), ACM, 2008, pp. 1277-1288.
  6. J. Sobel, “Scaling Out,” Facebook Engineering Notes, 20 Aug. 2008;
    on-line
    resource
    .
  7. J. Kistler and M. Satyanarayanan, “Disconnected Operation in the Coda
    File System” ACM Trans. Computer Systems, Feb. 1992, pp. 3-25.
  8. K. Birman, Q. Huang, and D. Freedman, “Overcoming the ‘D’ in CAP:
    Using Isis2 to Build Locally Responsive Cloud Services,” Computer,
    Feb. 2011, pp. 50-58.
  9. M. Burrows, “The Chubby Lock Service for Loosely-Coupled Distributed
    Systems,” Proc. Symp. Operating Systems Design and Implementation
    (OSDI 06), Usenix, 2006, pp. 335-350.
  10. J. Baker et al., “Megastore: Providing Scalable, Highly Available
    Storage for Interactive Services,” Proc. 5th Biennial Conf. Innovative
    Data Systems Research
    (CIDR 11), ACM, 2011, pp. 223-234.
  11. D. Abadi, “Problems with CAP, and Yahoo’s Little Known NoSQL
    System,” DBMS Musings, blog, 23 Apr. 2010; on-line
    resource.
  12. C. Hale, “You Can’t Sacrifice Partition Tolerance,” 7 Oct. 2010;
    on-line
    resource
    .
  13. W. K. Edwards et al., “Designing and Implementing Asynchronous
    Collaborative Applications with Bayou,” Proc. 10th Ann. ACM Symp. User
    Interface Software and Technology
    (UIST 97), ACM, 1999, pp. 119-128.
  14. P. Mahajan, L. Alvisi, and M. Dahlin, Consistency, Availability,
    and Convergence
    , tech. report UTCS TR-11-22, Univ. of Texas at Austin,
  15. D.B. Terry et al., “Managing Update Conflicts in Bayou, a Weakly
    Connected Replicated Storage System,” Proc. 15th ACM Symp. Operating
    Systems Principles
    (SOSP 95), ACM, 1995, pp. 172-182.
  16. B. Du and E.A. Brewer, “DTWiki: A Disconnection and Intermittency
    Tolerant Wiki,” Proc. 17th Int’l Conf. World Wide Web (WWW 08), ACM,
    2008, pp. 945-952.
  17. “What’s Different about the New Google Docs: Conflict Resolution”
    blog.
  18. M. Shapiro et al., “Conflict-Free Replicated Data Types,” Proc.
    13th Int’l Conf. Stabilization, Safety, and Security of Distributed
    Systems
    (SSS 11), ACM, 2011, pp. 386-400.
  19. M. Shapiro et al., “Convergent and Commutative Replicated Data
    Types,” Bulletin of the EATCS, no. 104, June 2011, pp. 67-88.
  20. G. DeCandia et al., “Dynamo: Amazon’s Highly Available Key-Value
    Store,” Proc. 21st ACM SIGOPS Symp. Operating Systems Principles (SOSP
    07), ACM, 2007, pp. 205-220.
  21. H. Garcia-Molina and K. Salem, “SAGAS,” Proc. ACM SIGMOD Int’l
    Conf. Management of Data
    (SIGMOD 87), ACM, 1987, pp. 249-259.
  22. H. Korth, E. Levy, and A. Silberschatz, “A Formal Approach to
    Recovery by Compensating Transactions,” Proc. VLDB Endowment (VLDB
    90), ACM, 1990, pp. 95-106

原稿链接:CAP Twelve Years Later: How the “Rules” Have
Changed

普通话原文链接:CAP理论十二年回看:”规则”变了

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 亚洲必赢app官方下载 版权所有