SpringBoot集成TX-LCN分布式事务框架

TX-LCN分布式事务

官方文档地址
框架定位
LCN并不生产事务，LCN只是本地事务的协调工

分布式事务存在两大理论依据：

CAP定律 BASE理论

CAP定律

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容错性（P）

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

事务特性（ACID）

原子性（A）
所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。
一致性（C）
事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。
隔离性（I）
所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
持久性（D）
所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。
这种特性 简称 刚性事物

事物隔离级别

READ-UNCOMMITTED(读取未提交内容)级别 2）
READ-COMMITTED（读取提交内容）级别 3）
REPEATABLE-READ(可重读)级别 4）
SERIERLIZED(串行化)
更新丢失：两事务同时更新，一个失败回滚覆盖另一个事务的更新。
脏读：事务T1读取到事务T2修改了但是还未提交的数据，之后事务T2又回滚其更新操作，导致事务T1读到的是脏数据。
不可重复读：事务T1读取某个数据后，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。
虚读（幻读）：事务T1读取在读取某范围数据时，事务T2又插入一条数据，当事务T1再次数据这个范围数据时发现不一样了，出现了一些“幻影行”。

分布式事物

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。也就是保证一个打的事务里的若干个小事务的强一致性要么全部成功，要么全部回滚或失败。

柔性事务和刚性事务

柔性事务满足BASE理论（基本可用，最终一致）
刚性事务满足ACID理论

柔性事务分为
1.两阶段型
2.补偿型
3.异步确保型
4.最大努力通知型几种。 由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。

分布式事物解决方案

1.分布式事物解决方案 可以使用全局事物2pc（两段提交协议）、3pc(三段提交协议)，tcc补偿机制、提供回滚接口、分布式数据库
2.LCN 核心采用3PC+TCC补偿机制

什么是XA接口

XA–eXtended Architecture 在事务中意为分布式事务
XA由协调者(coordinator，一般为transaction manager)和参与者(participants,一般在各个资源上有各自的resource manager)共同完成。在MySQL中，XA事务有两种。
mysql 的XA事务分为内部XA和外部XA。 外部XA可以参与到外部的分布式事务中，需要应用层介入作为协调者；内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。 Mysql 在XA事务中扮演的是一个参与者的角色，而不是协调者。

扫描二维码关注公众号，回复： 10511670 查看本文章

什么是JTA

JTA是Java的API，是个处理事务的。
事务必须保证用户操作的原子性，一致性，隔离性，持久性。
事务处理方式有两个，一个是本地事务还有一个是分布式事务
本地事务：
本地服务程序内部的处理方式
分布式事务：
满足事务的一致性

2PC两段提交-----------》3PC三段提交
一：2pc
阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager汇报自己已经准备好。
阶段二为提交阶段。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
二：3pc

1、引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
CanCommit:
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit:
协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
1.发送中断请求 协调者向所有参与者发送abort请求。
2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
DoCommit
该阶段进行真正的事务提交，也可以分为以下两种情况。
执行提交
1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3.响应反馈 事务提交完之后，向协调者发送Ack响应。
4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。
中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
1.发送中断请求 协调者向所有参与者发送abort请求
2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）

2PC与3PC的区别

解决的单点故障问题，并减少阻塞，
3PC无法解决：由于网络原因数据不一致以及太过保守问题。

TCC两阶段补偿事务机制

TCC是Try-Confirm-Cancel的简称:
解决跨服务调用场景下的分布式事务问题

MQ分布式事物

采用时效性高的 MQ，由对方订阅消息并监听，有消息时自动触发事件
采用定时轮询扫描的方式，去检查消息表的数据。
消息中间件是如何保证数据一致性--------使用超时询问机制。
优点：消息数据独立存储 ，降低业务系统与消息系统之间的耦合。
缺点：一次消息发送需要两次请求；业务处理服务需要实现消息状态回查接口

LCN框架

LCN框架在2017年6月份发布第一个版本，从开始的1.0，
LCN：
锁定事务单元（lock）
确认事务模块状态(confirm)
通知事务(notify)

改变：

5.0以后由于框架兼容了LCN、TCC、TXC三种事务模式，为了避免区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务框架。

官网例子：

方案：

若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。

单机版：
Maven:

 <codingapi.txlcn.version>5.0.2.RELEASE</codingapi.txlcn.version>
 <!--lcn分布式事务框架-->
        <dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-tc</artifactId>
            <version>${codingapi.txlcn.version}</version>
        </dependency>

        <dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-tm</artifactId>
            <version>${codingapi.txlcn.version}</version>
        </dependency>

        <dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-txmsg-netty</artifactId>
            <version>${codingapi.txlcn.version}</version>
        </dependency>

业务层方法：

    @LcnTransaction  表明使用lcn模式
    @Transactional   本地事务

启动类：

@EnableDistributedTransaction  事务客户端

yml:

init-db: true
tx-lcn:
  client:
    manager-address: 127.0.0.1:8070
  logger:
    enabled: true
    driver-class-name: ${spring.datasource.driver-class-name}
    jdbc-url: jdbc:mysql://127.0.0.1:3306/testpay?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull&serverTimezone=Asia/Shanghai&useSSL=false
    username: ${spring.datasource.username}
    password: ${spring.datasource.password}

分布式服务调用：

服务端：

可以新建一个分布式事务管理项目服务

 <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
	<dependency>
	    <groupId>com.codingapi.txlcn</groupId>
	    <artifactId>txlcn-tm</artifactId>
	    <version>5.0.2.RELEASE</version>
	</dependency>
  </dependencies>

启动类：

@SpringBootApplication
@EnableEurekaClient
@EnableTransactionManagerServer  增加服务放注解

yml配置：

spring:
  application:
    name: TransactionManager
  #数据库引用
  datasource:
    name: testsys
    url: jdbc:mysql://127.0.0.1:3306/txsys?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: admin
    # 使用druid数据源
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: com.mysql.cj.jdbc.Driver
    filters: stat
    maxActive: 20
    initialSize: 1
    maxWait: 60000
    minIdle: 1
    timeBetweenEvictionRunsMillis: 60000
    minEvictableIdleTimeMillis: 300000
    validationQuery: select 'x'
    testWhileIdle: true
    testOnBorrow: false
    testOnReturn: false
    poolPreparedStatements: true
    maxOpenPreparedStatements: 20
  #redis引用
  redis:
    host: 127.0.0.1
    password:
    port: 6379
    jedis:
      pool:
        max-active: 1000
        max-wait: -1
        max-idle: 100
        min-idle: 1
server:
  port: 7970

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/


tx-lcn:
  manager:
    dtx-time: 60000

客户端

Maven:

<codingapi.txlcn.version>5.0.2.RELEASE</codingapi.txlcn.version>
	 <!--lcn分布式事务框架-->
	        <dependency>
	            <groupId>com.codingapi.txlcn</groupId>
	            <artifactId>txlcn-tc</artifactId>
	            <version>${codingapi.txlcn.version}</version>
	        </dependency>
	        
	        <dependency>
	            <groupId>com.codingapi.txlcn</groupId>
	            <artifactId>txlcn-txmsg-netty</artifactId>
	            <version>${codingapi.txlcn.version}</version>
	        </dependency>

业务层方法：

@LcnTransaction(propagation = DTXPropagation.REQUIRED)分布式注解

yml:

#lcn配置

tx-lcn: 
  client: 
    manager-address: 127.0.0.1:8070
  springcloud:
    loadbalance:
      enabled: true

针对fegin接口调用

<lcn.last.version>5.0.2.RELEASE</lcn.last.version>

    <dependency>
        <groupId>com.codingapi</groupId>
        <artifactId>transaction-springcloud</artifactId>
        <version>${lcn.last.version}</version>
        <exclusions>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>*</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

    <dependency>
        <groupId>com.codingapi</groupId>
        <artifactId>tx-plugins-db</artifactId>
        <version>${lcn.last.version}</version>
        <exclusions>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>*</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

基于http重写两个类：

public class TxManagerHttpRequestServiceImpl implements TxManagerHttpRequestService {
    @Override
    public String httpGet(String url) {
        System.out.println("httpGet-start");
        String res = HttpUtils.get(url);
        System.out.println("httpGet-end");
        return res;
    }

    @Override
    public String httpPost(String url, String params) {
        System.out.println("httpPost-start");
        String res = HttpUtils.post(url,params);
        System.out.println("httpPost-end");
        return res;
    }
}
	
public class TxManagerTxUrlServiceImpl implements TxManagerTxUrlService {
    @Value("${tm.manager.url}")
    private String url;

    @Override
    public String getTxUrl() {
        System.out.println("load tm.manager.url ");
        return url;
    }
}