1.事务的ACID原则

原子性:事务中的所有操作,要么全部成功,要么全部失败
一致性:要保证数据库内部完整性约束、声明性约束
隔离性:对同一资源操作的事务不能同时发生
持久性:对数据库做的一切修改将永久保存,不管是否出现故障

2.分布式服务案例

微服务下单业务,下单时会调用订单服务,创建订单并写入数据库。然后订单服务调用账户和库存服务:
•账户服务负责扣减用户余额
•库存服务负责扣减商品库存
image.png

1.创建数据库,名为seata_demo,然后导入课前资料提供的SQL文件:
image.png
image.png
在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。
image.png

3.CAP定理

1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标:
•Consistency(一致性)
•Availability(可用性)
•Partition tolerance (分区容错性)
Eric Brewer 说,分布式系统无法同时满足这三个指标。
这个结论就叫做 CAP 定理。
image.png

3.1一致性

用户访问分布式系统中的任意节点,得到的数据必须一致
image.png

3.2可用性

用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝
image.png

3.3分区容错

Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务
image.png

3.4总结

分布式系统节点通过网络连接,一定会出现分区问题(P)
当分区出现时,系统的一致性(C)和可用性(A)就无法同时满足

4.BASE理论

4.1概述

BASE理论是对CAP的一种解决思路,包含三个思想:
Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
Eventually Consistent(最终一致性)虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论:
•AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
•CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。

4.2分布式事务模型

•全局事务:整个分布式事务
•分支事务:分布式事务中包含的每个子系统的事务
•最终一致思想:各分支事务分别执行并提交,如果有不一致的情况,再想办法恢复数据
•强一致思想:各分支事务执行完业务不要提交,等待彼此结果。而后统一提交或回滚

5.初识Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。

Seata事务管理中有三个重要的角色:
TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
image.png



6.部署Seata的tc-server

6.1.下载

首先我们要下载seata-server包,地址在http://seata.io/zh-cn/blog/download.html

6.2.解压

在非中文目录解压缩这个zip包,其目录结构如下:

image.png

6.3.修改配置

修改conf目录下的registry.conf文件:

image.png

内容如下:

  1. registry {
  2. # tc服务的注册中心类,这里选择nacos,也可以是eureka、zookeeper等
  3. type = "nacos"
  4. nacos {
  5. # seata tc 服务注册到 nacos的服务名称,可以自定义
  6. application = "seata-tc-server"
  7. serverAddr = "127.0.0.1:8848"
  8. group = "DEFAULT_GROUP"
  9. namespace = ""
  10. cluster = "SH"
  11. username = "nacos"
  12. password = "nacos"
  13. }
  14. }
  15. config {
  16. # 读取tc服务端的配置文件的方式,这里是从nacos配置中心读取,这样如果tc是集群,可以共享配置
  17. type = "nacos"
  18. # 配置nacos地址等信息
  19. nacos {
  20. serverAddr = "127.0.0.1:8848"
  21. namespace = ""
  22. group = "SEATA_GROUP"
  23. username = "nacos"
  24. password = "nacos"
  25. dataId = "seataServer.properties"
  26. }
  27. }

6.4.在nacos添加配置

特别注意,为了让tc服务的集群可以共享配置,我们选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。

格式如下:

image.png

配置内容如下:

  1. # 数据存储方式,db代表数据库
  2. store.mode=db
  3. store.db.datasource=druid
  4. store.db.dbType=mysql
  5. store.db.driverClassName=com.mysql.jdbc.Driver
  6. store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
  7. store.db.user=root
  8. store.db.password=123456
  9. store.db.minConn=5
  10. store.db.maxConn=30
  11. store.db.globalTable=global_table
  12. store.db.branchTable=branch_table
  13. store.db.queryLimit=100
  14. store.db.lockTable=lock_table
  15. store.db.maxWait=5000
  16. # 事务、日志等配置
  17. server.recovery.committingRetryPeriod=1000
  18. server.recovery.asynCommittingRetryPeriod=1000
  19. server.recovery.rollbackingRetryPeriod=1000
  20. server.recovery.timeoutRetryPeriod=1000
  21. server.maxCommitRetryTimeout=-1
  22. server.maxRollbackRetryTimeout=-1
  23. server.rollbackRetryTimeoutUnlockEnable=false
  24. server.undo.logSaveDays=7
  25. server.undo.logDeletePeriod=86400000
  26. # 客户端与服务端传输方式
  27. transport.serialization=seata
  28. transport.compressor=none
  29. # 关闭metrics功能,提高性能
  30. metrics.enabled=false
  31. metrics.registryType=compact
  32. metrics.exporterList=prometheus
  33. metrics.exporterPrometheusPort=9898

其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。

6.5.创建数据库表

特别注意:tc服务在管理分布式事务时,需要记录事务相关数据到数据库中,你需要提前创建好这些表。

这些表主要记录全局事务、分支事务、全局锁信息:

  1. SET NAMES utf8mb4;
  2. SET FOREIGN_KEY_CHECKS = 0;
  3. -- ----------------------------
  4. -- 分支事务表
  5. -- ----------------------------
  6. DROP TABLE IF EXISTS `branch_table`;
  7. CREATE TABLE `branch_table` (
  8. `branch_id` bigint(20) NOT NULL,
  9. `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  10. `transaction_id` bigint(20) NULL DEFAULT NULL,
  11. `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  12. `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  13. `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  14. `status` tinyint(4) NULL DEFAULT NULL,
  15. `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  16. `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  17. `gmt_create` datetime(6) NULL DEFAULT NULL,
  18. `gmt_modified` datetime(6) NULL DEFAULT NULL,
  19. PRIMARY KEY (`branch_id`) USING BTREE,
  20. INDEX `idx_xid`(`xid`) USING BTREE
  21. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
  22. -- ----------------------------
  23. -- 全局事务表
  24. -- ----------------------------
  25. DROP TABLE IF EXISTS `global_table`;
  26. CREATE TABLE `global_table` (
  27. `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  28. `transaction_id` bigint(20) NULL DEFAULT NULL,
  29. `status` tinyint(4) NOT NULL,
  30. `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  31. `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  32. `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  33. `timeout` int(11) NULL DEFAULT NULL,
  34. `begin_time` bigint(20) NULL DEFAULT NULL,
  35. `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  36. `gmt_create` datetime NULL DEFAULT NULL,
  37. `gmt_modified` datetime NULL DEFAULT NULL,
  38. PRIMARY KEY (`xid`) USING BTREE,
  39. INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
  40. INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
  41. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
  42. SET FOREIGN_KEY_CHECKS = 1;

6.6启动TC服务

进入bin目录,运行其中的seata-server.bat即可:

image.png

启动成功后,seata-server应该已经注册到nacos注册中心了。

打开浏览器,访问nacos地址:http://localhost:8848,然后进入服务列表页面,可以看到seata-tc-server的信息:
image.png

7.微服务集成seata

7.1.引入依赖

首先,我们需要在微服务中引入seata依赖:

  1. <dependency>
  2. <groupId>com.alibaba.cloud</groupId>
  3. <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  4. <exclusions>
  5. <!--版本较低,1.3.0,因此排除-->
  6. <exclusion>
  7. <artifactId>seata-spring-boot-starter</artifactId>
  8. <groupId>io.seata</groupId>
  9. </exclusion>
  10. </exclusions>
  11. </dependency>
  12. <!--seata starter 采用1.4.2版本-->
  13. <dependency>
  14. <groupId>io.seata</groupId>
  15. <artifactId>seata-spring-boot-starter</artifactId>
  16. <version>${seata.version}</version>
  17. </dependency>

7.2.修改配置文件

需要修改application.yml文件,添加一些配置:

  1. seata:
  2. registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址
  3. # 参考tc服务自己的registry.conf中的配置
  4. type: nacos
  5. nacos: # tc
  6. server-addr: 127.0.0.1:8848
  7. namespace: ""
  8. group: DEFAULT_GROUP
  9. application: seata-tc-server # tc服务在nacos中的服务名称
  10. cluster: SH
  11. tx-service-group: seata-demo # 事务组,根据这个获取tc服务的cluster名称
  12. service:
  13. vgroup-mapping: # 事务组与TC服务cluster的映射关系
  14. seata-demo: SH

8.XA模式

XA 规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,
XA 规范描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。
image.png

8.1优缺点

XA模式的优点是什么?
•事务的强一致性,满足ACID原则。
•常用数据库都支持,实现简单,并且没有代码侵入
XA模式的缺点是什么?
•因为一阶段需要锁定数据库资源,等待二阶段结束才释放,性能较差
•依赖关系型数据库实现事务

8.2实现XA模式

Seata的starter已经完成了XA模式的自动装配,实现非常简单,步骤如下:
1.修改application.yml文件(每个参与事务的微服务),开启XA模式:

  1. seata:
  2. data-source-proxy-mode: XA # 开启数据源代理的XA模式

2 给发起全局事务的入口方法添加@GlobalTransactional注解

  1. @Override
  2. @GlobalTransactional
  3. public Long create(Order order) {
  4. // 创建订单
  5. orderMapper.insert(order);
  6. // 扣余额 ...略
  7. // 扣减库存...略
  8. return order.getId();
  9. }

9.AT模式

AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。
image.png
简述AT模式与XA模式最大的区别是什么?
•XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
•XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。
•XA模式强一致;AT模式最终一致

9.1AT模式的优缺点:

AT模式的优点:
•一阶段完成直接提交事务,释放数据库资源,性能比较好
•利用全局锁实现读写隔离
•没有代码侵入,框架自动完成回滚和提交
AT模式的缺点:
•两阶段之间属于软状态,属于最终一致
•框架的快照功能会影响性能,但比XA模式要好很多

9.2实现AT模式

1.导入提供的Sql文件:seata-at.sql
其中lock_table导入到TC服务关联的数据库,undo_log表导入到微服务关联的数据库。
image.png
2.修改application.yml文件,将事务模式修改为AT模式即可:

  1. seata:
  2. data-source-proxy-mode: AT# 开启数据源代理的AT模式

10.四种模式对比

XA AT TCC SAGA
一致性 强一致 弱一致 弱一致 最终一致
隔离性 完全隔离 基于全局锁隔离 基于资源预留隔离 无隔离
代码侵入 有,要编写三个接口 有,要编写状态机和补偿业务
性能 非常好 非常好
场景 对一致性、隔离性有高要求的业务 基于关系型数据库的大多数分布式事务场景都可以 •对性能要求较高的事务。
•有非关系型数据库要参与的事务。
•业务流程长、业务流程多
•参与者包含其它公司或遗留系统服务,无法提供 TCC 模式要求的三个接口