Question

请教Dubbo 如何解决分布式事务

Answer 1

目前比较多的解决方案有几个：
一、结合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

Answer 2

dubbo实现了分布式远程调用框架，多运行节点既能提高可靠性，又能提升负载能力。dubbo配置主要有注册中心（推荐zookeeper或redis）、提供者provider、消费者consumer，注册中心是第三方实现，所以主要配置好服务提供者和消费者就可以了。实际上服务接口和实现都是需要我们自己设计和实现的，dubbo做的事情就是将服务实现发布到注册中心，然后消费者从注册中心订阅服务接口，之后对接口的调用就由dubbo调度提供者去执行并返回结果。以下配置都有源码，见右侧“免费资源”。
提供者provider的配置：提供者是独立运行的节点，可以多实例运行，将服务注册到注册中心
必须要有application name，注册中心配置zookeeper，协议dubbo，超时6秒失败不重试，提供者加载repository和service层bean，然后发布接口service。

Answer 3

zookeeper是Dubbo服务的注册中心，provider提供服务后注册在zookeeper上， consumer可以接口和版本信息从zookeeper中获取相应的服务，服务对于consumer来说完全透明，根本感知不到该接口是来自本地和provider，就像引用本地的一个bean一样。 zookeeper可以实现服务的分布式，同时可以监控每个服务的状态以及调用次数情况等。 希望可以帮助到您！