一、传统的分布式事务模型
关于分布式事务，有一个被大家广泛接受的分布式处理模型：X/Open DTP模型。
该模型主要由4个组件构成：应用程序(Application Program)[AP]、资源管理器(Resource Manager)[RM]、事务管理器(Transaction Manager)[TM]和通信资源管理器(Communication Resource Manager)[CRM),如下所示：
其中：AP使用TX接口与TM交互，开始或提交全局事务；
TM给事务分配标识符，与RM通过XA接口规范，使用两阶段提交协议来完成全局事务；
RM提供对共享数据资源的访问；
CRM负责对通信进行控制；
1.1 二阶段提交协议
关于二阶段提交协议，在这里不再做详细的说明，大家可以参与下图：
二阶段提交协议存在如下问题：
1、可靠性差： 当网络环境较差时，数据操作出错的机率较大，任意一个事务参与者的临时故障，甚至是数据接收的延迟，都会导致全局事务的失败；
2、处理效率低：RM在事务执行过程及准备提交阶段需要锁定事务处理涉及到的所有数据资源，此时其它需要访问的事务就会一直处于等待状态；
3、可能存在阻塞现象
二、基于JMS的分布式异步处理技术
基于JMS的分布式处理模型如下所示：
采用JMS消息中间件作为通信资源管理器，分布式事务处理可以转化为消息处理和传统的本地事务处理两个部分。
基于JMS的分布式异步事务处理模型的事务处理过程如下所示：
事务发起者：AP调用全局TM启动一个全局事务，锁定数据资源执行本地操作，本地操作执行完成后，释放数据资源锁定，创建事务处理请求和事务上下文消息，发送到JMS消息服务器；
事务参与者：AP通过监听事务处理请求队列，获取本地事务处理请求和事务上下文消息，调用本地TM开始事务的执行，事务处理结果封装成JMS消息发送到JMS服务器的事务处理结果队列；
事务发起者：全局TM从事务处理结果队列中获取各个事务的处理结果。
其它分布式相关资源请参见：https://yq.aliyun.com/articles/7119
另蚂蚁花呗的分布式事务管理可以参见：http://www.infoq.com/cn/articles/technical-architecture-of-alipay-and-ant-check-later
分布式事务框架的流程图：
实现：
- 一个完整的业务活动由一个主业务服务与若干从业务服务组成。
- 主业务服务负责发起并完成整个业务活动。
- 从业务服务提供TCC型业务操作。
- 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的confirm操作，在业务活动取消时调用所有两阶段事务的cancel操作。”
与2PC协议比较：
- 没有单独的Prepare阶段，降低协议成本
- 系统故障容忍度高，恢复简单
其中关键组件异步可靠消息策略如下：
其中一些关键设计点：
- 若在第2、3、4步出现故障，业务系统自行决定回滚还是另起补偿机制；若在第6、7步出现异常，消息中心需要回查生产者；若在第8步出现异常，消息中心需要重试。第6步的确认消息由消息中心组件封装，应用系统无需感知。
- 此套机制保障了消息数据的完整性，进而保障了与通过异步可靠消息通讯的系统数据最终一致性。
- 某些业务的前置检查，需要消息中心提供指定条件回查机制。