查看完整视频
小黑屋思过中,禁止观看!
评论并刷新后可见

您需要在视频最下面评论并刷新后,方可查看完整视频

积分观看

您支付积分,方可查看完整视频

{{user.role.value}}
付费视频

您支付费用,方可查看完整视频

¥{{user.role.value}}
课程视频

开通VIP,畅学所有专题课程视频

会员专享

视频选集

最全分布式事务解决方案详解

  • 课程笔记
  • 交流讨论

分布式事务在电商、支付、金融等业务中是一个非常重要的技术场景,所以本节课我们就来重点解决分布式事务目前的主流解决方案。

我了助大家掌握好分布式事务,这节课我会重点讲解以下7点:

1.分布式事务

2.CAP

3.BASE

4.一致性模型

5.XA两阶段

6.事务补偿TCC

7.消息队列最终一致性

 

分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
最全分布式事务解决方案详解-mikechen的互联网架构师之路

简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。

本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

1.单体应用
最全分布式事务解决方案详解-mikechen的互联网架构师之路
2.微服务应用

随着业务需求的变化,单体应用被拆分成微服务应用,原来的模块被拆分成按照业务为单位的独立应用,分别使用独立的数据源,业务操作需要调用多个服务来完成。
最全分布式事务解决方案详解-mikechen的互联网架构师之路

按照业务为单位进行数据拆分:

  • 垂直拆分
  • 水平拆分

按照业务为单位提供服务:

  • 商品中心
  • 交易中心
  • 积分中心

业务场景:

用户支付商品,这里我们会创建三个服务,一个交易服务(下支付订单),一个商品服务(扣库存),一个支付服务(扣余额)。
最全分布式事务解决方案详解-mikechen的互联网架构师之路

业务流程:

  1. 当用户下单时,会在订单服务中创建一个订单。
  2. 然后通过远程调用库存服务来扣减下单商品的库存。
  3. 再通过远程调用账户服务来扣减用户账户里面的余额。
  4. 最后在订单服务中修改订单状态为已完成。

这个时候需要横跨多个服务,涉及订单、用户、商品库存、积分等多个数据库,而这些操作又需要在同一个事务中完,这就涉及到到了分布式事务。

这就是一个典型的分布式事务需求场景,我们需要一个分布式事务的解决方案保障业务全局的数据一致性。

CAP理论(强一致性)

隐藏内容,您需要满足以下条件方可查看
End

 

 

2 条回复 A文章作者 M管理员
  1. 路正银

    1.谈谈seata(fescar)分布式事务解决方案的实现原理?
    基于或者说参考了XA的实现,有全局事务和分事务,全局事务调度分事务,相比较于XA的两阶段提交,seata分事务第一阶段提交是真实提交(有commint),同时做好回滚日志,所有分事务都结束之后,由总事务来决定是提交(分事务去删除回滚日志)还是rollback(各个分事务开始回滚)。

    2.再谈谈seata相对于XA两阶段与TCC的优缺点?
    相对于XA两阶段提交有效的降低了锁的粒度
    想对于TCC对业务代码的侵入极小

    3.最后谈谈XA两阶段、TCC、MQ事务、以及seata等分布式事务方案的应用场景?
    XA两阶段,保证数据的强一致性,底层是基于数据库实现的,锁的范围太大,不适合高并发场合
    TCC,数据一致性是在业务层实现的,需要同时在业务层实现正向逻辑和反向逻辑,开发维护难度大
    MQ事务,保证的数据的最终一致性,适用于对数据一致性要求实时性不太高的场合(不要求数据实时一致性);上游事务和对发给下游事务的消息在一个事务里面,下游事务来消费消息(有重试机制);对业务代码有侵入
    seata,对业务代码侵入极小,锁的粒度小

    • mikechen

      good😊,谈到了锁的力度的问题就妥妥的了,继续,加油💪。

      备注:从多线程开始的锁、再到数据库的锁、再到事务涉及的锁、分布式锁,你会发现锁无处不在,也是核心重点。正是因为XA两阶段的锁是两阶段都要锁,从TCC开始就开始优化,再到Seata这个版本,都是希望锁的粒度能降低的同时,去满足高性能的一致性要求这个整体方向。