类dubbo分布式事务处理模型

层级调用方式

层级调用，就是指对后端业务进行分层处理。通常来说都是基于了SOA的编程。

例如这一的一个场景:在电商网站买商品下单。这个动作在SOA系统中会调用到订单服务和库存服务。那么调用流程如下：

Created with Raphaël 2.1.0用户下单 开启订单层事务 订单服务-处理业务逻辑操作订单数据库开启库存层事务 库存服务-处理业务逻辑 操作库存数据库 提交库存层事务 提交订单层事务 结束 回滚事务 yesnoyesnoyesnoyesno

在这个流程中，订单服务一定要先操作业务逻辑和数据库数据，保证所有的业务流程操作成功，才能调用库存服务。否则就会出现库存层的业务成功了，返回订单服务的时候出现错误，导致库存层数据无法回滚。

这种方式在实际业务中要收到很大的限制，通常业务逻辑都过于复杂，很多情况下会在业务系统中相互调用，这时后就没办法做到顺序执行。

这个时序图表明的意思其实和流程图一样。

Created with Raphaël 2.1.0RequestRequestServiceServiceDubboService_OneDubboService_OneDubboService_TwoDubboService_TwoDatabaseDatabase接收请求处理自身业务逻辑调用dubbo服务处理自身业务逻辑调用dubbo服务处理自身业务逻辑commitreturn successreturn successcommitreturn successreturn successcommitreturn successreturn successerrorreturn failreturn failrollbackrollbackrollbackreturn fail

两段式提交

这个在很多服务中都提到过，包括阿里讲分布式的事务的ppt里面。还是以用户下单的例子来举例：

ps:用Markdown实在是画不出来，所有就搞出了这个，Linux系统下弄的，将就一下吧！



在这个流程中，面向用户端的商城服务，会分别去调用订单服务和库存服务，处理成功后，把成功或失败的结果返回给商城服务。只有订单服务和库存服务都成功的情况下，商城服务才会想订单服务和库存服务发送提交事务的命令，否则发送事务回滚命令。

这种方式只是一种理论上可以实现，但是在编码中，太过于复杂，而且延长事务开启的时间，延长数据库锁定数据的时间，导致数据库效率下降，在互联网项目中，肯定是无法接受的。我从未见到这中方式使用到项目中。

下面是整个过程的时序图：

Created with Raphaël 2.1.0RequestRequestServiceServiceDatabaseDatabaseDubboService_OneDubboService_OneDubboService_TwoDubboService_Two接收请求处理自身业务逻辑执行sql，等待commitsuccess 等待commit调用dubbo服务处理自身业务逻辑执行sql，等待commitsuccess 等待commitsuccess 等待commit调用dubbo服务处理自身业务逻辑执行sql，等待commitsuccess 等待commitsuccess 等待commitcommitcommitsuccesssuccesscommitcommitsuccesssuccesscommitsuccessreturn successrollbackrollbackrollbackrollbackrollbackrollbackrollbackrollbackrollbackrollbackreturn fail

使用消息队列来处理

这个方式是比较常用的方式，从原理上说，并不是解决了分布式事务的问题，只是避开了这个问题。使用这种方式，需要衡量整个业务流程中那些是强一直性的业务，那些是弱一致业务。强一致性的业务，使用RPC框架直接调用，方式类似与层级调用模型。操作成功后发送消息到MQ中，弱一致性的业务监听到消息以后，处理自己的业务逻辑，如果失败了，需要记录下消息，然后采用人工进行干预，或者启动异常数据处理程序，完成数据的最终一致性就行。