design

架构设计

流程图

流程图原理详解

首先用户发起request请求进入consume端（也可以是controller层），controller层进入AOP切面，开启分布式事务

• 会与txManager通信，创建事务组
• 发起业务方法调用point.proceed(),这一步是分布式事务调用RPC方法的入口，会一个一个调用RPC方法
• 主线程调用provder1 提供的RPC方法，同样会进入切面，此时，会启动另一个线程去调用该RPC方法，当前线程wait

调用失败，调用业务方法线程，会唤醒等待的主线程，并把异常信息返回，走的就是one fial rollback这条线，消费方获取异常信息，自动回滚当前事务，分布式事务结束。

调用成功  业务线程，将唤醒主线程，并返回数据。业务线程同txManager 通信 将自己加入到当前事务组中，业务线程进入等待，等待txManager指令，commit or rollback 即 图中的4,5,6

• 主线程继续调用provider2提供的RPC方法 ，同样会进入AOP切面，当前主线程等待，启动一个业务线程去调用业务方法

调用失败，调用业务方法线程，会唤醒等待的主线程，并把异常信息返回，走的就是two fial rollback这条线，消费方获取异常信息，自动回滚当前事务，并与txManager进行通信（two TransactionGroup fail 这条线），txManager
发起rollback指令（two fail rollback 这条线），通知provider1 rollback

调用成功  业务线程，将唤醒主线程，并返回数据。业务线程同txManager 通信 将自己加入到当前事务组中，业务线程进入等待，等待txManager指令，commit or rollback 即 图中的9,10,11

• 主线程point.proceed()方法成功执行，会向txManager发出commit请求，txManager接收请求后，会检查各模块的网络通信等状态，符合条件后，发出commit指令，即 14。通知各个模块提交自己的事务。

三阶段提交最大的问题，在于当txManager发出commit指令后，业务方down机，或者网络通信断了。怎么解决事务一致性的问题。我们这么想，当txManager 发出commit指令的时候，其实业务方法都没有任何异常，都是执行成功的，那么数据就是需要提交的。那么我们本地的补偿机制正是为了该场景而考虑，如果down机，或者网络异常。本地服务恢复后，会执行补偿，达到数据的一致性。如果业务方是集群部署的话，会立刻执行补偿，达到数据的一致性。

重要提醒，如果调用服务方是timeout，那么会判断当前事务不成功，这次分布式事务统一不会执行。如需了解更多细节，请您参考源码，欢迎大家一起探讨，指正。