【spring的事务】分布式事务-单应用多数据源

@Transaction注解只能对单一数据源生效

在前文中的
Spring事务传播机制

@Transactional(rollbackFor = Exception.class)
	public void doPay(RefillRequest refillRequest) {
		// 完成支付转账
		accountAmountService.transfer(refillRequest.getUserAccountId(), 
				refillRequest.getBusinessAccountId(), refillRequest.getPayAmount());  
		// 创建充值订单
		refillOrderService.add(createRefillOrder(refillRequest));  
		// 给用户增加一次抽奖机会
		lotteryDrawService.increment(refillRequest.getUserAccountId()); 
		// 给用户增加充值面值5%的积分
		try {
			creditService.increment(refillRequest.getUserAccountId(),
					(double)Math.round((refillRequest.getPayAmount() * 0.05) * 100) / 100);
		} catch (Exception e) {
			e.printStackTrace();
		}

		// 如果使用了券的话，标记使用的券状态为已使用
		if(refillRequest.getCoupon() != null && refillRequest.getCoupon().getId() != null) {
			couponService.markCouponUsed(refillRequest.getCoupon().getId());  
		}
		// 如果要赠送券的话，就会插入一张券
		CouponActivity couponActivity = refillRequest.getDataPackage().getCouponActivity();
		if(couponActivity != null && couponActivity.getId() != null) {
			couponService.insert(createCoupon(refillRequest, couponActivity));  
		}

成立的前提是：转账，订单，抽奖，积分这些都在同一个数据库，@Transactional
这个注解才会生效。

随着业务量在增长，面临分库分表。这个几个服务被拆分为不同的数据库之后，
@Transactional加上也是失效了

可以实验一下：

在增加积分接口实现里抛出异常

@Transactional(rollbackFor = Exception.class)
	public void increment(Long userAccountId, Double updatedPoint) {
		creditMapper.increment(userAccountId, updatedPoint);
		throw new NullPointerException("null point");
	}

即使加了@Transactional，

	@Transactional(rollbackFor = Exception.class)
    public void finishRefillData(RefillRequest refillRequest) {

积分增加异常，但是依然转账成功了

分布式事务理论

1、XA规范

跨多个库的分布式事务的一个问题，有个叫做X/Open的组织，很早以前就定义了一整套的解决方案来处理分布式事务的问题。这里面有几个角色，就是AP（Application，应用程序），TM（Transaction Manager，事务管理器），RM（Resource Manager，资源管理器），CRM（Communication Resource Manager，通信资源管理器）

其实
Application：就是我们的系统，
TM：系统里嵌入的一个专门管理横跨多个数据库事务的一个组件
RM：说白了就是数据库（比如MySQL），
CRM：可以是消息中间件（但是也可以不用这个）

XA规范定义了一个很重要的概念，就是全局事务，就：任何一个操作失败了，其他所有库的操作全部回滚，这就是所谓的分布式事务

XA说白了，就是定义好的那个TM与RM之间的接口规范，就是管理分布式事务的那个组件跟各个数据库之间通信的一个接口，说白了就是这个意思

这个XA仅仅是个规范，具体的实现是数据库产商来提供的，比如说MySQL就会提供XA规范的接口函数和类库实现，等等

2、2PC理论

XA接口规范也是一个比较务虚的一个东西，光靠我说的这些东西还是没法落地的
2PC说白了就是基于XA规范搞的一套分布式事务的理论，也可以叫做一套规范，或者是协议，。Two-Phase-Commitment-Protocol，两阶段提交协议
2PC，其实就是基于XA规范，来让分布式事务可以落地，定义了很多实现分布式事务过程中的一些细节

（1）准备阶段

简单来说，就是TM先发送个prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，先准备执行，其实此时各个库会差不多先执行好，就是不提交罢了，也可以认为是prepare消息一发，各个库先在本地开个事务，然后执行好SQL，而且注意这里各个数据库会准备好随时可以提交或者是回滚，有对应的日志记录的。
然后各个数据库都返回一个响应消息给事务管理器，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息。

（2）提交阶段

如果prepare阶段，任意一个返回失败，或者超过指定时间没有返回。
这个时候TM直接判定这个分布式事务失败，然后TM通知所有的数据库，全部回滚回滚，其实这里你可以认为是通知每个数据库，把自己本地的那个事务回滚不就得了，然后各个库都回滚好了以后就通知TM，TM就认为整个分布式事务都回滚了

如果prepare阶段TM接收到所有的数据库返回的消息都是成功，直接发送个消息通知各个数据库说提交，提交好了通知下TM，TM要是发现所有数据库的事务都提交成功了，就认为整个分布式事务成功了。

2PC 二阶段提交协议的缺点：

1、TM单点故障
2、事务执行期间被锁定的资源，性能较低：
如果TM挂了或者网络故障，会导致很长时间一直被阻塞。

3、脑裂：在提交阶段，某个消息commit网络故障一直没有接收到，导致事务部分提交
4、事务状态丢失：即使把TM做成一个双机热备的，一个TM挂了自动选举其他的TM出来，但是如果TM挂掉的同时，接收到commit消息的某个库也挂了，两者同时挂，此时即使重新选举了其他的TM，压根儿不知道这个分布式事务当前的状态，因为不知道哪个库接收过commit消息，因为那个接收过commit消息的库也挂了。

3PC 三阶段提交

三段提交（3PC）是对两段提交（2PC）的一种升级优化，3PC在2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前，各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制，当参与者各种原因未收到协调者的commit请求后，会对本地事务进行commit，不会一直阻塞等待，解决了2PC的单点故障问题。

但3PC 还是没能从根本上解决数据一致性的问题。

3PC的缺陷：
如果TM在DoCommit阶段发送了abort消息给各个库，脑裂，某个库没接收到abort消息自己执行了commit操作，产生不一致性

所以2PC，3PC也好，都没法完全保证分布式事务的ok的，总有一些特殊情况下会出问题的。

JTA事务&&全局事务

全局事务，Global Transaction，是DTP模型中的一个概念，全局事务，指的其实就是说跨多个数据库的这么一个分布式事务

JTA事务，站在另外一个角度，其实是J2EE中的一个概念，Java Transaction API，JTA一套分布式事务的编程API

XA，实际上来说是一种接口规范，就是说TM在跟数据库（RM）进行通信时的接口规范，按照一套什么样的规范来管理和执行一整套的分布式事务呢，XA接口规范中定义的流程是什么样的呢？
start -> end
prepare -> commit / rollback

基于JTA + Druid多数据源 + Atomikos的 @Transactional的XA分布式事务支持改造

整合在spring boot + druid生产级环境中的一套单系统跨多库的分布式事务实践，使用的JTA事务管理器，加上Atomikos分布式事务的框架，Atomikos框架主要是提供了支持分布式事务的DataSource数据源的一个支持

JTA主要是提供了事务管理器，也就是分布式事务流程管控的这么一套机制

步骤如下：
1、pom.xml中引入依赖

    <dependency>
	    <groupId>org.springframework.boot</groupId>
	    <artifactId>spring-boot-starter-jta-atomikos</artifactId>
	</dependency>

2、修改application.yml配置文件

activity:
  datasource:
#   type: com.alibaba.druid.pool.DruidDataSource   改造前  
    type: com.alibaba.druid.pool.xa.DruidXADataSource

## 新增
jta:
  log-dir: classpath:tx-logs
  transaction-manager-id: txManager

3、重构druid数据源配置类

    /**
     * 创建druid数据库连接池bean
     * @return
     */
    @Bean(name = "activityDataSource")     
    @Primary  
    public DataSource activityDataSource(){
       // DruidDataSource datasource = new DruidDataSource(); 改造前
        DruidXADataSource datasource = new DruidXADataSource();
        datasource.setUrl(this.dbUrl);  
        datasource.setUsername(username);  
        datasource.setPassword(password);  
        datasource.setDriverClassName(driverClassName);  
        datasource.setInitialSize(initialSize);  
        datasource.setMinIdle(minIdle);  
        datasource.setMaxActive(maxActive);  
        datasource.setMaxWait(maxWait);          
        datasource.setTimeBetweenEvictionRunsMillis(timeBetweenEvictionRunsMillis);  
        datasource.setMinEvictableIdleTimeMillis(minEvictableIdleTimeMillis);  
        datasource.setValidationQuery(validationQuery);  
        datasource.setTestWhileIdle(testWhileIdle);  
        datasource.setTestOnBorrow(testOnBorrow);  
        datasource.setTestOnReturn(testOnReturn);  
        datasource.setPoolPreparedStatements(poolPreparedStatements);  
        datasource.setMaxPoolPreparedStatementPerConnectionSize(maxPoolPreparedStatementPerConnectionSize);  
        
        try {  
            datasource.setFilters(filters);  
        } catch (SQLException e) {  
            e.printStackTrace();
        }  
        
        datasource.setConnectionProperties(connectionProperties);
//        return datasource; 改造前

        AtomikosDataSourceBean atomikosDataSource = new AtomikosDataSourceBean();
        atomikosDataSource.setXaDataSource(datasource); //改造后
        return atomikosDataSource;
    }

//    @Bean(name = "activityTransactionManager")
//    @Primary
//    public DataSourceTransactionManager activityTransactionManager() {
//        return new DataSourceTransactionManager(activityDataSource());
//    } 改造前

    @Bean(name = "xatx") //改造后
    @Primary
    public JtaTransactionManager activityTransactionManager() {
        UserTransactionManager userTransactionManager = new UserTransactionManager();
        UserTransaction userTransaction = new UserTransactionImp();
        return new JtaTransactionManager(userTransaction, userTransactionManager);
    }

注意多个数据源的配置类DataSourceConfig里只需要定义一个JtaTransactionManager 即可。

xatx 就是JTA分布式事务管理器的名称

@Transactional(transactionManager = "xatx", rollbackFor = Exception.class)
    public void doPay(RefillRequest refillRequest) {
		// 完成支付转账
		accountAmountService.transfer(refillRequest.getUserAccountId(), 
				refillRequest.getBusinessAccountId(), refillRequest.getPayAmount());  
		// 创建充值订单
		refillOrderService.add(createRefillOrder(refillRequest));  
		// 给用户增加一次抽奖机会
		lotteryDrawService.increment(refillRequest.getUserAccountId()); 
		// 给用户增加充值面值5%的积分
		creditService.increment(refillRequest.getUserAccountId(),
				(double)Math.round((refillRequest.getPayAmount() * 0.05) * 100) / 100); 
		// 如果使用了流量券的话，标记使用的流量券状态为已使用
		if(refillRequest.getCoupon() != null && refillRequest.getCoupon().getId() != null) {
			couponService.markCouponUsed(refillRequest.getCoupon().getId());  
		}
		// 如果要赠送流量券的话，就会插入一张流量券
		CouponActivity couponActivity = refillRequest.getDataPackage().getCouponActivity();
		if(couponActivity != null && couponActivity.getId() != null) {
			couponService.insert(createCoupon(refillRequest, couponActivity));  
		}

在增加积分的环节故意抛出异常

	@Override
	public void increment(Long userAccountId, Double updatedPoint) {
		creditMapper.increment(userAccountId, updatedPoint);
		throw new NullPointerException("null point");
	}

在增加积分的时候抛出空指针异常
，查询分库，积分已经回滚

转账也已经回滚

一旦走了XA分布式事务之后，性能极差

（1）跨4~5个库的分布式事务的操作，750m左右完成
（2）跨4~5个库，你不用分布式事务，任何事务都不用，650ms左右

如果在更加复杂的场景里面，XA分布式事务，性能最极端的情况下，会降低10倍
不用XA分布式事务，可能就是50ms，用了就是500ms