分布式事务方案（二）

atomikos JTA/XA全局事务

TransactionEssentials：开源的免费产品

TransactionEssentials：

1、实现了JTA/XA规范中的事务管理器(Transaction Manager)应该实现的相关接口，如：

• UserTransaction实现是com.atomikos.icatch.jta.UserTransactionImp，用户只需要直接操作这个类
• TransactionManager实现是com.atomikos.icatch.jta.UserTransactionManager
• Transaction实现是com.atomikos.icatch.jta.TransactionImp

2、针对实现了JDBC规范中规定的实现了XADataSource接口的数据库连接池，以及实现了JMS规范的MQ客户端提供一层封装。
在JTA规范，XADataSource、XAConnection等接口应该由资源管理器RM来实现，而Atomikos的作用是一个事务管理器™，并不需要提供对应的实现。而Atomikos对XADataSource进行封装，只是为了方便与事务管理器整合。封装XADataSource的实现类为AtomikosDataSourceBean。典型的XADataSource实现包括：
1、mysql官方提供的com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
2、阿里巴巴开源的druid连接池，对应的实现类为com.alibaba.druid.pool.xa.DruidXADataSource
3、tomcat-jdbc连接池提供的org.apache.tomcat.jdbc.pool.XADataSource
而其他一些常用的数据库连接池，如dbcp、dbcp2或者c3p0，目前貌似尚未提供XADataSource接口的实现。如果提供给AtomikosDataSourceBean一个没有实现XADataSource接口的数据源，如c3p0的ComboPooledDataSource，则会抛出类似以下异常：

ExtremeTransactions在TransactionEssentials的基础上额外提供了以下功能：

支持TCC：这是一种柔性事务

支持通过RMI、IIOP、SOAP这些远程过程调用技术，进行事务传播。

本文主要针对Atomikos开源版本的事务管理器实现TransactionEssentials进行讲解，包括：

1、直接使用TransactionEssentials的API

2、TransactionEssentials与spring、mybatis整合

3、Atomikos配置详解

具体案例：http://www.tianshouzhi.com/api/tutorials/distributed_transaction/386

柔性事务：最大努力通知

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点：

1. 不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。

2. 定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。

举例来说：笔者曾经做过一个短信发送平台，背景是公司内部有多个业务都有发送短信的需求，如果每个业务独立实现短信发送功能，存在功能实现上的重复。因此专门做了一个短信平台项目，所有的业务方都接入这个短信平台，来实现发送短信的功能。简化后的架构如下所示：

短信发送流程如下：

1、业务方将短信发送请求提交给短信平台

2、短信平台接收到要发送的短信，记录到数据库中，并标记其状态为”已接收"

3、短信平台调用外部短信发送供应商的接口，发送短信。外部供应商的接口也是异步将短信发送到用户手机上，因此这个接口调用后，立即返回，进入第4步。

4、更新短信发送状态为"已发送"

5、短信发送供应商异步通知短信平台短信发送结果。而通知可能失败，因此最多只会通知N次。

6、短信平台接收到短信发送结果后，更新短信发送状态，可能是成功，也可能失败(如手机欠费)。到底是成功还是失败并不重要，重要的是我们知道了这调短信发送的最终结果

7、如果最多只通知N次，如果都失败了的话，那么短信平台将不知道短信到底有没有成功发送。因此短信发送供应商需要提供一个查询接口，以方便短信平台驱动的去查询，进行定期校对。

在这个案例中，短信发送供应商通知短信平台短信发送结果的过程中，就是最典型的最大努力通知型方案，通知了N次就不再通知。通过提供一个短信结果查询接口，让短信平台可以进行定期的校对。而由于短信发送业务的时间敏感度并不高，比较适合采用这个方案。

需要注意的是，短信结果查询接口很重要，必须要进行定期校对。因为后期要进行对账，笔者在做这个项目的时候，一个月的短信发送总量在高峰期可以达到1亿条左右，即使一条短信只要5分钱，一个月就有500W。

(这个5分钱是笔者估计的，在这么大的量的情况，一条短信到底需要多少钱我也不知道。因为商务对接过程，是没有我靓丽的身影的。总之短信发送要花很多钱，如果短信发送供应商说短信都发送成功了，而短信平台却一条成功的记录都没有，出现这种扯皮的情况就不好了)

最后提一点：当当网开源数据库中间件sharding-jdbc使用了最大努力通知型来实现分库分表情况下数据的一致性，说实话，个人觉得最大努力通知型不太适合于这种场景。目前，sharding-jdbc也正在开发另一种柔性事务方案TCC，我们后面将要讲解。

柔性事务 ：TCC两阶段补偿型

TCC的作用主要是解决跨服务调用场景下的分布式事务问题，在本文中，笔者将先介绍一个跨服务的场景案例，并分析其中存在的分布式事务问题；然后介绍TCC的基本概念以及其是如何解决这个问题的。
举例中国移动开户过程中对于号码和sim资源等的使用

TCC 的基本概念
TCC是Try-Confirm-Cancel的简称:

• Try阶段：
  完成所有业务检查（一致性），预留业务资源(准隔离性)，针对案例的阶段1，对应开户业务就是业务资源，所有的资源提供预留都成功，try阶段才算成功，必须要有对应的业务资源满足业务操作

• Confirm阶段：

  确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源，如果满足业务要求，则提交请求。

• Cancel阶段：

  取消Try阶段预留的业务资源。当某个业务方的业务资源没有预留成功，如证件资源验证不通过，则取消所有业务资源预留请求，即释放资源，中国移动在释放资源方面提供释放接口和后台进程异步释放方式。

TCC与XA两阶段提交有着异曲同工之妙，下图列出了二者之间的对比：

TCC两阶段提交与XA两阶段提交的区别是：
XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁
XA事务中的两阶段提交内部过程是对开发者屏蔽的，因此开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录，那么就必须等待锁释放。
TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁
TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在

TCC事务模型 VS DTP事务模型
在介绍完TCC的基本概念之后，我们再来比较一下TCC事务模型和DTP事务模型，如下所示：

TCC事务的优缺点：

• 优点：XA两阶段提交资源层面的，而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。

• 缺点：主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。还是航班预定案例，原来只需要提供一个购买接口，现在需要改造成try、confirm、canel3个接口，开发成本高。

柔性事务：可靠消息最终一致性

基于MQ的事务消息，以下展示了RocketMQ的事务消息机制。

事务消息的逻辑，由发送端 Producer进行保证(消费端无需考虑)

1. 首先，发送一个事务消息，这个时候，RocketMQ将消息状态标记为Prepared，注意此时这条消息消费者是无法消费到的。

2. 接着，执行业务代码逻辑，可能是一个本地数据库事务操作

3. 最后，确认发送消息，这个时候，RocketMQ将消息状态标记为可消费，这个时候消费者，才能真正的保证消费到这条数据。

   如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事务消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认。RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

   如果消费失败怎么办？阿里提供给我们的解决方法是：人工解决。

另外一种实现，并不是所有的mq都支持事务消息。也就是消息一旦发送到消息队列中，消费者立马就可以消费到。此时可以使用独立消息服务、或者本地事务表。

可以看到，其实就是将消息先发送到一个我们自己编写的一个"独立消息服务"应用中，刚开始处于prepare状态，业务逻辑处理成功后，确认发送消息，这个时候"独立消息服务"才会真正的把消息发送给消息队列。消费者消费成功后，ack时，除了对消息队列进行ack(图中没有画出)，对于独立消息服务也要进行ack，"独立消息服务"一般是把这条消息删除。而定时扫描prepare状态的消息，向消息发送端(生产者)确认的工作也由独立消息服务来完成。

对于"本地事务表"，其实和"独立消息服务"的作用类似，只不过"独立消息服务"是需要独立部署的，而"本地事务表"是将"独立消息服务"的功能内嵌到应用中。