文章目录
Seata分布式事务
简介
如果一个事务中调用了外部服务,这就是分布式事务
事务的隔离级别
Read uncommitted(读未提交):一个事务可以读取另一个未提交事务的数据。
举例:数据库中字段price为1000,A修改数据库为1500,此时B查看price为1500,结果A回滚了事务,数据库中数据还是1000。
结果:B出现脏读
Read committed(读已提交):一个事务要等另一个事务提交后才能读取数据。(针对的是UPDATE操作)
举例:数据库中字段price为1000,A查看数据为1000,告诉了C,此时B将数据进行了修改,修改为1600,当C去查看price为1600。
结果:出现了不可重复读现象
Repeatable read(可重复读):读取多条记录时,同一事务两次读取的数据条数不一致。在一条记录上的操作是,不能读取已由其它事务修改了但是未提交的行,其它任何事务也不能修改在当前事务完成之前由当前事务读取的数据。
举例:数据库中只有一条记录,当A查看时只有一条,A告诉C,此时B去数据库插入一条数据,C去查看时有两条。
结果:出现了幻读现象
Serializable (序列化):事务串行化顺序执行,可以避免脏读、不可重复读与幻读。
MYSQL隔离级别:可重复读
Oracle隔离级别:读已提交
事务传播行为
事务的传播行为:想要发生传播就一定要有两个以上的物体,而这里指的是两个方法都要在事务中进行,当一个事务方法A调用另一个事务方法B时,另一个事务方法B该如何运行。
Spring一共定义了7种事务传播行为(事务方法B该如何运行):
本地事务@Transactional+传播行为
//事务使用代理对象来控制
@Transactional(timeout = 10)
public void A(){
//如果abc在同一个class类中,那么b,c做任何设置都没作用,都是和A公用一个事务,此时不生效,要使用代理
B();
C();
}
// 此时如果A有事务,就使用A的事务,A没有事务,就新建事务
@Transactional(propagation = Propagation.REQUIRED,timeout = 5)
public void B(){
}
// 不和A公用一个事务,新建事务
@Transactional(propagation = Propagation.REQUIRES_NEW,timeout = 20)
public void C(){
}
/*本地事务失效问题:
同一个对象内事务方法互调默认失效,原因 绕过了代理对象,事务使用代理对象来控制的
解决:使用代理对象来调用事务方法
针对:本类方法互调使用事务
1)引入spring-boot-starter-aop;引入aspectj
2)主启动类@EnableAspectJAutoProxy(exposeProxy = true);
开启aspectj动态代理功能。以后所有的动态代理都是aspectj创建的(即使没有接口也可以创建动态代理)。
exposeProxy = true:对外暴露代理对象
3)用代理对象本类互调
使用:OrderService orderService = AopContext.currentProxy(); orderService.b(); orderService.c();
*/
@Transactional(timeout = 10)
public void A(){
//b,c做任何设置都没作用,都是和A公用一个事务,此时不生效,要使用代理
OrderServiceImpl orderService = (OrderServiceImpl) AopContext.currentProxy();
orderService.B();
orderService.C();
}
分布式事务
分布式系统之所以叫分布式,是因为提供服务的各个节点分布在不同机器上,相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务,网络因素成为了分布式事务的考量标准之一。
分布式事务产生的场景
分布式系统会把一个应用系统拆分为可独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务,例如用户注册送积分事务、创建订单减库存事务,银行转账事务等都是分布式事务。
分布式经常出现的异常:机器宕机,网络异常,消息丢失,消息乱序,数据错误,不可靠的TCP,存储数据丢失。。。
CAP理论
C:Consistency(强一致性)
A:Availability(可用性)
P:Partition tolerance(分区容错性)
CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP-满足一致性,分区容错的系统,通常性能不是特别高。
AP-满足可用性,分区容错的系统,通常对一致性要求略低一些。
在当前分布式的大环境中,P已经成为必不可少!!!
注意:CAP不可能三者同时兼顾,甚至连CA都不可能会有!(CA最多只有在本地运行可以做到)
当前主流技术对CAP的使用:必然会接触到分布式系统,例如:zookeeper就是使用CP原则,eureka使用AP原则
raft算法:https://www.bilibili.com/video/BV1np4y1C7Yf?p=286
分布式事务常见解决方案
针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。
2PC(两阶段提交,刚性事务)
数据库支持的2PC【二阶段提交】,又被称为XA Transactions
Mysql从5.5开始支持,SQL Server 2005开始支持,Oracle 7开始支持。
其中XA是一个两阶段提交协议:
第一阶段为 准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时,向transaction manager报告已准备就绪。
第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready后,向所有参与者发送commit命令。
其中如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚他们在此事务中的那部分信息
优缺点:
- XA协议比较简单,商业数据库使用,使用分布式事务的成本低。
- XA性能不理想,特别是交易下单链路,往往并发量很高,XA无法满足高并发场景。
- XA在商业数据库支持比较理想,在mysql数据库支持不太理想,MYSQL的XA实现没有记录prepare阶段日志,主备切换导致主库和备库数据不一致。
- 也有3PC,引入超时机制(无论协调者还是参与者,在向对方发送请求后,若长时间未收到回应则做出相应处理)
TCC(柔性事务)
**刚性事务:**遵循ACID原则,强一致性。
**柔性事务:**遵循BASE理论,最终一致性。
TCC 模式,不依赖于底层数据资源的事务支持:
**一阶段 prepare 行为:**调用 自定义 的 prepare 逻辑。
**二阶段 commit 行为:**调用 自定义 的 commit 逻辑。
**三阶段 rollback 行为:**调用 自定义 的 rollback 逻辑。
所谓 TCC 模式,是指支持把 自定义 的分支事务纳入到全局事务的管理中。
可靠消息最终一致性(柔性事务)
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,**事务参与方(消息消费者)一定能够接收消息并处理事务成功,**此方案强调的是只要消息发给事务参与方最终事务要达到一致。
最大努力通知(柔性事务)
按规律进行通知,不保证数据一定能通知成功,但是会提供可查询操作接口进行核对。
用途:用在与第三方进行通讯时,如:微信支付宝支付后的支付结果通知。结合MQ进行实现,通过MQ发送http请求,设置最大通知次数,次数到达就不通知。
案例:银行通知,商户通知,支付宝支付成功异步回调。
Seata环境准备
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。
创建 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