深化解析:分布式体系的事务处理经典问题及模型ITeye - AG环亚娱乐

深化解析:分布式体系的事务处理经典问题及模型ITeye

2019-01-11 14:38:07 | 作者: 乐双 | 标签: 问题,处理,数据 | 浏览: 2454

原文链接:
http://www.csdn.net/article/2014-01-20/2818197-distributed-system

摘要:分布式体系需求在数据完好、共同性和功能间做平衡。本文体系介绍了处理分布式数据共同性的技能模型,如:Master-Slave,Master-Master,2PC/3PC,经典的将军问题,Paxos,以及Dynamo的NRW和VectorClock的模型。
编者按:数据效劳的高可用是一切企业都想具有的,可是要想让数据有高可用性,就需求冗余数据写多份。写多份的问题会带来共同性的问题,而共同性的问题又会带来功能问题,这就会堕入一个无解的死循环!这儿所谓数据共同性,便是当多个用户企图一起拜访一个数据库时,假如它们的业务一起运用相同的数据,或许会发作以下四种状况:丢掉更新、未承认的相关性、不共同的剖析和幻像读。阿里巴巴北京研制中心、商家业务部任资深专家陈皓的博客《分布式体系的业务处理》一文对此做了具体的描绘,推荐给咱们。以下是作者原文:

在生产线上用一台效劳器来供给数据效劳的时分,经常会遇到如下的两个问题:

一台效劳器的功能不足以供给满足的才干效劳于一切网络恳求。
忧虑效劳器宕机,形成效劳不行用或是数据丢掉。
面临这些问题,咱们不得不对效劳器进行扩展,参加更多的机器来分管功能问题,以及处理单点故障问题。一般,咱们会经过两种手法来扩展咱们的数据效劳:

数据分区:便是把数据分块放在不同的效劳器上(如:uid % 16,共同性哈希等)。
数据镜像:让一切的效劳器数据同步,供给无差其他数据效劳。
运用第一种计划,无法处理数据丢掉问题,单台效劳器出问题时,必定会有部分数据丢掉。所以,数据效劳的高可用性只能经过第二种办法来完结——数据的冗余存储(一般工业界以为比较安全的备份数应该是3份,如:Hadoop和Dynamo)。 可是,参加的机器越多数据就会变得越杂乱,特别是跨效劳器的业务处理,也便是跨效劳器的数据共同性。这个是一个很难的问题!让咱们用最经典的Use Case:“A帐号向B帐号汇钱”来说明一下,了解RDBMS业务的都知道从帐号A到帐号B需求6个操作:

从A帐号中把余额读出来;
对A帐号做减法操作;
把成果写回A帐号中;
从B帐号中把余额读出来;
对B帐号做加法操作;
把成果写回B帐号中。
为了数据的共同性,这6件事,要么都成功做完,要么都不成功,并且这个操作的进程中,对A、B帐号的其它拜访必需锁死,所谓锁死便是要扫除其它的读写操作,不然会有脏数据问题,这便是业务。可是,在参加了多个机器后,这个作业会变得杂乱起来:

在数据分区的计划中:假如A帐号和B帐号的数据不在同一台效劳器上怎样办?咱们需求一个跨机器的业务处理。也便是说,假如A的扣钱成功了,但B的加钱不成功,咱们还要把A的操作给回滚回去。在不同的机器上完结,就会比较杂乱。
在数据镜像的计划中:A帐号和B帐号间的汇款是能够在一台机器上完结的,可是别忘了咱们有多台机器存在A帐号和B帐号的副本。假如对A帐号的汇钱有两个并发操作(要汇给B和C),这两个操作发作在不同的两台效劳器上怎样办?也便是说,在数据镜像中,在不同的效劳器上对同一个数据的写操作怎样保证其共同性,保证数据不抵触?
一起,咱们还要考虑功能要素,假如不考虑功能的话,业务完结并不困难,体系慢一点就行了。除了考虑功能外,咱们还要考虑可用性,也便是说,一台机器没了,数据不丢掉,效劳可由其他机器持续供给。 所以,咱们需求要点考虑下面的这么几个状况:

容灾:数据不丢、结点的Failover
数据的共同性:业务处理
功能:吞吐量 、 呼应时刻
前面说过,要处理数据不丢,只能经过数据冗余的办法,就算是数据分区,每个区也需求进行数据冗余处理。这便是数据副本:当呈现某个节点的数据丢掉时能够从副本读到,数据副本是分布式体系处理数据丢掉反常的仅有手法。所以,在这篇文章中,咱们只评论在数据冗余状况下考虑数据的共同性和功能的问题。简略说来:

要想让数据有高可用性,就得写多份数据。
写多份的问题会导致数据共同性的问题。
数据共同性的问题又会引发功能问题
这便是软件开发,按下了葫芦起了瓢。

共同性模型

说起数据共同性来说,简略说有三种类型(当然,假如细分的话,还有许多共同性模型,如:次序共同性,FIFO共同性,会话共同性,单读共同性,单写共同性,但为了本文的简略易读,我只说下面三种):

Weak 弱共同性:当你写入一个新值后,读操作在数据副本上或许读出来,也或许读不出来。比方:某些cache体系,网络游戏其它玩家的数据和你没什么联系,VOIP这样的体系,或是百度搜索引擎。
Eventually 终究共同性:当你写入一个新值后,有或许读不出来,但在某个时刻窗口之后保证终究能读出来。比方:DNS,电子邮件、Amazon S3,Google搜索引擎这样的体系。
Strong 强共同性:新的数据一旦写入,在恣意副本恣意时刻都能读到新值。比方:文件体系,RDBMS,Azure Table都是强共同性的。
从这三种共同型的模型上来说,咱们能够看到,Weak和Eventually一般来说是异步冗余的,而Strong一般来说是同步冗余的,异步的一般意味着更好的功能,但也意味着更杂乱的状况操控;同步意味着简略,但也意味着功能下降。让咱们由浅入深,一步一步地来看有哪些技能:

Master-Slave

首先是Master-Slave结构,关于这种加构,Slave一般是Master的备份。在这样的体系中,一般是如下规划的:

读写恳求都由Master担任。
写恳求写到Master上后,由Master同步到Slave上。
从Master同步到Slave上,能够运用异步,也能够运用同步,能够运用Master来push,也能够运用Slave来pull。 一般来说是Slave来周期性的pull,所所以终究共同性。这个规划的问题是,假如Master在pull周期内垮掉了,那么会导致这个时刻片内的数据丢掉。假如你不想让数据丢掉,Slave只能成为Read-Only的办法等Master康复。

当然,假如能够忍受数据丢掉的话,能够立刻让Slave替代Master作业(关于只担任核算的结点来说,没有数据共同性和数据丢掉的问题,Master-Slave的办法就能够处理单点问题了) 当然,Master Slave也能够是强共同性的, 比方:当写Master的时分,Master担任先备份,等成功后,再写Slave,两者都成功后回来成功,整个进程是同步的,假如写Slave失利了,那么两种办法,一种是符号Slave不行用报错并持续效劳(等Slave康复后同步Master的数据,能够有多个Slave,这样少一个,还有备份,就像前面说的写三份那样),另一种是回滚自己并回来写失利。(注:一般不先写Slave,由于假如写Master自己失利后,还要回滚Slave,此刻假如回滚Slave失利,就得手艺修订数据了)能够看到,假如Master-Slave需求做成强共同性有多杂乱。

Master-Master

Master-Master,又名Multi-master,是指一个体系存在两个或多个Master,每个Master都供给read-write效劳。这个模型是Master-Slave加强版,数据间同步一般是经过Master间异步完结,所所以终究共同性。 Master-Master的优点是一台Master挂了,其他Master能够正常做读写效劳,这个和Master-Slave相同,当数据没有被仿制到其他Master上时数据会丢掉。许多数据库都支撑Master-Master的Replication的机制。

其他,假如多个Master对同一个数据进行修正的时分,这个模型的恶梦就呈现了——需求对数据间的抵触进行兼并,这十分困难。看看Dynamo的Vector Clock的规划(记载数据的版别号和修正者)就知道这个事并不那么简略,并且Dynamo对数据抵触这个事是交给用户自己搞的。就像SVN源码抵触相同,关于同一行代码的抵触,只能交给开发者自己来处理。(在本文后后面会评论一下Dynamo的Vector Clock)

Two/Three Phase Commit

这个协议的缩写又名2PC,中文叫两阶段提交。在分布式体系中,每个节点尽管能够知晓自己的操作时成功或许失利,却无法知道其他节点的操作的成功或失利。当一个业务跨过多个节点时,为了坚持业务的ACID特性,需求引进一个作为和谐者的组件来共同掌控一切节点(称作参与者)的操作成果并终究指示这些节点是否要把操作成果进行真实的提交(比方将更新后的数据写入磁盘等等)。 两阶段提交的算法如下:

第一阶段:

和谐者会问一切的参与者结点,是否能够履行提交操作。
各个参与者开端业务履行的预备作业:如:为资源上锁,预留资源,写undo/redo log……
参与者呼应和谐者,假如业务的预备作业成功,则回应“能够提交”,不然回应“回绝提交”。
第二阶段:

假如一切的参与者都回应“能够提交”,那么,和谐者向一切的参与者发送“正式提交”的指令。参与者完结正式提交,并开释一切资源,然后回应“完结”,和谐者搜集各结点的“完结”回应后完毕这个Global Transaction。
假如有一个参与者回应“回绝提交”,那么,和谐者向一切的参与者发送“回滚操作”,并开释一切资源,然后回应“回滚完结”,和谐者搜集各结点的“回滚”回应后,撤销这个Global Transaction。


能够看到,2PC说白了便是第一阶段做Vote,第二阶段做抉择的一个算法,也能够看到2PC这个事是强共同性的算法。在前面评论过Master-Slave的强共同性战略,和2PC有点类似,只不过2PC更为保存一些——先测验再提交。 2PC用的是比较多的,在一些体系规划中,会串联一系列的调用,比方:A - B - C - D,每一步都会分配一些资源或改写一些数据。比方B2C网上购物的下单操作在后台会有一系列的流程需求做。假如一步一步地做,就会呈现这样的问题,假如某一步做不下去了,那么前面每一次所分配的资源需求做反向操作把他们都回收掉,所以,操作起来比较杂乱。现在许多处理流程(Workflow)都会学习2PC这个算法,运用 try - confirm的流程来保证整个流程的能够成功完结。 举个浅显的比方,西方教堂成婚的时分,都有这样的桥段:

牧师别离问新郎和新娘:你是否乐意……不管生老病死……
当新郎和新娘都答复乐意后(承认终身的资源),牧师就会说:我宣告你们……(业务提交)
这是多么经典的一个两阶段提交的业务处理。 其他能够看到其间的一些问题, A)其间一个是同步堵塞操作,这个作业必然会十分大地影响功能。 B)另一个首要的问题是在TimeOut上,比方,

假如第一阶段中,参与者没有收到问询恳求,或是参与者的回应没有抵达和谐者。那么,需求和谐者做超时处理,一旦超时,能够当作失利,也能够重试。
假如第二阶段中,正式提交宣布后,假如有的参与者没有收到,或是参与者提交/回滚后确实认信息没有回来,一旦参与者的回应超时,要么重试,要么把那个参与者符号为问题结点除掉整个集群,这样能够保证效劳结点都是数据共同性的。
糟糕的状况是,第二阶段中,假如参与者收不到和谐者的commit/fallback指令,参与者将处于“状况不知道”阶段,参与者彻底不知道要怎样办,比方:假如一切的参与者完结第一阶段的回复后(或许悉数yes,或许悉数no,或许部分yes部分no),假如和谐者在这个时分挂掉了。那么一切的结点彻底不知道怎样办(问另的参与者都不行)。为了共同性,要么死等和谐者,要么重发第一阶段的yes/no指令。
两段提交最大的问题便是第3项,假如第一阶段完结后,参与者在第二阶没有收到抉择计划,那么数据结点会进入“手足无措”的状况,这个状况会block住整个业务。也便是说,和谐者Coordinator关于业务的完结十分重要,Coordinator的可用性是个要害。 因些,咱们引进三段提交,三段提交在Wikipedia上的描绘如下,他把二段提交的第一个段break成了两段:问询,然后再锁资源。最终真实提交。三段提交的示意图如下:



三段提交的核心理念是:在问询的时分并不承认资源,除非一切人都赞同了,才开端锁资源。

理论上来说,假如第一阶段一切的结点回来成功,那么有理由信任成功提交的概率很大。这样一来,能够下降参与者Cohorts的状况不知道的概率。也便是说,一旦参与者收到了PreCommit,意味他知道咱们其实都赞同修正了。这一点很重要。下面来看一下3PC的状况搬迁图:(注间图中的虚线,那些F,T是Failuer或Timeout,其间的:状况意义是 q – Query,a – Abort,w – Wait,p – PreCommit,c – Commit)



其实,三段提交是一个很杂乱的作业,完结起来适当难,并且也有一些问题。

看到这儿,我信任你有许多许多的问题,你必定在考虑2PC/3PC中各式各样的失利场景,你会发现Timeout是个十分难处理的作业,由于网络上的Timeout在许多时分让你无所事从,你也不知道对方是做了仍是没有做。所以你好好的一个状况机就由于Timeout成了个铺排。

一个网络效劳会有三种状况:1)Success,2)Failure,3)Timeout,第三个必定是恶梦,特别在你需求保护状况的时分。

Two Generals Problem(两将军问题)

Two Generals Problem 两将军问题是这么一个思想性试验问题: 有两支戎行,它们别离有一位将军领导,现在预备进犯一座修筑了防护工事的城市。这两支戎行都驻守在那座城市的邻近,分占一座山头。一道山沟把两座山分隔开来,并且两位将军仅有的通讯办法便是派各自的信使交游于山沟两头。不幸的是,这个山沟现已被那座城市的保卫者占据,并且存在一种或许,那便是任何被派出的信使经过山沟是会被捕。 请留意,尽管两位将军现已就进犯那座城市达到共同,但在他们各自占据山头阵地之前,并没有就进攻时刻达到共同。两位将军有必要让自己的戎行一起进攻城市才干取得成功。因而,他们有必要相互交流,以承认一个时刻来进犯,并赞同就在那时进犯。假如只需一个将军进行进犯,那么这将是一个灾难性的失利。 这个思想试验就包含考虑将军怎么去做这件作业。下面是关于这件作业的考虑:

第一位将军先发送一段音讯“让咱们在上午9点开端进攻”。可是,一旦信使被差遣,他是否经过了山沟,第一位将军就不得而知了。任何一点的不承认性都会使得第一位将军进犯犹疑,由于假如第二位将军不能在同一时刻发起进犯,那座城市的驻军就会击溃他的戎行的进攻,导致他的军对被炸毁。
知道了这一点,第二位将军就需求发送一个承认音讯:“我收到您的信息,并会在9点的进犯。”可是,假如带着承认音讯的信使被抓怎样办?所以第二位将军会犹疑自己确实认音讯是否能抵达。
所以,好像咱们还要让第一位将军再发送一条承认音讯——“我收到了你确实认”。可是,假如这位信使被抓怎样办呢?
这样一来,是不是咱们还要第二位将军发送一个“承认收到你确实认”的信息。
所以你会发现,这作业很快就开展成为不管发送多少个承认音讯,都没有办法来保证两位将军有满足的自傲自己的信使没有被敌军捕获。



这个问题是无解的。两个将军问题和它的无解证明首先由E.A.Akkoyunlu,K.Ekanadham和R.V.Huber于1975年在《一些约束与折衷的网络通讯规划》一文中宣布,就在这篇文章的第73页中一段描绘两个黑帮之间的通讯中被说明。 1978年,在Jim Gray的《数据库操作体系留意事项》一书中(从第465页开端)被命名为两个将军悖论。作为两个将军问题的界说和无解性的证明的来历,这一参阅被广泛提及。

这个试验意在说明:企图经过建立在一个不牢靠的连接上的交流来和谐一项举动的危险和规划上的巨大应战。

从工程上来说,一个处理两个将军问题的实践办法是运用一个能够承受通讯信道不牢靠性的计划,并不企图去消除这个不牢靠性,但要将不牢靠性削减到一个能够承受的程度。比方,第一位将军排出了100位信使并估计他们都被捕的或许性很小。在这种状况下,不管第二位将军是否会进犯或许遭到任何音讯,第一位将军都会进行进犯。其他,第一位将军能够发送一个音讯流,而第二位将军能够对其间的每一条音讯发送一个承认音讯,这样假如每条音讯都被接纳到,两位将军会感觉更好。可是从证明中来看,他们俩都不能必定这个进犯是能够和谐的。他们没有算法可用(比方,收到4条以上的音讯就进犯)能够保证避免仅有一方进犯。再者,第一位将军还能够为每条音讯编号,说这是1号,2号……直到n号。这种办法能让第二位将军知道通讯信道到底有多牢靠,并且回来适宜的数量的音讯来保证最终一条音讯被接纳到。假如信道是牢靠的话,只需一条音讯就行了,其他的就帮不上什么忙了。最终一条和第一条音讯丢掉的概率是持平的。

两将军问题能够扩展成更反常的拜占庭将军问题 (Byzantine Generals Problem),其故事布景是这样的:拜占庭坐落现在土耳其的伊斯坦布尔,是东罗马帝国的首都。由于其时拜占庭罗马帝国疆土广阔,为了防护意图,因而每个戎行都分隔很远,将军与将军之间只能靠信差传音讯。 在战役的时分,拜占庭戎行内一切将军必需达到共同的共同,抉择是否有赢的时机才去攻击敌人的阵营。可是,戎行或许有叛徒和敌军特务,这些叛徒将军们会打乱或左右抉择计划的进程。这时分,在已知有成员谋反的状况下,其他忠实的将军在不受叛徒的影响下怎么达到共同的协议,这便是拜占庭将军问题。
PAXOS算法

Wikipedia上的各种Paxos算法的描绘十分具体,咱们能够去围观一下。

Paxos 算法处理的问题是在一个或许发作上述反常的分布式体系中怎么就某个值达到共同,保证不管发作以上任何反常,都不会损坏抉择的共同性。一个典型的场景是,在一个分布式数据库体系中,假如各节点的初始状况共同,每个节点都履行相同的操作序列,那么他们最终能得到一个共同的状况。为保证每个节点履行相同的指令序列,需求在每一条指令上履行一个「共同性算法」以保证每个节点看到的指令共同。一个通用的共同性算法能够应用在许多场景中,是分布式核算中的重要问题。从20世纪80年代起关于共同性算法的研讨就没有中止过。

Notes:Paxos算法是莱斯利·兰伯特(Leslie Lamport,便是 LaTeX 中的”La”,此人现在在微软研讨院)于1990年提出的一种根据音讯传递的共同性算法。由于算法难以了解起先并没有引起人们的注重,使Lamport在八年后1998年从头宣布到ACM Transactions on Computer Systems上。即便如此paxos算法仍是没有得到注重,2001年Lamport 觉得同行无法承受他的幽默感,所以用容易承受的办法从头表述了一遍。可见Lamport对Paxos算法情有独钟。近几年Paxos算法的遍及运用也证明它在分布式共同性算法中的重要位置。2006年Google的三篇论文初现“云”的端倪,其间的Chubby Lock效劳运用Paxos作为Chubby Cell中的共同性算法,Paxos的人气从此一路狂飙。(Lamport 自己在他的blog 中描写了他用9年时刻宣布这个算法的前前后后)

注:Amazon的AWS中,一切的云效劳都根据一个ALF(Async Lock Framework)的结构完结的,这个ALF用的便是Paxos算法。我在Amazon的时分,看内部的共享视频时,规划者在内部的Principle Talk里说他参阅了ZooKeeper的办法,但他用了另一种比ZooKeeper更易读的办法完结了这个算法。

简略说来,Paxos的意图是让整个集群的结点对某个值的改变达到共同。Paxos算法根本上来说是个民主选举的算法——大多数的抉择会成个整个集群的共同抉择。任何一个点都能够提出要修正某个数据的提案,是否经过这个提案取决于这个集群中是否有超越对折的结点赞同(所以Paxos算法需求集群中的结点是奇数)。

这个算法有两个阶段(假定这个有三个结点:A,B,C):

第一阶段:Prepare阶段

A把恳求修正的恳求Prepare Request发给一切的结点A,B,C。留意,Paxos算法会有一个Sequence Number(你能够以为是一个提案号,这个数不断递加,并且是仅有的,也便是说A和B不或许有相同的提案号),这个抉择号会和修正恳求一起宣布,任何结点在“Prepare阶段”时都会回绝其实小于当时提案号的恳求。所以,结点A在向一切结点恳求修正恳求的时分,需求带一个提案号,越新的提案,这个提案号就越是是最大的。

假如接纳结点收到的提案号n大于其它结点发过来的提案号,这个结点会回应Yes(本结点上最新的被同意提案号),并保证不接纳其它 n的提案。这样一来,结点上在Prepare阶段里总是会对最新的提案做许诺。

优化:在上述 prepare 进程中,假如任何一个结点发现存在一个更高编号的提案,则需求告诉 提案人,提示其间断这次提案。

第二阶段:Accept阶段

假如提案者A收到了超越对折的结点回来的Yes,然后他就会向一切的成果发布Accept Request(相同,需求带上提案号n),假如没有超越对折的话,那就回来失利。

当结点们收到了Accept Request后,假如关于接纳的成果来说,n是最大的了,那么,它就会修正这个值,假如发现自己有一个更大的提案号,那么,结点就会回绝修正。

咱们能够看以,这好像便是一个“两段提交”的优化。其实,2PC/3PC都是分布式共同性算法的劣质版别,Google Chubby的作者Mike Burrows说过这个世界上只需一种共同性算法,那便是Paxos,其它的算法都是劣质品。

咱们还能够看到:关于同一个值的在不同结点的修正提案就算是在接纳方被乱序收到也是没有问题的。

关于一些实例,你能够看一下Wikipedia中文中的“Paxos样例”一节,我在这儿就不再多说了。关于Paxos算法中的一些反常示例,咱们能够自己推导一下。你会发现根本上来说只需保证有对折以上的结点存活,就没有什么问题。

多说一下,自从Lamport在1998年宣布Paxos算法后,对Paxos的各种改善作业就从未中止,其间动作最大的莫过于2005年宣布的Fast Paxos。不管何种改善,其要点依然是在音讯推迟与功能、吞吐量之间作出各种权衡。为了容易地从概念上区别二者,称前者Classic Paxos,改善后的后者为Fast Paxos。

总结

下图来自:Google App Engine的co-founder Ryan Barrett在2009年的google i/o上的讲演:



前面,咱们说过,要想让数据有高可用性,就需求冗余数据写多份。写多份的问题会带来共同性的问题,而共同性的问题又会带来功能问题。从上图咱们能够看到,咱们根本上来说不能够让一切的项都绿起来,这便是闻名的CAP理论:共同性,可用性,分区忍受性,你能够要其间的两个。

NWR模型

最终我还想提一下Amazon Dynamo的NWR模型。这个NWR模型把CAP的挑选权交给了用户,让用户自己的挑选你的CAP中的哪两个。

所谓NWR模型。N代表N个备份,W代表要写入至少W份才以为成功,R表明至少读取R个备份。装备的时分要求W+R N。 由于W+R N, 所以 R N-W 这个是什么意思呢?便是读取的份数必定要比总备份数减去保证写成功的倍数的差值要大。

也便是说,每次读取,都至少读取到一个最新的版别。然后不会读到一份旧数据。当咱们需求高可写的环境的时分,咱们能够装备W = 1 假如N=3 那么R = 3。 这个时分只需写任何节点成功就以为成功,可是读的时分有必要从一切的节点都读出数据。假如咱们要求读的高效率,咱们能够装备 W=N R=1。这个时分任何一个节点读成功就以为成功,可是写的时分有必要写一切三个节点成功才以为成功。

NWR模型的一些设置会形成脏数据的问题,由于这很显着不是像Paxos相同是一个强共同的东西,所以,或许每次的读写操作都不在同一个结点上,所以会呈现一些结点上的数据并不是最新版别,但却进行了最新的操作。

所以,Amazon Dynamo引了数据版其他规划。也便是说,假如你读出来数据的版别是v1,当你核算完结后要回填数据后,却发现数据的版别号现已被人更新成了v2,那么效劳器就会回绝你。版别这个事就像“达观锁”相同。

可是,关于分布式和NWR模型来说,版别也会有恶梦的时分——便是版别冲的问题,比方:咱们设置了N=3 W=1,假如A结点上承受了一个值,版别由v1 - v2,但还没有来得及同步到结点B上(异步的,应该W=1,写一份就算成功),B结点上仍是v1版别,此刻,B结点接到写恳求,按道理来说,他需求回绝掉,可是他一方面并不知道其他结点现已被更新到v2,另一方面他也无法回绝,由于W=1,所以写一分就成功了。所以,呈现了严峻的版别抵触。

Amazon的Dynamo把版别抵触这个问题奇妙地逃避掉了——版别冲这个事交给用户自己来处理。

所以,Dynamo引进了Vector Clock(矢量钟?!)这个规划。这个规划让每个结点各自记载自己的版别信息,也便是说,关于同一个数据,需求记载两个事:1)谁更新的我,2)我的版别号是什么。

下面,咱们来看一个操作序列:

一个写恳求,第一次被节点A处理了。节点A会添加一个版别信息(A,1)。咱们把这个时分的数据记做D1(A,1)。 然后其他一个对相同key的恳求仍是被A处理了所以有D2(A,2)。这个时分,D2是能够掩盖D1的,不会有抵触发生。
现在咱们假定D2传达到了一切节点(B和C),B和C收到的数据不是从客户发生的,而是他人仿制给他们的,所以他们不发生新的版别信息,所以现在B和C所持有的数据仍是D2(A,2)。所以A,B,C上的数据及其版别号都是相同的。
假如咱们有一个新的写恳求到了B结点上,所以B结点生成数据D3(A,2; B,1),意思是:数据D大局版别号为3,A升了两新,B升了一次。这不便是所谓的代码版其他log么?假如D3没有传达到C的时分又一个恳求被C处理了,所以,以C结点上的数据是D4(A,2; C,1)。
假如D3没有传达到C的时分又一个恳求被C处理了,所以,以C结点上的数据是D4(A,2; C,1)。
好,最精彩的作业来了:假如这个时分来了一个读恳求,咱们要记住,咱们的W=1 那么R=N=3,所以R会从一切三个节点上读,此刻,他会读到三个版别:
A结点:D2(A,2)
B结点:D3(A,2; B,1);C结点:D4(A,2; C,1)
C结点:D4(A,2; C,1)
6.这个时分能够判别出,D2现已是旧版别(现已包含在D3/D4中),能够放弃。

7.可是D3和D4是显着的版别抵触。所以,交给调用方自己去做版别抵触处理。就像源代码版别办理相同。

很显着,上述的Dynamo的装备用的是CAP里的A和P。

版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表AG环亚娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章