SpringBoot2分布式事务管理

本地事务

事务的基本性质

数据库的四个特性: 原子性(atomicity) ,一致性(consistency) ,隔离性(lsolation) ,持久性(durabilily)

原子性: 一系列操作整体不可拆分,要么同时成功,要么同时失败
一致性: 数据在事务的前后,业务整体一致
隔离性: 事务之间相互隔离
持久性: 一旦事务成功,数据一定会落盘在数据库

在以往的单体应用中,我们多个业务操作使用同一条连接操作不同的数据库表,一旦有异常,很容易整体回滚.

事务的隔离级别

read uncommitted (读未提交)
- 该隔离级别的事务会读到其它未提交事务的数据,此现象也称为脏读
read committed(读已提交)
- 一个事务可以读取到另一个已提交的事务,多次读取会造成不一样的结果,此现象称为不可重复读问题.oracle和sql server 的默认隔离级别
repaatable read(可重复读)
- 该隔离级别是mysql默认的隔离级别,在同一个事务里,select的结果是事务开始的时间点的状态,因此,同样的select操作读到的结果会是一致的,但是,会有幻读的现象.mysql的innoDB引擎可以通过next-key locks 机制来避免幻读
serializable(序列化)
- 该隔离级别下的事务都是串行顺序执行的,mysql 数据的InnoDB 引擎会给读操作隐式加一把读共享锁,从而避免了脏读,不可重复读和幻读的问题

事务的传播行为

1、PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，

就加入该事务，该设置是最常用的设置。

2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当

前不存在事务，就以非事务执行。

3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果

当前不存在事务，就抛出异常。

4、PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当

前事务挂起。

6、PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，

则执行与 PROPAGATION_REQUIRED 类似的操作。

@Transactional // 事务注解的使用

@Transactional(isolation = Isolation.READ_COMMITTED)  // 设置事务隔离级别

@Transactional(propagation = Propagation.REQUIRED)  // 事务的传播行为

事务里面的坑

在同一个类里面，编写两个方法，内部调用的时候，会导致事务设置失效。原因是没有用到代理对象的缘故。

// 解决方法

导入 spring-boot-starter-aop : 引入了 aspectj

@EnableTransactionManagement(proxyTargetClass = true)
    
@EnableAspectJAutoProxy(exposeProxy=true) 开启aspectj 动态代理功能,默认是jdk自动代理,以后所有的动态代理都是aspectj创建的
    
AopContext.currentProxy() 调用方法

分布式事务

CAP定理

一致性 (Consistency)
- 在分布式系统中的所有数据备份,在同一时刻是否同样的值, (等同于所有节点访问同一份最新的数据副本)
可用性 (Availability)
- 在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求,( 对数据更新具备高可用性)
分区容错性 (Partition tolerance)
- 大多数分布式系统都分布在多个子网络,每个网络就叫做一个区(partition) .分区容错的意思是,区间通行可能失败.

CAP原则,这三个要素最多只能同时实现两点,不可能三者兼顾.

分布式系统中实现一致性的算法有：raft算法、paxos

http://thesecretlivesofdata.com/raft/

raft算法

心跳机制和数据复制保持数据的一致性

存在的问题

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所

以节点故障、网络故障是常态，而且要保证服务可用性达到 99.99999%（N 个 9），即保证

P 和 A，舍弃 C。

BASE理论

是对 CAP 理论的延伸,思想是即使无法做到强一致性 (CAP的一致性就是强一致性),但可以采用适当的采取弱一致性,即最终一致性.

BASE 是指

基本可用 ( basically available)
- 基本可用是指分布式系统在出现故障的时候,允许损失部分可用性(例如响应时间,功能上的可用性),允许损失部分可用性.需要注意的是,基本可用绝不等价于系统不可用
  - 响应时间上的损失: 正常情况下搜索引擎需要在0.5秒之内返回给用户响应查询结果,但是由于故障(比如系统部分机房发生断电或者断网故障),查询结果的响应时间增加到1-2秒
  - 功能上的损失: 购物网站在购物高峰时期(如双十一),为了保护系统的稳定性,部分消费者可能会被引导到一个降级页面
软状态 ( soft state )
- 软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性.分布式存储中一般一份数据会有多个副本,允许不同副本同步的延时就是软状态的体现.mysql replication的异步复制也是一种体现
最终一致性 (eventual consistency)
- 最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态.弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况.

强一致性、弱一致性、最终一致性

从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性.

对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性,如果能容忍后续的部分或者全部访问不到,则是弱一致性,如果经过一段时间后要求能访问到更新后的数据,则是最终一致性.

分布式事务方案

2PC 模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是

否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务

中的那部分信息。

XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。
XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景
XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。
也有 3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理）

柔性事务-TCC 事务补偿型方案

刚性事务：遵循 ACID 原则，强一致性。

柔性事务：遵循 BASE 理论，最终一致性；

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致

一阶段 prepare 行为：调用自定义的 prepare 逻辑。

二阶段 commit 行为：调用自定义的 commit 逻辑。

二阶段 rollback 行为：调用自定义的 rollback 逻辑。

所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中

柔性事务-最大努力通知型方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种

方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种

方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通

知次数后即不再通知。

案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对

账文件），支付宝的支付成功异步回调

柔性事务-可靠消息+最终一致性方案（异步确保型）

柔性事务 -可靠消息 + 最终一致性方案 ( 异步确保型)

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只

记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确

认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。

防止消息丢失： 
/*** 1、做好消息确认机制（pulisher，consumer【手动 ack】） * 2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一 遍*/
CREATE TABLE `mq_message` ( 
    `message_id` char(32) NOT NULL, 
    `content` text, 
    `to_exchane` varchar(255) DEFAULT NULL, 
    `routing_key` varchar(255) DEFAULT NULL, 
    `class_type` varchar(255) DEFAULT NULL, 
    `message_status` int(1) DEFAULT '0' COMMENT '0-新建 1-已发送 2-错误抵达 3-已抵达', 		`create_time` datetime DEFAULT NULL, 
    `update_time` datetime DEFAULT NULL, 
    PRIMARY KEY (`message_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

分布式解决方案 seata的使用

springcloud alibaba seata 官方文档

https://seata.io/zh-cn/docs/overview/what-is-seata.html

使用步骤

创建 UNDO_LOG 表

seata AT 模式需要 UNDO_LOG 表

-- 注意此处0.3.0+ 增加唯一索引 ux_undo_log
CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

启动Seata Server服务
- 从 https://github.com/seata/seata/releases ,下载服务器 ( seata - server )软件包

项目整合

引入依赖

<dependency>
		<groupId>com.alibaba.cloud</groupId>
		<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>
        
// 根据引入依赖中 seata-all-1.3.0 版本确定seata-server版本

解压-配置conf-启动服务
- 修改 registry.conf文件中 registry . type = “nacos” , 并配置nacos 连接地址
- 修改 registry.conf文件中 config . type = “nacos” ,并创建配置(将conf文件下的file.conf文件可以全部搬到nacos配置中心)

想要所有用到分布式事务的微服务使用 srata ,要使用 DataSourceProxy代理自己的数据源

每个微服务都必须导入

@Configuration
public class MySeataConfig {

    @Autowired
    DataSourceProperties dataSourceProperties;


    @Bean
    public DataSource dataSource(DataSourceProperties dataSourceProperties){
        HikariDataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
        if (StringUtils.hasText(dataSourceProperties.getName())) {
            dataSource.setPoolName(dataSourceProperties.getName());
        }
        return new DataSourceProxy(dataSource);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

- 在方法上加入 @GlobalTransactional 注解,开启分布式事务

#### **`注意`**

#### 坑：

```java
// 报错信息
ERROR 8384 --- [           main] i.s.c.r.netty.NettyClientChannelManager  : Failed to get available servers: endpoint format should like ip:port

java.lang.IllegalArgumentException: endpoint format should like ip:port

需要配置

service {
  #vgroup->rgroup
  vgroupMapping.order-service-seata-service-group = "default"
  #only support single node
  default.grouplist = "127.0.0.1:8091"
  #degrade current not support
  enableDegrade = false
  #disable
  disable = false
  #unit ms,s,m,h,d represents milliseconds, seconds, minutes, hours, days, default permanent
  max.commit.retry.timeout = "-1"
  max.rollback.retry.timeout = "-1"
}

启动多个项目时还是可能有问题，需要统一指定 tx-service-group ，根据官方文档，可以通过 application.yml 中添加如下配置

spring:
  cloud:
    alibaba:
      seata:
        tx-service-group: seven-seata-service-group

注意: 默认下载是没有service这个配置的.需要手动引入,文档地址:https://github.com/seata/seata-samples/blob/master/doc/quick-integration-with-spring-cloud.md

注意

seata部署到服务器端,需要在yml配置服务器地址,才能连接的上

spring:
  application:
    name: myapp
    
seata:
  service:
    grouplist: ## 这是一个list,可以配置多个
      - 192.168.56.101:8091