我们的电商项目中使用到了dubbo、zookeeper的服务化框架，把项目拆分成了订单，帐户，会员，积分，红包等服务，
在Consumer端调用服务的过程中可能会操作多个服务，每个服务可能操作着不同的数据源，这时候就涉及到分布式事务
的问题。关于分布式事务dubbo框架并没有提供可靠的方案，所以我们还是采用的传统分布式事务的两种解决方案。
第一种是分成两阶段提交的方式:
1、请求被发送到事务的协调器上
2、事务协调器准备一个预处理消息，并写到本地日志。然后把预处理消息发送到事务执行者上
3、事务执行者收到预处理消息后，执行本机事务，但不commit。成功返回yes，失败返回no。返回前记录日志。
4、事务协调器收集到所有响应消息，如果执行者全部返回yes，就给所有执行者发送commit消息，执行者接到消息
后执行commit操作，如果不是全部返回的yes，就给所有执行者发送abort消息，执行者收到消息执行事务放弃操作。
以上交互过程中记录日志的操作是为了故障恢复，开源软件atomikos可以快速实现上述方案。
但是这个方案不适合高并发系统，因为通信时间太长，锁定资源时间也长了，效率太低，这是强一致性的场景。
第二种是使用RabbitMQ消息队列的方式：
1、业务处理主服务在事务提交之前，向MQ发送请求消息。
2、业务处理主服务提交事务，向MQ发送确认消息。MQ得到确认消息进行真正的发送。
3、如果主服务事务提交失败，向MQ发送取消消息，MQ得到取消消息时不会进行发送。
4、其它服务在收到MQ消息后进行执行，并通知主服务，主服务把MQ中的消息删除。
这种方式可以保证最终一致性，并且解耦，但是实时性稍差，我们主要使用的就是这种方式。