框架架构详解

  • 通过上面的二篇文章，相信您对meepo应该有个大体的了解，并且已经搭建好了调试环境，那么接下来开始深入理解meepo。

  • 首先我们需要了解一下几个概念

    XA协议：两阶段提交其实比较简单，这边有两个资源提供准备和提交两个接口。

    由于隔离性互斥的要求，在事务执行过程中，所有的资源都是被锁定的，这种情况只适合执行时间确定的短事务。 但是为了保证分布式事务的一致性，大都是采用串行化的隔离级别来保证事务一致性，这样会降低系统的吞吐。

    但因为2PC的协议成本比较高，又有全局锁的问题，性能会比较差。 因此现在大家基本上不会采用这种强一致解决方案。

    结构图

    JTA规范：Java事务API（JTA：Java Transaction API）和它的同胞Java事务服务（JTS：Java Transaction Service），为J2EE平台提供了分布式事务服务（distributed transaction）的能力。

    某种程度上，可以认为JTA规范是XA规范的Java版，其把XA规范中规定的DTP模型交互接口抽象成Java接口中的方法，并规定每个方法要实现什么样的功能。

    JTA 深度历险这篇文章可以帮助理解JTA：https://www.ibm.com/developerworks/cn/java/j-lo-jta/

    byteJta是XA/JTA的一个开源实现，读者如果对XA/JTA感兴趣，可以参考更知名的Atomikos或者JOTM框架源码

    GTS：GTS是阿里不开源收费的框架，网上只有一些原理分析，meepo可以理解成GTS的一个开源实现，GTS原理：https://zhuanlan.zhihu.com/p/32684212

    GTS与XA架构相同，GTS架构由应用、事务管理器、资源管理器三个部分组成。资源管理器由事务分支处理模块、镜像查询构造模块、并发控制模块、恢复控制模块，以及存储在数据库中的GTS事务信息（GTS锁表与GTS日志表）等组成。

    所以写一个GTS的实现，不需要重复开发，基于一个已有的XA框架即可，选择byteJta是因为集成dubbo、springcloud，更切合实际项目

    结构图

    meepo正常业务时序图

    meepo-commit流程图

    byteJta正常流程：发起全局事务->执行业务（加入事务组）->发起全局prepare（全体通过）->发起全局commit

    meepo正常流程：发起全局事务->执行业务（加入事务组,prepare分支事务,commit分支事务）->发起全局commit（异步清理分支事务信息）

    meepo-rollback流程图

    byteJta回滚流程：发起全局事务->执行业务（加入事务组）->发起全局prepare（任一失败）->发起全局rollback

    meepo回滚流程：发起全局事务->执行业务（加入事务组,prepare分支事务,commit分支事务，任一失败）->rollback（异步回滚日志镜像，清理分支事务信息）

  • 正常业务中，byteJta最后一个分支commit前，会锁定所有分支业务对应的数据行，直到所有业务成功提交，整个过程效率非常低，整体速度通常取决于网速最慢的业务分支

    meepo在执行业务时直接prepare、commit分支事务，分支事务生命周期与本地事务相同，效率非常的高