分布式事务

转于自己在公司的Blog：
http://pt.alibaba-inc.com/wp/experience_1264/distributed-transaction.html

关于Dubbo服务框架的分布式事务，虽然现在不急着做，但可以讨论一下。

我觉得事务的管理不应该属于Dubbo框架，
Dubbo只需实现可被事务管理即可，
像JDBC和JMS都是可被事务管理的分布式资源，
Dubbo只要实现相同的可被事务管理的行为，比如可以回滚，
其它事务的调度，都应该由专门的事务管理器实现。

在Java中，分布式事务主要的规范是JTA/XA，
其中：JTA是Java的事务管理器规范，
XA是工业标准的X/Open CAE规范，可被两阶段提交及回滚的事务资源定义，
比如某数据库实现了XA规范，则不管是JTA，还是MSDTC，都可以基于同样的行为对该数据库进行事务处理。

在JTA/XA中，主要有两个扩展点：

(1) TransactionManager
JTA事务管理器接口，实现该接口，即可完成对所有XA资源的事务调度，比如BEA的Tuxedo，JBossJTA等。

(2) XAResource
XA资源接口，实现该接口，即可被任意TransactionManager调度，比如：JDBC的XAConnection，JMS的XAMQ等。

而Dubbo的远程服务，也应该是一个XAResource，比如：XAInvoker和XAExporter，
Dubbo只需在第一次提交时，将请求发到服务提供方进行缓存和写盘，
在第二次提交时，再基于缓存调用服务的Impl实现，
当然一些健状性分支流程要考虑清楚。

JTA/XA的基本原理如下：



1. 用户启动一个事务：

transactionManager.begin(); 

2. 事务管理器在当前线程中初始化一个事务实例：

threadLocal.set(new TransactionImpl());

3. 用户调用JDBC或JMS或Dubbo请求，请求内部初始化一个XAResource实例：

XAResource xaResource = new XAResourceImpl(); // 比如：XAConnection

4. JDBC或JMS或Dubbo内部从当前线程获取事务：

Transaction transaction = transactionManager.getTransaction(); // 其内部为：threadLocal.get();

5. 将当前XAResource注册到事务中：

transaction.enlistResource(xaResource);

6. 用户提交一个事务：

transactionManager.commit(); // 其内部为：getTransaction().commit();

7. 事务for循环调用所有注册的XAResource的两阶段提交：

Xid xid = new XidImpl();
for (XAResource xaResource: xaResources) {
xaResource.prepare(xid);
xaResource.commit(xid, true);
xaResource.commit(xid, false);
}

8. 当然，还有一些异常流程，比如rollback和forget等。

举例：

TransactionManager transactionManager = ...; // 从JNDI进行lookup等方式获取
transactionManager.begin(); // 启动事务
try {
    jdbcConn.executeUpdate(sql); // 执行SQL语句，DB写入binlog，但不更新表
    jmsMQ.send(message); // 发送消息，MQ记录消息，但不进入队列
    dubboService.invoke(parameters); // 调用远程服务，Provider缓存请求信息，但不执行
    transactionManager.commit(); // 提交事务，数据库，消息队列，远程服务同时提交
} catch(Throwable t) {
    transactionManager.rollback(); // 回滚事务，数据库，消息队列，远程服务同时回滚
}

评论

12 楼 路呆呆丶 2017-06-15  

我基于spring的 tx下 PlatformTransactionManager，结合dubbo框架实现了对dubbo的分布式事务支持。框架很好的兼容并可以区分本地和分布式事务，并且该框架可以兼容任何基于spring的db框架，例如mybaits hibernate等。在需要的地方只需要添加一个分布式事务注解就行。我提供了一个TxManager服务来管理所有业务模块的事务调度，本身TxManager也可以做集群化。我把框架开源放在了github上，详细见：https://github.com/1991wangliang/transaction，希望大家多提提意见，共同帮我维护好框架。

11 楼 comedsh 2016-11-27  

Sequence diagram 有点小问题，在 6.start() 完了以后，应该执行 XAResource.end() 方法，让数据源的 XA Transaction 状态从 ACTIVE 进入 IDEL 状态；然后才能调用 9:prepare() 进入 PREPARED 状态；否则 XA Resource 会出错。

10 楼 hcq1986224 2015-12-01  

实现XAResource已经事务调度流程都不难，无非是dubbo服务回滚的不确定性，服务设计之初肯定都是以原子方式，如果发起方真的失败了，想要回滚dubbo原子服务产生的影响几乎不可能，因为不知道服务到底对哪种资源产生了影响，所以dubbo想要实现分布式事务，应该还是提供类似反交易或者补偿服务，发起方需要回滚时候，通过框架自动保证调用。

9 楼 guoshiguan 2015-09-21  

远程的分布式事务的方案不可能完美，不管是两段还是三段的事务，都是会有问题的。我相信支付宝的tcc这种方式也有相关的问题。但如果那种问题和反交易这种解决方案来比的话，那就不知好多少

8 楼 guoshiguan 2015-09-21  

lwclover 写道

lwclover 写道

存在两点问题：1.事务发起方宕机，服务端（Provider）应该需要回查，否则不知道是否成功。
2.如果这个过程包含两个远程调用，怎么办？

在加一点，dubbo服务的返回值做为其他的输入参数。

我觉得dubbo有返回值和事务并没有关系，因为，我不需要使用到dubbo服务的返回值，如果dubbo使用one way时，也不会去传播事务的上下文

7 楼 guoshiguan 2015-09-21  

lwclover 写道

存在两点问题：1.事务发起方宕机，服务端（Provider）应该需要回查，否则不知道是否成功。
2.如果这个过程包含两个远程调用，怎么办？

事务的传播可以用两种方式进行，一种是使用事务协调器，一种是使用协议本身来进行（粘滞连接）来进行，
使用第一种使用事务协调器的话，事务的传播是非常扁平的，事务的上下文依赖于事务协调器，如果事务发起方出现宕机，事务协调器会通知各事务的参与者进行回滚。这是可以不管有几个远程调用，这种方式，dubbo在请求时带上transactionId.
使用第二种的话，dubbo发起请求是把事务的上下文一起带过去，事务发起方提交是发起一个粘滞连接请求进行提交，应该会有比第一种更高的性能，但是只能适用于调用关系比较简单的情况，如果有异常，很多时候只能等待超时来进行回滚

6 楼 lwclover 2015-09-15  

lwclover 写道

存在两点问题：1.事务发起方宕机，服务端（Provider）应该需要回查，否则不知道是否成功。
2.如果这个过程包含两个远程调用，怎么办？

在加一点，dubbo服务的返回值做为其他的输入参数。

5 楼 lwclover 2015-09-15  

存在两点问题：1.事务发起方宕机，服务端（Provider）应该需要回查，否则不知道是否成功。
2.如果这个过程包含两个远程调用，怎么办？

4 楼 guoshiguan 2015-08-17  

我想在Dubbo上架一个事务的协调器来实现类似EJB的事务，两阶段的提交是一个耗时耗力的东西，类似的方案也没有一个是比较轻量的。

3 楼 hy2012_campus 2015-03-27  

我是遇到大牛了

2 楼 wxrmath9802 2015-03-03  

我理解事务无非是两种解决办法，一种是框架去解决，另一种是程序员在程序中控制。我觉得目前使用的dubbo，应该属于后一种，希望您详细举个实际案例说一下，在目前的环境中程序员手工控制该怎么做。

1 楼 gmh20052002 2013-12-06  

而Dubbo的远程服务，也应该是一个XAResource，比如：XAInvoker和XAExporter，
请问这个改如何实现，要自己扩展实现XAResource吧？