阿里P8:图解微服务下的分布式事务以及解决方案

阿里P8:图解微服务下的分布式事务以及解决方案

这篇文章,阿里P8带你从面试出发,学习分布式锁,不信你学不会 ,在这篇文章中,有一个读者给我评论了上面的截图中的这样的一条信息,而底下又有读者回复说:”这个可以涉及到分布式事务了“

所以,周末闲来无聊。就写下了这篇文章——分布式事务解决方案,希望对大家有所帮助

我们在说到事务的时候,总会以转账作为经典案例:用户下单买东西,一次买卖过程会扣件库存,生成订单,扣减账户余额;在这样的情况下,如果要保证数据业务的成功,必须引入事务。不再赘述。 在事务案例里面,我们的项目结构是这样的,Storage、Order、Account是一个服务里的三个功能模块,他们共同面对一个DB,这时候,启用本地事务,就可以实现三个操作的共同成功和共同失败。

阿里P8:图解微服务下的分布式事务以及解决方案

本地事务

然而,我们知道,如果库存、订单、账户分别在不同的服务当中,每个服务对应自己的DB,那么本地事务就没有办法去限制和判断其他操作是否一致性完成。这就需要引入分布式事务。

阿里P8:图解微服务下的分布式事务以及解决方案

分布式事务

分布式系统的三大原则:CAP

我们介绍解决方案之前,我们先介绍分布式系统的三大原则,也就是总会被提到的CAP定理:一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance),分别解释一下: 一致性 :我们希望分布式系统中各个节点的数据能保证一致,这里的“一致”,对于主从数据库来说是指主库和从库要保证数据一致。还是还有一层意思,就是分布式系统任何时刻数据都是最新状态。比如我买了东西,接下来order和account返回的就是最新的状态,我能从数据库中直接查到;再比如我们刚对数据库insert了一条数据,立马select,我们希望从数据库中返回的就是刚刚insert的数据。 如果我们要做到以上所说的,我们需要master向slave同步数据后,slave同步数据并表(假设因为网络原因同步需要一些时间),不对外开放读的状态,直到slave数据修改成功后,解锁。 可用性 :与一致性不同,所谓可用,就是每次访问数据时都能够得到数据,不能返回错误和超时,这一点看起来就和保证一致性的时候同步有些冲突,因为我们为了一致性得锁表,可能就会导致延时。 分区容错 :分区容错是我们使用分布式,特别是主从复制时候的意义所在,它指的是其中一个结点挂了,不能使整个数据库集群收到影响,其他服务还是可以正常运行。 看了以上三个原则的特点,我们可以了解到,CAP不能够共存,如果需要每次返回都是最新数据,那么就可能存在系统延时,但是这又违反了可用性。但无论如何,分区容错是必须保证的,集群不能因为某一个结点的宕机而整个垮掉。那么所有的分布式解决方案,也就是基于满足AP或者CP来展开设计的。

还是基于上面的案例,我们来设计一个分布式事务解决方案: 拿Storage和Order举例,既然业务上分成了两个服务,如果他们在各自的服务里面执行数据操作后,告诉某一个中心操作结果,如果各自的事务提交都成功,则整体成功,如果其中有一个事务失败,则一起回滚,这样一来不就可以控制分布式事务了吗。

阿里P8:图解微服务下的分布式事务以及解决方案

分布式事务管理

从上图我们可以看到,全局的事务可以通过一个专门的服务——Transaction Manager(TM)进行管理,它会去统计所有相关子事务的执行情况,如果全部提交成功,对应的全局事务正常结束就可以了(因为各个子事务已经完成了提交任务),如果其中有一个事务出现了问题,我们可以根据每个子事务上的undo log进行回滚,数据状态修复。 这其实就是Seata的实现原理: 在一次分布式事务中,发起全局事务的服务会向Seata服务注册一个全局事务,这个全局事务会给各个子事务进行关联:

阿里P8:图解微服务下的分布式事务以及解决方案

Global Transaction

与我们之前自己臆想的分布式事务有点出入的是,Seata还定义了一个事务调度服务:Transaction Coordinator(TC)它用来执行TM的指令。

阿里P8:图解微服务下的分布式事务以及解决方案

Seata执行流程

  1. 发起全局事务的微服务会启动一个全局事务的实例(TM),TM会告诉TC进程“我要开启全局事务了”,这时候,TC会返回一个XID给该微服务。
  2. 得到XID后,该微服务上的资源管理器(Resource Manager)将子事务注册到TC上,TC将该事务纳入全局事务管理。
  3. 微服务开始执行自己的本地事务,比如新建一个order表数据。
  4. 随着代码逻辑的执行,现在需要远程调用库存微服务,去扣减库存,这时候这个全局的XID会一并传给库存服务上的TM,库存上的MC就会在本地事务开启之前向TC进行子事务的注册,这样库存事务也被纳入全局事务管理。
  5. 库存事务执行完毕后,返回到订单微服务,这个时候,如果订单事务也执行完成,则由TM(TM存在于发起全局事务的服务中)告诉TC各个子事务的执行情况,将提交或回滚的决议给到TC。
  6. TC根据全局事务-分支事务的映射关系执行TM传过来的决议。

这就是关于 seata 的相关整理,不足的地方,希望大家在下方评论区一起交流

觉得写的还可以的老铁,欢迎关注公众号:java架构师联盟,文章首发公众号

原文 

https://segmentfault.com/a/1190000022422469

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 阿里P8:图解微服务下的分布式事务以及解决方案

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址