本地事务,也就是传统的单机事务。在传统数据库事务中,必须要满足四个原则:
分布式事务:在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。
分布式事务,就是指不是在单个服务或单个数据库架构下,产生的事务,例如:
在数据库水平拆分、服务垂直拆分之后,一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例,包括下面几个行为:
完成上面的操作需要访问三个不同的微服务和三个不同的数据库。
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务,可以保证ACID原则。
但是当我们把三件事情看做一个"业务",要满足保证“业务”的原子性,要么所有操作全部成功,要么全部失败,不允许出现部分成功部分失败的现象,这就是分布式系统下的事务了。
此时ACID难以满足,这是分布式事务要解决的问题
我们通过一个案例来演示分布式事务的问题:
1)创建数据库,名为seata_demo
,然后导入课前资料提供的SQL
文件:
2)导入课前资料提供的微服务:
微服务结构如下:
其中:
seata-demo
:父工程,负责管理项目依赖
account-service
:账户服务,负责管理用户的资金账户。提供扣减余额的接口storage-service
:库存服务,负责管理商品库存。提供扣减库存的接口order-service
:订单服务,负责管理订单。创建订单时,需要调用account-service
和storage-service
3)启动nacos
、所有微服务
4)测试下单功能,发出Post
请求:
请求如下:
curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'
如图:
测试发现,当库存不足时,如果余额已经扣减,并不会回滚,出现了分布式事务问题。
解决分布式事务问题,需要一些分布式系统的基础知识作为理论指导。
1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标。
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance (分区容错性)
它们的第一个字母分别是 C、A、P。
Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
比如现在包含两个节点,其中的初始数据是一致的:
当我们修改其中一个节点的数据时,两者的数据产生了差异:
要想保住一致性,就必须实现node01
到 node02
的数据 同步:
Availability (可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
如图,有三个节点的集群,访问任何一个都可以及时得到响应:
当有部分节点因为网络故障或其它原因无法访问时,代表节点不可用:
Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务
在分布式系统中,系统间的网络不能100%保证健康,一定会有故障的时候,而服务有必须对外保证服务。因此Partition Tolerance【分区容错】不可避免。
当节点接收到新的数据变更时,就会出现问题了
如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。
如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。
也就是说,在P一定会出现的情况下,A和C之间只能实现一个。
BASE
理论是对CAP
的一种解决思路,包含三个思想:
Basically Available
(基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。Soft State
(软状态): 在一定时间内,允许出现中间状态,比如临时的不一致状态。Eventually Consistent
(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。 分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP
定理和BASE
理论,有两种解决思路:
AP模式
:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
CP模式
:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
但不管是哪一种模式,都需要在子系统事务之间互相通讯,协调事务状态,也就是需要一个 事务协调者(TC):
这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。
Seata
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。
官网地址:http://seata.io/,其中的文档、播客中提供了大量的使用说明、源码分析。
Seata事务管理中有三个重要的角色:
TC (Transaction Coordinator) - 事务协调者: 维护全局和分支事务的状态,协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器: 定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器: 管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚 。
整体的架构如图:
Seata
基于上述架构提供了四种不同的分布式事务解决方案:
XA模式
:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入TCC模式
:最终一致的分阶段事务模式,有业务侵入AT模式
:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式SAGA模式
:长事务模式,有业务侵入无论哪种方案,都离不开TC
,也就是事务的协调者。
参考课前资料提供的文档《 seata的部署和集成.md 》:
https://editor.csdn.net/md?articleId=128410730
Seata
【重要】我们以order-service
为例来演示。
实际中每个微服务都要集成一遍Seata
,参与全局事务的每个微服务都要做这个动作;
首先,在order-service
中引入依赖:
com.alibaba.cloud spring-cloud-starter-alibaba-seata seata-spring-boot-starter io.seata
io.seata seata-spring-boot-starter ${seata.version}
在order-service
中的application.yml
中,配置TC
服务信息,通过注册中心nacos
,结合服务名称获取TC
地址:
下面的是要根据自己的实际来更改的
group: DEFAULT_GROUP # 分组,默认是DEFAULT_GROUP ,与nacos浏览器显示的是一样的application: seata-tc-server # seata服务名称 ,与部署TC服务时是一样的seata-demo: SH #将seata-demo映射到SH集群
seata:registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址# 参考tc服务自己的registry.conf中的配置;# 包括:地址、namespace、group、application-name 、clustertype: nacos # 注册中心类型 nacosnacos: # tcserver-addr: 127.0.0.1:8848 # nacos地址namespace: "" # namespace,默认为空,空就是publicgroup: DEFAULT_GROUP # 分组,默认是DEFAULT_GROUP ,与nacos浏览器显示的是一样的application: seata-tc-server # seata服务名称 ,与部署TC服务时是一样的username: nacospassword: nacostx-service-group: seata-demo # 事务组名称;根据这个获取tc服务的cluster(集群)名称service:vgroup-mapping: # 事务组与cluster的映射关系seata-demo: SH #将seata-demo映射到SH集群
微服务如何根据这些配置寻找TC的地址呢?
我们知道注册到Nacos
中的微服务,确定一个具体实例需要四个信息:
namespace
:命名空间group
:分组application
:服务名cluster
:集群名以上四个信息,在刚才的yaml文件中都能找到:
namespace
为空,就是默认的public
结合起来,TC服务的信息就是:public@DEFAULT_GROUP@seata-tc-server@SH
,这样就能确定TC服务集群了。然后就可以去Nacos
拉取对应的实例信息了。
其它两个微服务也都参考order-service
的步骤来做,完全一样。
下面我们就一起学习下Seata中的四种不同的事务模式。
XA
规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,XA 规范 描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。
XA是规范,目前主流数据库都实现了这种规范,实现的原理都是基于两阶段提交。
正常情况:
异常情况:
一阶段:
二阶段:
Seata
对原始的XA模式做了简单的封装和改造,以适应自己的事务模型,基本架构如图:
RM
一阶段的工作:
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC
二阶段的工作:
RM
二阶段的工作:
XA
模式的优点是什么?
XA
模式的缺点是什么?
XA
模式 【重要】Seata
的starter
已经完成了XA
模式的自动装配,实现非常简单,步骤如下:
1)修改application.yml
文件(每个参与事务的微服务),开启XA模式:
seata:data-source-proxy-mode: XA
2)给发起全局事务的入口方法添加@GlobalTransactional
注解:
本例中是OrderServiceImpl
中的create
方法.
3)重启服务并测试
重启order-service
等每个微服务,再次测试,发现无论怎样,三个微服务都能成功回滚。
AT模式同样是分阶段提交的事务模型,不过弥补了XA模型中资源锁定周期过长的缺陷。
基本流程图:
阶段一RM
的工作:
undo-log
(数据快照)阶段二提交时RM的工作:
undo-log
即可阶段二回滚时RM
的工作:
undo-log
恢复数据到更新前我们用一个真实的业务来梳理下AT模式的原理。
比如,现在又一个数据库表,记录用户余额:
id | money |
---|---|
1 | 100 |
其中一个分支业务要执行的SQL
为:
update tb_account set money = money - 10 where id = 1
AT模式下,当前分支事务执行流程如下:
一阶段:
1)TM发起并注册全局事务到TC
2)TM调用分支事务
3)分支事务准备执行业务SQL
4)RM拦截业务SQL,根据where条件查询原始数据,形成快照。
{"id": 1, "money": 100
}
5)RM执行业务SQL,提交本地事务,释放数据库锁。此时 money = 90
6)RM报告本地事务状态给TC
二阶段:
1)TM通知TC事务结束
2)TC检查分支事务状态
a)如果都成功,则立即删除快照
b)如果有分支事务失败,需要回滚。读取快照数据({"id": 1, "money": 100}
),将快照恢复到数据库。此时数据库再次恢复为100
流程图:
简述AT
模式与XA
模式最大的区别是什么?
在多线程并发访问AT模式的分布式事务时,有可能出现脏写问题,如图:
解决思路就是引入了全局锁的概念。在释放DB锁
(数据库锁)之前,先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
实际还可能存在见缝插针的问题:
解决办法:使用了两个快照:更新前的快照、更新后的快照,如果出现问题就会申请人工介入;
AT模式的优点:
AT模式的缺点:
AT模式中的快照生成、回滚等动作都是由框架自动完成,没有任何代码侵入,因此实现非常简单。
只不过,AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
【需要两张表分别记录全局锁和数据快照,这两张表分别在不同的数据库中】
1)导入数据库表,记录全局锁
导入课前资料提供的Sql文件:seata-at.sql
,其中 lock_table
(全局锁)导入到TC服务关联的数据库seata
, undo_log
(快照)表导入到微服务关联的数据库seata_demo
:
DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table` (`row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,`xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,`transaction_id` bigint(20) NULL DEFAULT NULL,`branch_id` bigint(20) NOT NULL,`resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,`table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,`pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,`gmt_create` datetime NULL DEFAULT NULL,`gmt_modified` datetime NULL DEFAULT NULL,PRIMARY KEY (`row_key`) USING BTREE,INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log` (`branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',`xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',`context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',`rollback_info` longblob NOT NULL COMMENT 'rollback info',`log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',`log_created` datetime(6) NOT NULL COMMENT 'create datetime',`log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;
2)修改application.yml
文件(每个参与事务的微服务),将事务模式修改为AT模式即可:
seata:data-source-proxy-mode: AT # 默认就是AT
3)重启所有有关的微服务并测试
重启order-service
等每个微服务,再次测试,发现无论怎样,三个微服务都能成功回滚。
注意: 并不是所有的微服务都适合使用TCC模式,可以一部分使用AT一部分使用TCC;AT和TCC可以混用;
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:
Try
:资源的检测和预留;Confirm
:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。Cancel
:预留资源释放,可以理解为try的反向操作。举例,一个扣减用户余额的业务。假设账户A原来余额是100,需要余额扣减30元。
阶段一( Try ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30
初识余额:
余额充足,可以冻结:
此时,总金额 = 冻结金额 + 可用金额,数量依然是100不变。事务直接提交无需等待其它事务。
阶段二(Confirm):假如要提交(Confirm),则冻结金额扣减30
确认可以提交,不过之前可用金额已经扣减过了,这里只要清除冻结金额就好啦:
此时,总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元
阶段二(Canncel):如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30
需要回滚,那么就要释放冻结金额,恢复可用金额:
Seata 中的 TCC模型 依然延续之前的事务架构,如图:
TCC模式的每个阶段是做什么的?
Try
:资源检查和预留Confirm
:业务执行和提交Cancel
:预留资源的释放TCC的优点是什么?
TCC的缺点是什么?【消耗人】
当某分支事务的try
阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel
操作。在未执行try
操作时先执行了cancel
操作,这时cancel
不能做回滚,就是空回滚。
如图:
执行cancel
操作时,应当判断try
是否已经执行,如果尚未执行,则应该空回滚。
对于已经空回滚的业务,之前被阻塞的try操作恢复(但是它恢复的太迟了,整个全局事务已经结束了),继续执行try,就永远不可能confirm或cancel ,事务一直处于中间状态,这就是业务悬挂。
执行try
操作时,应当判断cancel
是否已经执行过了,如果已经执行,应当阻止空回滚后的try
操作,避免悬挂
注意: 并不是所有的微服务都适合使用TCC模式,可以一部分使用AT一部分使用TCC;AT和TCC可以混用;
解决空回滚和业务悬挂问题,必须要记录当前事务状态,是在try
、还是cancel
?
为了实现空回滚、防止业务悬挂,以及幂等性要求。我们必须在数据库记录冻结金额的同时,记录当前事务id和执行状态,为此我们设计了一张表:
在微服务的数据库seata_demo
中执行创建
CREATE TABLE `account_freeze_tbl` (`xid` varchar(128) NOT NULL,`user_id` varchar(255) DEFAULT NULL COMMENT '用户id',`freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额',`state` int(1) DEFAULT NULL COMMENT '事务状态,0:try,1:confirm,2:cancel',PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;
其中:
xid
:是全局事务idfreeze_money
:用来记录用户冻结金额state
:用来记录事务状态那此时,我们的业务该怎么做呢?
account_freeze
表account
表可用金额account_freeze
表的冻结记录account_freeze
表,冻结金额为0,state为2account
表,恢复可用金额cancel
业务中,根据xid查询account_freeze_tbl
表,如果为null则说明try还没做,需要空回滚try
业务中,根据xid
查询account_freeze_tbl
表 ,如果已经存在则证明Cancel已经执行,拒绝执行try业务接下来,我们改造account-service
,利用TCC
实现余额扣减功能。
TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明,
我们在account-service
(账户微服务)项目中的cn.itcast.account.service
包中新建一个接口,声明TCC三个接口:
package cn.itcast.account.service;@LocalTCC
public interface AccountTCCService {@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")//给参数加注解(在deduct方法中@BusinessActionContextParameter)void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,@BusinessActionContextParameter(paramName = "money")int money);boolean confirm(BusinessActionContext ctx); //BusinessActionContext ct上下文对象,可以获取当前的事务信息和参数信息,前提是要给参数加注解(在deduct方法中@BusinessActionContextParameter)boolean cancel(BusinessActionContext ctx);//BusinessActionContext ct上下文对象,可以获取当前的事务信息和参数信息
}
账户实体类:
记录当前事务id和执行状态的实体类,对应上面创建的account_freeze_tbl
数据表
mapper
操作数据表操作记录当前事务id和执行状态数据表,对应上面创建的account_freeze_tbl
数据表:
操作账户数据表:
在account-service
服务中的cn.itcast.account.service.impl
包下新建一个类,实现TCC
业务:
package cn.itcast.account.service.impl;@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {@Autowiredprivate AccountMapper accountMapper;//下面Try方法要操作两张表,把两张表的mapper层的方法注入进来@Autowiredprivate AccountFreezeMapper freezeMapper; //下面Try方法要操作两张表,把两张表的mapper层的方法注入进来@Override@Transactional //下面一抛异常,走到这里回滚public void deduct(String userId, int money) { //Try方法// 0.获取事务idString xid = RootContext.getXID(); //拿到全局事务id// 1.扣减可用余额accountMapper.deduct(userId, money); //调用mapper层的操作数据库方法// 2.记录冻结金额,事务状态AccountFreeze freeze = new AccountFreeze(); //AccountFreeze的实体类;freeze.setUserId(userId);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freeze.setXid(xid); //使用 // 0.获取事务idfreezeMapper.insert(freeze); //调用mapper层的操作数据库方法}@Overridepublic boolean confirm(BusinessActionContext ctx) {// 1.获取事务idString xid = ctx.getXid();// 2.根据id删除冻结记录int count = freezeMapper.deleteById(xid); //调用mapper层的操作数据库方法return count == 1;}@Overridepublic boolean cancel(BusinessActionContext ctx) {// 0.查询冻结记录String xid = ctx.getXid();AccountFreeze freeze = freezeMapper.selectById(xid); //得到freeze对象// 1.恢复可用余额//参数是用户id和金额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());// 2.将冻结金额清零,状态改为CANCELfreeze.setFreezeMoney(0); //冻结金额清零freeze.setState(AccountFreeze.State.CANCEL); //修改状态为CANCELint count = freezeMapper.updateById(freeze); //调用mapper层的操作数据库方法return count == 1;}
}
Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。
其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。
Seata官网对于Saga的指南:https://seata.io/zh-cn/docs/user/saga.html
在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会去退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。
Saga也分为两个阶段:
优点:
缺点:
我们从以下几个方面来对比四种实现:
如图:
Seata
的TC
服务作为分布式事务核心,一定要保证集群的高可用性。
搭建TC服务集群非常简单,启动多个TC服务,注册到nacos即可。
但集群并不能确保100%安全,万一集群所在机房故障怎么办?所以如果要求较高,一般都会做异地多机房容灾。
比如一个TC集群在上海,另一个TC集群在杭州:
微服务基于事务组(tx-service-group)与TC集群的映射关系,来查找当前应该使用哪个TC集群。当SH集群故障时,只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。
具体实现请参考课前资料提供的文档《seata的部署和集成.md》:
第三章节:
直接参考https://editor.csdn.net/md?articleId=128410730即可
【# 叁、TC服务的高可用和异地容灾】