分布式事务学习（一）

1.事务

数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

1.1本地事务

事务有资源管理器（DBMS）本地管理

1.2全局事务

事务由全局事务管理器全局管理

1.3DTP（全局事务）之XA,TX

两阶段提交协议

2.javaEE标准分布式事务实现

2.1JavaEE分布式事务服务利弊

2.2BASE理论和CAP理论

CAP定理

事务

3.柔性事务

3.1柔性事务中的服务模式

柔性事务中的服务模式---可查询操作

柔性事务中的服务模式---TCC操作

解决

4 柔性事务解决方案

4.1异步确保性

异步确保型事务(会计记账)（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

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

4.2TCC

1两阶段型：就是分布式事务两阶段提交，对应技术上的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文档

最大

4.3最大努力通知型

最大努力通知型事务(商户通知)（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）