柔性事务 和 刚性事务
柔性事务满足 BASE理论 (基本可用,最终一致),刚性事务满足ACID理论
柔性事务分为
1> 两阶段型
2> 补偿型
3> 异步确保型
4> 最大努力通知型几种,由于支付宝整个架构是 SOA架构,因此传统单机环境下数据库的 ACID事务 满足分布式环境下的业务需要,以上几种事务类似就是针对分布式环境下业务需要设定的
两阶段提交 (2PC) 型
两阶段型 就是分布式事务两阶段提交,对应技术上的 XA、JTA/JTS。这是分布式环境下事务处理的典型模式
事务补偿型 (TCC事务)
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事务的可用性
异步确保型
将一些同步阻塞的事务操作变为异步的操作,避免对数据库事务的争用,典型例子是热点账户异步记账、批量记账的处理
最大努力型