分布式事物-柔性事物简介

在支付宝架构与技术 中对柔性事务有大体的描述：

 

能够看出，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的。
支付宝所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。
因为支付宝整个架构是SOA架构，所以传统单机环境下数据库的ACID事务知足了分布式环境下的业务须要，以上几种事务相似就是针对分布式环境下业务须要设定的。
其中：
一、两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。
这是分布式环境下事务处理的典型模式。

二、补偿型：
TCC型事务（Try/Confirm/Cancel）能够归为补偿型。
补偿型的例子，在一个长事务（ long-running ）中 ，一个由两台服务器一块儿参与的事务，服务器A发起事务，服务器B参与事务，B的事务须要人工参与，因此处理时间可能很长。若是按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不容许其余应用访问到事务过程当中的中间结果，直到整个事务被提交或者回滚。这就形成事务A中的资源被长时间锁定，系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。仍是上面的例子，服务器A的事务若是执行顺利，那么事务A就先行提交，若是事务B也执行顺利，则事务B也提交，整个事务就算完成。可是若是事务B执行失败，事务B自己回滚，这时事务A已经被提交，因此须要执行一个补偿操做，将已经提交的事务A执行的操做做反操做，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了必定的隔离性和一致性的，可是提升了long-running事务的可用性。
例子来源：OASIS的WS-BusinessActivity文档

三、异步确保型
将一些同步阻塞的事务操做变为异步的操做，避免对数据库事务的争用，典型例子是热点帐户异步记帐、批量记帐的处理。

四、最大努力型
PPT中提到的例子交易的消息通知（例如商户交易结果通知重试、补单重试）

若是有技术背景，能够参考另一个文档 大规模SOA系统中的分布事务处事 ，对支付宝分布式事务处理机制有较为详细描述。
更详细的也能够参考OASIS的相关资料。