分布式事务 - XA/TCC/最终一致性解决方案/Seata (原FESCAR)

版权声明 :

本文为博主原创文章,如需转载,请注明出处(https://blog.csdn.net/F1004145107/article/details/86648263)

一、什么是分布式事务

在进入微服务系统之后,给我们带来了很多的方便,同时也有很多的痛点,这里我们不讨论微服务系统在后期逐渐变得'臃肿'的问题,本文主要讨论分布式事务
在以前的系统中,我们将订单、账户等服务写在同一个服务内,用的是同一个本地数据源,本地事务可以保证这俩个操作是同时提交(commit)或者回滚(rollback),但是在微服务系统中,我们将俩个服务单独部署,并且数据源也不是同一个,此时就会有一个问题,订单的事务提交了,但是账户因为异常原因回滚了,此时会造成用户已经成功购买了商品,但是钱并没有扣除,由此可见,分布式事务解决的就是将俩个本地事务当作一个本地事务来处理,一起提交或一起回滚

CAP

在了解分布式事务的解决方案之前我们需要先明白,分布式事务的基本原则
一致性(Consistency) : 在执行完该流程的操作后,所有的更新操作是否能保证整个系统的数据都被更新,保证数据的一致性
可用性(Availability) : 每个操作能够在正常的响应时间内完成,并给客户端返回正常的数据
分区容错性(Partition Tolerance) : 当系统中某个服务宕机之后,任然能满足一和可用性的条件,并且不会影响用户使用

二、现有的分布式事务解决方案

分布式事务的发展

XA - 俩阶段提交协议(业务无侵入)
- 第一阶段 : 事务管理器要求涉及到本次操作流程的所有数据源都执行预提交(preCommit)操作,是或否
- 第二阶段 : 根据第一阶段的返回结果来判断当前所有数据源是全部提交或回滚
- 优点 : 从流程上我们可以看出来,XA保证数据的强一致性,要么一起提交,要么一起回滚
- 缺点
  - 数据库必须提供对XA的支持,例如MySQL 5.7以下的版本
  - 受协议约束,事务资源(数据库连接)的锁定周期较长,而且因为事务资源的管理器是数据库本身,我们无法在应用层做处理,所以就导致了我们很难优化其性能
TCC(侵入业务)
- try : 预留业务资源,对当前系统做校验,检查当前系统是否准备好提交,与XA的preCommit类似
- confirm : 如果try执行成功,则确认执行提交操作
- cancel : 如果try执行失败,则回滚事务,并释放预留资源
- 优点 : 给了开发人员更大的施展空间,方便拓展,与XA一样,在强一致性上保持的不错
- 缺点 : 对业务的侵入性很大,每一个分布式的分支都需要实现try,confirm,cancel操作,如果一旦需要改造,那绝对很让人愤怒
基于消息中间件的最终一致性解决方案(最常见的方式,侵入业务)

我们先介绍第一种,不支持事务的消息队列,例如RabbitMQ
- 方案包括一个生产者,一个消费者,以及一个校验中心和一张存储消息的表
- 生产者 : 在开启本地事务时保存一条数据到消息表中,状态置位未消费,事务提交之后将消息发送到队列中
- 消费者 : 通过订阅队列获取到消息,在消费成功后(事务提交之后)修改消息表中的状态为已消费
- 校验中心 : 校验中心也可以有俩种实现方式
  - 1. 定时扫描消息表,俩种结果,发送失败的,发送失败则重新发送成功但是消费者一直消费失败,设定消费失败次数,到达次数后标记该信息,调用生产者再次发送该消息((重新消费次数可设置)),重新计时,再次失败发送预警信息给开发人员,请求人工干预
    2. 创建一个校验中心队列,生产者在发送消息时同时发送一条到校验中心队列中,校验中心会有一个消费者来进行订阅该队列,拿到消息后将消息表中的状态置为处理中,然后定时扫描消息表,如果发现消息在规定时间内没有被消费成功,则再次将消息发送到消费者订阅的队列中,请求重新消费(重新消费次数可设置),重新计时,再次失败则请求人工干预
  - 以上的俩种方式原理都是一样的,但是第二种需要写更多的代码
- 优点 : 将分布式事务进行拆分成本地事务,避免了分布式事务,实现了最终一致性
- 缺点 : 需要些大量的代码,如果涉及的不够灵活,可能会给后续的开发和拓展带来不好的体验
第二种,支持事务的消息队列,例如RocketMQ
- 在开启本地事务之前先发送一条预处理消息(Prepared,很像MyBatis的防注入的处理方式),然后处理本地事务,处理结束后发送确认消息,此时会有俩种结果
  1. 确认消息发送成功,RocketMQ执行提交或回滚策略,生产者方面的流程结束
  2. 确认消息发送失败,RocketMQ内部会定时扫描直接本地事务消息表,查询到Prepared消息,如果当前Prepared消息没有被确认,则会向生产者确认,RocketMQ执行提交或回滚策略
- 消费者订阅队列消费消息,RocketMQ会一直监测消息是否被成功消费,如果失败则一直重试,达到指定次数后申请人工干预
不难发现,其实支持事务的消息队列也好,不支持的也好,解决分布式的方式很类似,都是将分布式事务分为俩个本地事务来处理
GTS / Seata (原FESCAR)(阿里开源的分布式事务解决方案,无业务侵入)

在介绍FESCAR之前我们先来介绍一下FESCAR与XA

从上图架构层次我们可以看到,XA的RM(事务管理器)在数据库层面上,而FESCAR的RM则是在应用层上面,这样就不会再依赖数据库对协议的依赖,开发人员可以最大限度的使用自己最擅长的

2019年1月9日,阿里正式在github开源了基于GTS的FESCAR,在此之前我们一直使用的是自研、网上的的分布式处理方案,都没有一个权威的组织来进行后期维护,但是分布式事务又一直是微服务系统的一个不容忽视的问题,接下来我们来看一下阿里开源的分布式FESCAR

FESCAR开源地址