【转载】分布式事务介绍

关于@Transactional注解

我在上一篇文章https://www.jianshu.com/p/f0d08e9ab454
提到了@Transactional注解，这个注解我们一般使用的时候直接加到某个方法上就可以了，通常我们捕获异常的时候这个注解也能够起到作用正常回滚，但在这个情况下会有一些问题

@Transactional(rollbackOn = { Exception.class })  
public void test() {  
     try {  
        doDbStuff1();  
        doDbStuff2();  //假如这个操作数据库的方法会抛出异常，现在方法doDbStuff1()对数据库的操作  不会回滚。  
     } catch (Exception e) {  
           e.printStackTrace();     
     }  
}  

有两种解决方式，

• service方法中不进行异常的捕捉，抛出异常到controller层

• 在catch语句中加上这么一句transactionAspectSupport.currentTransactionStatus().setRollbackOnly();或者throw new RuntimeException()

分布式事务

理论基础

数据库的 ACID 四大特性，已经无法满足我们分布式事务，这个时候又有一些新的大佬提出一些新的理论

1.CAP定理

• C (一致性consistency)
  更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。关于一致性，如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性。如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性。此外，如果允许存在部分数据不一致，那么就称之为弱一致性

• A (可用性Availability)
  可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果

• P (分区容错性partition-tolerance)
  分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障

熟悉 CAP 的人都知道，三者不能共有，如果感兴趣可以搜索 CAP 的证明，在分布式系统中，网络无法 100% 可靠，分区其实是一个必然现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是 A 又不允许，所以分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

2.BASE理论

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。

• 1. 基本可用（Basically Available）
     指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

• 2. 软状态（ Soft State）
     指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。

• 3. 最终一致（ Eventual Consistency）
     强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

mysql 对XA事务的支持

MySQL 从5.0.3开始支持XA分布式事务，且只有InnoDB存储引擎支持。MySQL Connector/J 从5.0.0版本之后开始直接提供对XA的支持

命令.png

1.MySQL XA 事务SQL语法

XA {START|BEGIN} xid [JOIN|RESUME]   //开启XA事务，如果使用的是XA START而不是XA BEGIN，那么不支持[JOIN|RESUME]，xid是一个唯一值，表示事务分支标识符
XA END xid [SUSPEND [FOR MIGRATE]]   //结束一个XA事务，不支持[SUSPEND [FOR MIGRATE]]
XA PREPARE xid 准备提交
XA COMMIT xid [ONE PHASE] //提交，如果使用了ONE PHASE，则表示使用一阶段提交。两阶段提交协议中，如果只有一个RM参与，那么可以优化为一阶段提交
XA ROLLBACK xid  //回滚
XA RECOVER [CONVERT XID]  //列出所有处于PREPARE阶段的XA事务

解决方案

比较常见的有以下5中方案

• XA方案

• TCC方案

• 本地消息表

• 可靠消息最终一致性

• 最大努力通知方案

这五种方案的区别可以参考这里
https://blog.csdn.net/crossroads10/article/details/88984279#commentBox
http://www.tianshouzhi.com/api/tutorials/distributed_transaction/389
https://yq.aliyun.com/articles/688001

流行框架

• Fescar

• TX-LCN

框架与上面的解决方案的最主要区别在于，进行集成配置后，基本上一个注解就完事了，不需要过多的侵入业务，设计类似confirm、cancel正向反向的冥等接口
上面两个框架的官方demo我都下载下来试了一下，Fescar一直在不停更新，没有跑成功，TX-LCN倒是跑成功了，但是两个框架在我潜水官方交流群一阵子之后，还是存在些许问题，还得继续研究