类dubbo分布式事务处理模型

层级调用方式

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

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

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

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

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

两段式提交

这个在很多服务中都提到过，包括阿里讲分布式的事务的ppt里面。还是以用户下单的例子来举例：
ps:用Markdown实在是画不出来，所有就搞出了这个，Linux系统下弄的，将就一下吧！


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

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

使用消息队列来处理

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