现在公司遇到一个问题 , 服务器A上跑了一个dubbo服务使用数据库A , 服务器B上也跑了一个dubbo服务使用数据库B, 现在服务器C里调用这两个服务 , 那么要如何实现这两个dubbo服务的事务呢 , 望大神解答啊???
是直接调用的service服务么？如果是通过controller层调用，将对应controller调用服务配置事务处理，若调用失败，则直接数据回滚。
目前比较多的解决方案有几个：
一、结合MQ消息中间件实现的可靠消息最终一致性
二、TCC补偿性事务解决方案
三、最大努力通知型方案
第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
TRYING阶段主要是对业务系统进行检测及资源预留
CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。
CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。
具体的案例你也可以参考下这篇博客，它上面有完整的电商系统分布式事务实现案例：http://www.roncoo.com/article/detail/124243
你可以试着以下思路，先操作A数据库，把所有的参数都传到A服务上，在A服务的方法里，先执行A的数据库操作，再在A服务中把剩下的参数传到B服务中，再在B中进行数据库操作，B服务出现异常，会把异常抛到A服务，A服务方法的上一步数据库操作会回滚！
正常的流程就是:C调用A,A调用B
出现异常时：B回滚，抛异常给A，A回滚，抛异常给C,C回滚。
这广告打得不错,太屌了
楼主搞定这个问题没，我也遇到了这个问题，不知怎么整 啊，求指点
分布式事务解决方案的效果演示（结合支付系统真实应用场景）：
http://www.iqiyi.com/w_19rsveqlhh.html
我基于spring的 tx下 PlatformTransactionManager，结合dubbo框架实现了对dubbo的分布式事务支持。框架很好的兼容并可以区分本地和分布式事务，并且该框架可以兼容任何基于spring的db框架，例如mybaits hibernate等。在需要的地方只需要添加一个分布式事务注解就行。我提供了一个TxManager服务来管理所有业务模块的事务调度，本身TxManager也可以做集群化。我把框架开源放在了github上，详细见：https://github.com/1991wangliang/transaction，希望大家多提提意见，共同帮我维护好框架。
使用LCD框架试试看~