深入理解「分布式事务」

  • 时间:
  • 浏览:2
  • 来源:大发彩票快三—大发彩票app

当参与者在投Yes票后一段时间内未收到应答时,参与者用该操作向协调者询问事务的投票表决结果。该操作用于从服务器崩溃或从消息延迟中恢复。



可是一一兩个 多事务调用了不同服务器上的操作,没有它就成为了一一兩个 多分布式事务。

一一兩个 多事务的参与者可是最终能提交事务,没有须要说参与者处在事务的准备好(prepared)具体情况。为了保证不必可不都能否提交,每个参与者须要将事务中所有处在改变的对象以及自身的具体情况(prepared)保存到持久性存储中。

阶段一(投票阶段):

1)协调者向分布式事务的所有参与者发送canCommit?请求

2)当参与者收到canCommit请求后,它向协调者回复个人的投票(Yes/No)。

在投Yes票就让,它在持久性存储中保存所有对象,准备提交。可是投No票,参与者立即放弃。

阶段二(提交阶段):

1)协调者分发所有的投票(包括它个人的投票)。

a)可是不处在故障可是所有的投票也有Yes时,没有协调者将决定提交事务并向所有参与者发送doCommit

请求

b)可是,协调者决定放弃该事务,并向所有投Yes票的参与者发送doAbort请求

2)投Yes票的在等待者在等待协调者发送的doCommit可是doAbort请求。一旦参与者接收到任何这俩请求消息,

它将根据该请求放弃可是提交事务。可是请求是提交事务,没有他须要向协调者发送一一兩个 多haveCommitted

来确认事务可是提交

3、分布式事务的故障模型

在分布式事务中执行的过程中,可是出显磁盘故障,应用应用进程崩溃以及消息的丢失,超时等。

在两阶段协议的不同阶段,协调者或参与者也有遇到这俩场景:只有处理它的那每项协议,直到接收到下一一兩个 多请求或应答为止。

1、two-phase commit protocol



两阶段提交协议(two-phase commit protocol)的设计出发点是允许任何一一兩个 多参与者自行放弃它个人的那每项事务。可是事务原子性的要求,可是每项事务被放弃,没有整个分布式事务也须要被放弃。

两阶段提交是这俩达成共识的协议,在该系统中,可是应用应用进程崩溃,没有是不可是达成共识的。可是,两阶段提交却是在哪些条件下达成了共识,这是可是应用应用进程的崩溃被屏蔽,崩溃的应用应用进程被一一兩个 多新的应用应用进程取代,新应用应用进程的具体情况根据持久性存储中保存的信息和这俩应用应用进程拥有的信息来设定。

没有 亲戚亲戚朋友上述的转账就变成了如下过程:

当支付宝扣款事务提交成功,向消息队列发送确认。在得到确认的指令后,消息队列向该消息发往余额宝。

在最坏的具体情况下,两阶段提交协议在执行过程中可是出显任意多次服务器和通信故障。尽管协议只有指定协议完成的时间限制,但它能处理连续故障(服务崩溃可是消息丢失),并保证最终完成。

在一一兩个 多分布式事务就让开始 英语 的就让,事务的原子特征要求所有参与该事务的服务器须要完整提交或完整放弃该事务。为了实现这俩点,其中一一兩个 多服务器承担了协调者(coordinater)的角色,由它来保证所有的服务器获得相同的结果。

协调者(coordinater)的工作最好的办法取决于它选取的协议,“两阶段提交”是分布式事务最常用的协议。

参与者用该操作向协调者确认它提交了事务。

消息传递可是有任意长的延迟。消息可是丢失、重复可是损坏。接收方(通过校验和)不必可不都能否检测到受损消息。未发现的受损消息和伪造的消息可是会原因分析分析灾难性故障。

3.1、故障模型

利用这俩关于持久性存储、处理器和通信的故障模型不必可不都能否设计出一一兩个 多可靠系统,该系统的组件可对付任何单一故障,并提供一一兩个 多简单的故障模型。有点硬是,可靠存储(stable storage)须要在出显一一兩个 多write操作故障可是应用应用进程崩溃的具体情况下提供原子写操作。它是通过将每一一兩个 多数据块一键复制到一一兩个 多磁盘上实现的。此时一一兩个 多write操作用于一一兩个 多磁盘块,在一一兩个 多磁盘出显故障的前提下,没有 好的磁盘也须要提供正确数据。可靠处理器(stable processor)使用可靠存储,用于在崩溃就让恢复对象。可通过可靠的远程过程调用机制来屏蔽通信错误。

6、使用消息队列来处理分布式事务

5.1、消息队列

4、两阶段提交的故障处理

当参与者处在故障的就让:



当协调者处在故障的就让:



5、两阶段提交的性能

假设一切运转正常,即协调者参与者什么都没有显故障,通信也正常时,有N个参与者的两阶段提交协议须要N个canCommit消息和应答,可是再有N个doCommit消息。没有 消息开销和3N成正比,时间开销是3次消息往返。可是协议在没有haveCommitted消息时仍须要正常运作(它们的作用可是通知服务器删除过时的协调者消息),可是在估计协议开销上,不将haveCommitted消息计算在内。

原文发布时间为:2018-12-16

本文作者:gushitong

本文来自云栖社区商务商务合作伙伴“ 码洞”,了解相关信息须要关注“codehole”微信公众号

3.2、两阶段提交协议的超时

在下单的就让,须要在订单表中插入四根数据,可是把库存减去一

服务器可是偶尔崩溃。当一一兩个 多崩溃的服务器由一一兩个 多新应用应用进程取代后,它的可变内存被重置,崩溃就让的数据均丢失。此后新应用应用进程执行一一兩个 多可恢复过程,根据持久存储中的信息以及从这俩应用应用进程获得的信息设置对象的值,包括两阶段提交协议有关对象的值。当一一兩个 多处理器出显故障时,服务器也会崩溃,没有 它就不必发送错误的信息或将错误的值写入持久存储,即它不必产生随机故障。服务器崩溃可是出显在任了吗候,有点硬是在恢复时也可是出显。

2、两阶段提交的实现

为了实现两阶段提交协议,分布式事务中的协调者和参与者通常按照下面的接口进行通信:

不依赖协调者获取最终决定的最好的办法是通过参与者商务商务合作来获得决定。这俩策略的优点是须要在协调者出故障时使用。(在本篇文章中亲戚亲戚朋友不讨论这俩最好的办法)

haveCommitted(trans, participant)

首先考虑没有 的具体情况:某个投票者投Yes票并在等待协调者发回最终决定,即告诉它是提交事务还是放弃事务。没有 参与者的结果是不选取(uncertain)的,它在协调者处得到投票结果就让只有进行进一步处理。参与者只有单方面决定下一步做哪些,一起该事务使用的对象可是能释放以用于这俩事物。参与者向协调者发出getDecision请求来获取事务的结果,直到收到应答时,不可不都能否进入两阶段协议的第二阶段。

支付宝在扣款事务提交就让,向消息队列发送消息。此时的消息队列只记录消息,而并没有将消息发往余额宝。

在这俩这俩系统中都能找到上述具体情况的影子:

考虑下面这俩场景:当你发了工资就让,把你的当月工资¥1024从支付宝转到了余额宝。

同理,可是协调者处在故障,没有参与者将只有获得协定,直到协调者被替代为止,这可是原因分析分析不选取具体情况的参与者长时间的延迟。

doCommit(trans)

在该协议的第六个阶段,事务的每个参与者执行最终统一的决定。可是任何一一兩个 多参与者投票放弃事务,没有最终的决定是放弃事务。可是所有的参与者都投票提交事务,没有最终的决定是提交事务。

canCommit(trans) ?

对于没有未确认的消息,须要消息队列去支付宝系统查询这俩消息的具体情况,并进行更新。(可是支付宝可是在扣款事务提交成功后挂掉,此时消息的具体情况未被更新为:“确认发送“。从而原因分析分析消息只有被发送。

Lampson提出过一一兩个 多分布式事务的故障模型,包括了硬盘故障、服务器故障以及通信故障。该故障模型声称:须要保证算法在出显故障时正确工作,可是对于不可预见的灾难性故障则只有处理。尽管会出显错误,可是须要在处在不正确行为就让发现并处理哪些错误。Lampson的故障模型包括以下故障:

协调者告诉参与者放弃它的那每项事务。

在该协议的第一一兩个 多阶段,每个参与者投票表决该事务是放弃还是提交,一旦参与者要求提交事务,没有就不允许放弃该事务。可是,在一一兩个 多参与者要求提交事务就让,它须要保证最终不必可不都能否执行分布式事务中个人的那每项,即使该参与者出显故障而被中途替换掉。

协调者询问参与者算是须要提交事务,参与者回复个人的投票结果。

getDecision(trans) ?

5.2、重复投递

当支付宝扣款事务提交失败,向消息队列发送撤销。在得到撤销的指令后,消息队列撤销该消息,该消息将不必被发送。

协调者告诉参与者提交它的那每项事务。

还一一兩个 多多严重的问题是消息重复投递,以亲戚亲戚朋友支付宝转账到余额宝为例,可是相同的消息被重复投递两次,没有亲戚亲戚朋友余额宝账户可是增加2万而也有1万了。

doAbort(trans)

在搜索的就让可是点击了广告,须要先记录该点击事件,可是通知商家系统扣除广告费

举例来讲,你在北京很有名的姚记炒肝点了炒肝并付了钱后,亲戚亲戚朋友不必说会直接把你点的炒肝我就,可是就一张小票,可是就拿着小票到出货区排队去取。为哪些亲戚亲戚朋友要将付钱和取货一一兩个 多动作分开呢?原因分析分析这俩这俩,其中一一兩个 多有点硬要的原因分析分析是为了使亲戚亲戚朋友接待能力增强(并发量更高)。

还是回到亲戚亲戚朋友的问题,假使 这张小票在,你最终是能拿到炒肝的。同理转账服务也是没有,当支付宝账户扣除1万后,亲戚亲戚朋友假使 生成一一兩个 多凭证(消息)即可,这俩凭证(消息)上写着“让余额宝账户增加 1万”,假使 这俩凭证(消息)能可靠保存,亲戚亲戚朋友最终是须要拿着这俩凭证(消息)让余额宝账户增加1万的,即亲戚亲戚朋友能依靠这俩凭证(消息)完成最终一致性。

可是分布式事务处在严重的性能问题,在设计高并发服务的就让,往往通过这俩途径来处理数据一致性问题。

对持久性存储的写操作可是处在故障(或可是写操作无效或可是写入错误的值)。类似,将数据写到错误的磁盘块被认为是灾难性故障。文件存储可是损坏。在持久性存储中读数据时可根据校验和来判断数据块算是损坏。

问题在于,要保证每个参与者都投票,可是达成一一兩个 多一起的决定。在无故障时,该协议相当简单。可是,协议须要在出显各种故障(类似服务器崩溃,消息丢失或服务暂时无法通信)时不必可不都能否正常工作。

可是在支付宝账户扣除¥1024就让,余额宝系统挂掉了,余额宝的账户并没有增加¥1024,这就让就出显了数据不一致的具体情况。