什么是柔性事务?

概念

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

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

原子性:严格遵循
一致性:事务完成后的一致性严格遵循;事务中的一致性可适当放宽
隔离性:并行事务间不可影响;事务中间结果可见性允许安全放宽
持久性:严格遵循

在业内，关于柔性事务，最主要的有以下三种类型:异步确保型、补偿型、最大努力通知型。

柔性事务的分类

柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型。

两阶段型 分布式事务二阶段提交，对应技术上的 XA、JTA/JTS，这是分布式环境下事务处理的典型模式。
补偿型 TCC 型事务（Try-Confirm-Cancel）可以归为补偿型。在 Try 成功的情况下，如果事务要回滚，Cancel 将作为一个补偿机制，回滚 Try 操作；TCC 各操作事务本地化，且尽早提交（没有两阶段约束）；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为。 TCC 是将资源层的二阶段提交协议转换到业务层，成为业务模型中的一部分。
异步确保型 将一些有同步冲突的事务操作变为异步操作，避免对数据库事务的争用，如消息事务机制。
最大努力通知型 通过通知服务器（消息通知）进行，允许失败，有补充机制。

想要实现柔性事务，有几个基础条件需要具备，以下介绍几个柔性事务实现的基础。

柔性事务实现的基础

1、可查询操作

可查询操作，几乎是所有的分布式解决方案都需要的。
举一个常见的分布式场景的例子，如订单处理这一功能:

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

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

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

以上这个支付订单处理的例子中，除了订单服务本地更新订单状态以外的所有操作，都需要调用RPC接口来执行，这种情况单纯的本地事务就无法保证数据的一致性了。就需要引入分布式事务。

在分布式事务执行过程中，如果某一个步骤执行出错，就需要明确的知道其他几个操作的处理情况，这就需要其他的服务都能够提供查询接口，保证可以通过查询来判断操作的处理情况。