所有栏目 | 云社区 美国云服务器[国内云主机商]
你的位置:首页 > 云社区 » 正文

分布式计算是如何控制事务的?

发布时间:2020-04-15 16:14:53

资讯分类:分布式计算  事务  dubbo  soa  事务  服务  调用
分布式计算是如何控制事务的?

事务的管理不应该属于Dubbo框架, Dubbo只需实现可被事务管理即可, 像JDBC和JMS都是可被事务管理的分布式资源, Dubbo只要实现相同的可被事务管理的行为,比如可以回滚, 其它事务的调度,都应该由专门的事务管理器实现。 在Java中,分布式事务主要的规范是JTA/XA, 其中:JTA是Java的事务管理器规范, XA是工业标准的X/Open CAE规范,可被两阶段提交及回滚的事务资源定义, 比如某数据库实现了XA规范,则不管是JTA,还是MSDTC,都可以基于同样的行为对该数据库进行事务处理。

首先是不建议采用XA两阶段提交方式去处理分布式事务,要知道要能够支持XA分布式事务,必须是要实现XA规范才可以,而Service本身是无状态的,如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。

可以设想一个最简单的分布式事务场景,对于跨银行的转账操作,该操作涉及到调用两个异地的Service服务,一个是本地提供的取款服务,一个是目标银行提供的存款服务,该两个服务本身无状态且独立,构成一个完整的事务。对于事务的处理初步分析: 事务补偿机制 事务补偿即在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链,则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态,也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理,建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。

在这种情况下以上面例子来说,首先调用取款服务,完全调用成功并返回,数据已经持久化。然后调用异地的存款服务,如果也调用成功,则本身无任何问题。如果调用失败,则需要调用本地注册的逆向服务(本地存款服务),如果本地存款服务调用失败,则必须考虑重试,如果约定重试次数仍然不成功,则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件,由消息中间件接管后续操作。 在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性,我们可以考虑实现一个通用的事务管理器,实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册,由事务管理器接管所有的事务补偿和回滚操作。

基于消息的最终一致性 在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题,如果需要的是最终一致性,那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦,解耦的关键就是异步消息和消息持久化机制。 还是以上面的例子来看。对于转账操作,原有的两个服务调用变化为第一步调用本地的取款服务,第二步发送异地取款的异步消息到消息中间件。如果第二步在本地,则保证事务的完整性基本无任何问题,即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。

由于解耦,我们看到客户得到成功返回的时候,如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定,因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析,然后调用异地银行提供的存款服务进行存款,如果服务调用失败则进行重试。

异地银行存款操作不应该长久地出现异常而无法使用,因此一旦发现异常我们可以迅速的解决,消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决,在不到万不得已的情况下本地的取款服务一般不进行可逆操作。 在本地取款到异地存款两个服务调用之间,会存在一个真空期,这段时间相关现金不在任何一个账户,而只是在一个事务的中间状态,但是客户并不关心这个,只要在约定的时间保证事务最终的一致性即可。

关于幂等操作的问题 重复调用多次产生的业务结果与调用一次产生的业务结果相同,简单点讲所有提供的业务服务,不管是正向还是逆向的业务服务,都必须要支持重试。因为服务调用失败这种异常必须考虑到,不能因为服务的多次调用而导致业务数据的累计增加或减少。 关于是否可以补偿的问题 在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务,因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。 3

在上面的例子来看,如果采用事务补偿机制,基本可以是做到准实时的补偿,不会有太大的影响。而如果采用基于消息的最终一致性方式,则可能整个周期比较长,需要较长的时间才能给得到最终的一致性。比如周六转款,客户可能下周一才得到通知转账不成功而进行了回退,那么就必须要考虑客户是否能给忍受。

其次对于前面讨论,如果真正需要的是实时的一致性,那么即使采用事务补偿机制,也无法达到实时的一致性。即很可能在两个业务服务调用中间,客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下,我们不得不考虑需要在数据库表增加业务状态锁的问题,即整个事务没有完整提交并成功前,第一个业务服务调用虽然持久化在数据库,但是仍然是一个中间状态,需要通过业务锁来标记,控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。

分布式计算是如何控制事务的?

分布式事务:是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。


X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。 XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。 二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说:两阶段提交主要保证了分布式事务的原子性:即所有结点要么全做要么全不做)。

所以大部分的关系型数据库通过两阶段提交(2 Phase Commit 2PC)算法来完成分布式事务就不足为奇了。


1.两阶段/三阶段提交

2PC/3PC全称:Two/Three Phase Commit,中文名叫叫两阶段/三阶段提交;为了使基于分布式系统架构下的所有节点在进行事务处理的过程中能够ACID特性而设计的一种算法,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交两阶段提交的算法如下:

第一阶段:提交事务阶段(投票阶段)

第二阶段:执行事务提交(执行阶段)

这种方式缺点比较多,通常在复杂场景下是不推荐使用的,除非是非常简单的场景,非常容易提供回滚,而且依赖的服务也非常少的情况。


2.本地方法表

这种实现方式的思路,其实是源于ebay;其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅,借助关系型数据库中的表即可实现。举个经典的跨行转账的例子来描述。

第一步伪代码如下,扣款1W,通过本地事务保证了凭证消息插入到消息表中。

第二步,通知对方银行账户上加1W了,如何通知对方:可以通过轮询或者MQ的方式


3.MQ

方式

大致伪代码如下,跨行转账为例

try{
1.本地更新数据库,如果更新成功,执行第二部
2.通过MQ发送消息
}catch{
rollback();
}

如果第一步失败,那不会将消息发送到MQ,如果第一步成功,第二步失败,那捕获异常回滚数据,保证数据一致性;


4.事务MQ

有MQ是直接支持分布式事务的,比如阿里的RocketMQ;RocketMQ处理事务消息的大致流程如下:

1.生产者发送"待确认"消息;

2.RocketMQ接收到消息进行相关保存操作,成功以后返回状态给生产者;

3.生产者接收到的返回如果为SEND_OK状态,将执行本地事务操作;

4.根据本地事务执行的结果,生产者执行commit还是rollback;

5.如果第四步生产者执行操作失败,服务器会在经过固定时间段对状态为"待确认"的消息发起回查请求;

6.生产者接收到回查请求后根据本地事务的结果返回commit还是rollback;

7.服务器收到结果后执行相关操作。


总结

可以看到第一种方式是保证绝对的一致性,这种在互联网行业很少使用,主要是性能太差了;后面四种情况都是保证了“最终一致性”,这种方式用的比较广泛;另外分布式事务本质上其实是数据一致性问题,所以可以关注一下CAP理论和Base理论;更多的可以关注本人的相关文章。

分布式计算是如何控制事务的?

1什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

分布式计算是如何控制事务的?

谢谢邀请:分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证不同数据库的数据一致性。



分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务,部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式,而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景。

分布式计算是如何控制事务的?

各个服务处理好自身回滚,将自己出错的信息通知给其他服务进行处理。记录好各个服务的日志信息,出现断电情况通过日志恢复。或者第三方服务统一控制事物。看要做到什么程度。说得简单,做起来挺复杂的

分布式计算是如何控制事务的?

对于这种分布式的亊务挖制,我认为总设计师应该实际的工作情况,时刻监控各个方面有关联的系纺,统一调配,随时监督,我认为这样才能控荆整体亊态的发展,对这方面我是个外行,只是发表自已的一点看法。

分布式计算是如何控制事务的?

分布式事物其实是个伪概念,因为传统的JTA或2PC在分布式环境下无法抵抗网络的不稳定性,分布式的特点就是默认网络不稳定,这与在同一台服务器中概念是不同的,而CAP定理才是分布式网络的根本依据,传统JTA或者基于RPC的所谓事务都是不适合分布式的,因为网络容错性差 很脆弱。所以最终一致性的柔性事务才是根据CAP下的选择,比如Saga等都是成熟方案。

分布式计算是如何控制事务的?

说不了如何,那个说来话长,小篇幅讲不清楚。我要说的是,事务一致性并不少见,只要是有复杂金融交易场景的都需要事务一致性,这个不难。真正难的是在互金场景大规模交易下如何低成本地实现事务一致性。普通的Dubbo根本做不了,现在唯一在大量金融核心交易实践中实现分步式事务一致性并且能对外输出的只有蚂蚁金服的SOFA及其中间件。

留言与评论(共有 0 条评论)
   
验证码:
Top