上一篇：单业务的一致性（CAP中的C【Consistency】）-02CAP介绍

1.使用Seata做强一致性分布式事务

还是我们开头提出的问题：如何保证1.1、1.2、1.3要么同时成功，要么同时失败，本小节，使用alibaba seata作为分布式事务的解决方案，达到这个目的。

2.Seata的AT模型介绍

seata中文官网：http://seata.io/zh-cn/docs/user/quickstart.html
可以直接官网查看，这里作为搬运工。

2.1Seata 是什么?

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

此处仅讨论其AT模式，AT模式本质上也是2PC模式。

2.2使用前提?

1.基于支持本地 ACID 事务的关系型数据库。
2.Java 应用，通过 JDBC 访问数据库。

2.3整体机制?

两阶段提交协议的演变：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段：
提交异步化，非常快速地完成。
回滚通过一阶段的回滚日志进行反向补偿。使用第一阶段的事务日志。undo.log

2.4写隔离

2.4.1正常提交

一阶段本地事务提交前，需要确保先拿到全局锁 。拿不到全局锁 ，不能提交本地事务。
拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

下面的实例特别好：
两个全局事务 tx1 和 tx2，分别对 A 表的 m 字段进行更新操作，m 的初始值 1000。

• tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁 ，本地提交，释放本地锁。
• tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁 ，tx1全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待全局锁 。
  如下图：
  
• tx1 二阶段全局提交，释放全局锁 。tx2 拿到 全局锁 提交本地事务。

2.4.2回滚提交

• 如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
• 此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
• 因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。

2.4写隔离?

在更新的同时进行查询的过程：

• 在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。
• 如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
  
• SELECT FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。
• 出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

2.5工作机制实例说明AT模式

业务表：product

AT 分支事务的业务逻辑：

update product set name = 'GTS' where name = 'TXC';

2.5.1一阶段

过程：

1.解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
2.查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

select id, name, since from product where name = 'TXC';

得到前镜像：

3.执行业务 SQL：更新这条记录的 name 为 ‘GTS’。
4.查询后镜像：根据前镜像的结果，通过主键定位数据。

select id, name, since from product where id = 1;

5.插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。

{
	"branchId": 641789253,
	"undoItems": [{
		"afterImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "GTS"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"beforeImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "TXC"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"sqlType": "UPDATE"
	}],
	"xid": "xid:xxx"
}

6.提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。（注册时获得锁，锁后的后才会提交本地事务。）
7.本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8.将本地事务提交的结果上报给 TC。

2.5.2二阶段-回滚

1.收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
2.数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。（可以直接覆盖）
3.根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

update product set name = 'TXC' where id = 1;

4.提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

2.5.3二阶段-提交

1.收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2.异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

2.5.4回滚日志表

以 MySQL 为例：

sql:

-- 注意此处0.7.0+ 增加字段 context
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,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

2.Seata的TCC 模式

回顾总览中的描述：一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：

• 一阶段 prepare 行为
• 二阶段 commit 或 rollback 行为
  
  根据两阶段行为模式的不同，我们将分支事务划分为 Automatic (Branch) Transaction Mode (自动事务模型)和 Manual (Branch) Transaction Mode（手动事务模型）.

AT 模式（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。

• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。

• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。
  相应的，TCC 模式，不依赖于底层数据资源的事务支持：

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

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

• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
  所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
  总结一句话：和AT一模一样，只是自己实现。

3.Saga 模式

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

理论基础：Hector & Kenneth 发表论⽂ Sagas （1987）
适用场景：
业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口
优势：
一阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，高吞吐
补偿服务易于实现
缺点：
不保证隔离性

4.官方实例架构

用例
用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：

仓储服务：对给定的商品扣除仓储数量。
订单服务：根据采购需求创建订单。
帐户服务：从用户帐户中扣除余额。

5.官方实例架构SEATA 的分布式交易解决方案

我们只需要使用一个 @GlobalTransactional 注解在业务方法上:

@GlobalTransactional
    public void purchase(String userId, String commodityCode, int orderCount) {
        ......
    }

6.在订单业务的一致性中使用seata的AT保证分布式事务一致性

1.每个需要用到的微服务（此处三个）创建undo_log
这里涉及到三个微服务：订单服务、库存服务、积分服务，这三个数据库中分别创建undo_log表。
2.安装事务协调器TC，seata-server,即seata软件
3.整合项目

• 导入依赖

<!-- common pom.xml中添加，其他引用了common微服务的用到的就不需要再次添加了。
        Seata场景启动器 - 解决分布式事务 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
            <version>2.1.0.RELEASE</version>
        </dependency>

• 加压启动seata-server
  

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

package com.atguigu.gulimall.order.config;

import com.zaxxer.hikari.HikariDataSource;
import io.seata.rm.datasource.DataSourceProxy;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.jdbc.DataSourceProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.util.StringUtils;

import javax.sql.DataSource;

/**
 * @Description SeaTa分布式事务管理的配置bean类，主要是对数据源的配置。
 **/
@Configuration
public class MySeataConfig {

    @Autowired
    DataSourceProperties dataSourceProperties;


    /**
     * 这里抄的是源码中的配置数据源的方式。
     * 参考源码书写。主要是为了使用
     * @param dataSourceProperties
     * @return
     */
   @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);
    }


}

特别注意，此处的数据源代理使用的是seata的代理，这样事务就交由seata管理了。：

import io.seata.rm.datasource.DataSourceProxy;

• 每个微服务均需要导入registry.conf和file.conf
  

• 在我们的业务方法上添加@GlobalTransactional可解决分布式事务问题。

	//点击提交订单按钮的时候，问题来了
	@GlobalTransactionall //seata事务 TM
  	@Transactional //本地事务 RM
    @Override
    public SubmitOrderRespVo submitOrder(OrderSubmitVo orderSubmitVo) {

        
            if (checkValidity() ) {//校验合法性，如果一切合法，则开始提交代码
	                // 1.1把订单保存在订单表中
	                saveOrder(order);
	                
	                // 1.2调用库存服务吧库存减去2
	                R r = wareFeignService.orderLocKStock(orderSubmitVo);
	
					// 1.3调用用积分服务给张三添加800万积分
	               	R r = pointsFeignService.upPoint(orderSubmitVo);
	               	return submitOrderRespVo;
	               	
               }
            } 
        }
    }

• 其他注意点：
  registry.conf和file.conf的配置有些注意点，再次不在赘述，可以使用数据库、或者文件作为存储使用；另外把自己配置进入nacos配置中心。
• 其他注意点 jpa整合https://github.com/seata/seata-samples/tree/master/springcloud-jpa-seata

1. file.conf 的 service.vgroup_mapping 配置必须和spring.application.name一致在 org.springframework.cloud:spring-cloud-starter-alibaba-seata的org.springframework.cloud.alibaba.seata.GlobalTransactionAutoConfiguration类中，默认会使用 ${spring.application.name}-fescar-service-group作为服务名注册到 Seata Server上，如果和file.conf中的配置不一致，会提示 no available server to connect错误
2. 也可以通过配置 spring.cloud.alibaba.seata.tx-service-group修改后缀，但是必须和file.conf中的配置保持一致
   

7总结

1.前面说了那么多其实就是一个注解的事。
2.seata的这种方案在一般场景中会使用到，例如金融it行业，但是在电商中不会使用，因为其中均需要获得锁local Lock 或者GlobleLock，性能低下，下篇介绍更为高效的解决方案：柔性事务-可靠消息+最终一致性。
下一篇地址：订单业务的一致性（CAP中的C【Consistency】）-04使用柔性事务-可靠消息+最终一致性方案

最后

以上就是懵懂口红为你收集整理的订单业务的一致性（CAP中的C【Consistency】）-03使用Seata做强一致性分布式事务1.使用Seata做强一致性分布式事务2.Seata的AT模型介绍2.Seata的TCC 模式3.Saga 模式4.官方实例架构5.官方实例架构SEATA 的分布式交易解决方案6.在订单业务的一致性中使用seata的AT保证分布式事务一致性7总结的全部内容，希望文章能够帮你解决订单业务的一致性（CAP中的C【Consistency】）-03使用Seata做强一致性分布式事务1.使用Seata做强一致性分布式事务2.Seata的AT模型介绍2.Seata的TCC 模式3.Saga 模式4.官方实例架构5.官方实例架构SEATA 的分布式交易解决方案6.在订单业务的一致性中使用seata的AT保证分布式事务一致性7总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。