分布式事务解决方案——柔性事务与服务模式

转载自分布式事务解决方案——柔性事务与服务模式

初识分布式系统

关于分布式一致性的探究

分布式系统的CAP理论（需要到博客中查看）

分布式系统的BASE理论（需要到博客中查看）

Java中的事务——JDBC事务和JTA事务

Java中的事务——全局事务与本地事务

关于分布式事务、两阶段提交协议、三阶提交协议

深入理解分布式系统的2PC和3PC

这里简单总结下以前几篇文章，算是本文的背景知识。在分布式系统中，存在CAP理论，即可用性、数据一致性和分区容错性无法同时满足。所以，一个基于CAP的最终一致性理论BASE理论是目前解决分布式问题比较靠谱的。

在分布式系统中，是无法使用本地事务保证数据的一致性的。一种标准的分布式事务就是全局事务（DTP模型）。他是基于2PC来控制的。但是由于2PC自身就存在同步阻塞的问题，这也就导致全局事务效率很低。所以，这种全局事务并不适合解决大型网站的分布式事务问题。

柔性事务

在业内，主要用来解决分布式事务的方案是使用柔性事务。所谓柔性事务，相比较与数据库事务中的ACID这种刚性事务来说，柔性事务保证的是“基本可用，最终一致。”这其实就是基于BASE理论，保证数据的最终一致性。

虽然柔性事务并不像刚性事务那样完全遵循ACID，但是，也是部分遵循ACID的，简单看一下关于ACID四个属性，柔性事务的支撑程度：

原子性：严格遵循

一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽

隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽

持久性：严格遵循

柔性事务的基础

前面介绍过了柔性事务的定义，目前，在业内，关于柔性事务，最主要的有以下三种类型：异步确保型、补偿型、最大努力通知型。

这三种类型的柔性事务基本都有对应的实现，不同的场景需要使用不同的柔性事务类型。而这几种柔性事务类型，其实还是依赖一些基础模式的，或者叫做基础接口，基础功能。

比如，要想使用可靠消息最终一致来实现异步确保型柔性事务，就依赖接幂等操作和可查询操作。关于具体实现，我们在后面的文章中介绍，本文简单介绍下这些实现柔性事务依赖的基础模式。

注意，下面要介绍的柔性事务的模式，并不是柔性事务的方案。这些是做柔性事务的基础。也就是说，如果你想做柔性事务，你的接口和功能要满足下面的几个要求。不一定要都满足，因为不同的方案的要求不一样。但是都不满足的话，是不可能做柔性事务的。

可查询操作

可查询操作，几乎是所有的分布式解决方案都需要的。

举一个常见的分布式场景的例子，如订单处理这一功能：

/** 支付订单处理 **/
public void completeOrder() {orderDao.update(); // 订单服务本地更新订单状态accountService.update(); // 调用资金账户服务给资金帐户加款pointService.update(); // 调用积分服务给积分帐户增加积分accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}

以上这个支付订单处理的例子中，除了订单服务本地更新订单状态以外的所有操作，都需要调用RPC接口来执行，这种情况单纯的本地事务就无法保证数据的一致性了。就需要引入分布式事务。在分布式事务执行过程中，如果某一个步骤执行出错，就需要明确的知道其他几个操作的处理情况，这就需要其他的服务都能够提供查询接口，保证可以通过查询来判断操作的处理情况。