高并发系统实战课
徐长龙
前微博架构师、极客时间架构师
11663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语&结课测试 (2讲)
高并发系统实战课
15
15
1.0x
00:00/00:00
登录|注册

09|分布式事务:多服务的2PC、TCC都是怎么实现的?

Seata
DTM
缺点
数据一致性
并发性能
缺点
数据一致性
并发性能
缺点
数据一致性
并发性能
思考题
市面上的中间件
TCC
3PC
2PC
Cancel阶段
Confirm阶段
Try阶段
DoCommit阶段
PreCommit阶段
CanCommit阶段
流程图
代码实现
Commit阶段
Prepare阶段
资源管理器(RM)
事务协调器(TM)
应用(AP)
总结
TCC协议
3PC简述
MySQL XA的2PC分布式事务
XA协议
分布式事务

该思维导图由 AI 生成,仅供参考

你好,我是徐长龙,今天这节课我们聊聊分布式事务。
目前业界流行微服务,DDD 领域驱动设计也随之流行起来。DDD 是一种拆分微服务的方法,它从业务流程的视角从上往下拆分领域,通过聚合根关联多个领域,将多个流程聚合在一起,形成独立的服务。相比由数据表结构设计出的微服务,DDD 这种方式更加合理,但也加大了分布式事务的实现难度。
在传统的分布式事务实现方式中,我们普遍会将一个完整的事务放在一个独立的项目中统一维护,并在一个数据库中统一处理所有的操作。这样在出现问题时,直接一起回滚,即可保证数据的互斥和统一性。
不过,这种方式的服务复用性和隔离性较差,很多核心业务为了事务的一致性只能聚合在一起。
为了保证一致性,事务在执行期间会互斥锁定大量的数据,导致服务整体性能存在瓶颈。而非核心业务要想在隔离要求高的系统架构中,实现跨微服务的事务,难度更大,因为核心业务基本不会配合非核心业务做改造,再加上核心业务经常随业务需求改动(聚合的业务过多),结果就是非核心业务没法做事务,核心业务也无法做个性化改造。
也正因为如此,多个系统要想在互动的同时保持事务一致性,是一个令人头疼的问题,业内很多非核心业务无法和核心模块一起开启事务,经常出现操作出错,需要人工补偿修复的情况。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式事务在微服务和领域驱动设计中面临挑战,传统实现方式存在问题。本文深入探讨了分布式事务的实现方式及其优缺点,介绍了XA协议在多个数据库中协调分布式事务的应用,以及MySQL中XA的2PC分布式事务的具体指令集。此外,文章还介绍了TCC协议,相比2PC和3PC,TCC协议具有更好的性能,能够实现分布式事务而无需使用XA。TCC协议的Try-Confirm-Cancel流程以及优缺点也得到了详细阐述。 总体来说,本文通过丰富的内容和强大的技术性,帮助读者更好地理解分布式事务的实现过程。文章提到了不同的分布式事务实现方式,包括2PC、3PC和TCC,分析了它们各自的优缺点,以及适用场景和注意事项。此外,还提到了市面上一些优秀的中间件,如DTM、Seata,它们对分布式事务协调做了很多优化,提供更完善的流程机制。 对于读者来说,本文是一份深入浅出的技术指南,能够帮助他们快速了解分布式事务的实现方式及其性能特点,以及选择合适的实现方式来解决业务需求。文章内容丰富,技术性强,适合对分布式事务感兴趣的读者阅读。 总的来说,本文为读者提供了全面的分布式事务实现方式的介绍和分析,对于理解和应用分布式事务具有很大帮助。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • peter
    请教老师几个问题: Q1:MySQL支持XA的bug很多,那么,实际项目中不能用XA吗? Q2:TCC既可以是XA,也可以不是XA,对吗? Q3:seat是采用XA的吗?还是普通的事务? Q4:中厂、大厂一般用什么来做分布式事务? Q5:一个网站,50万用户,这种规模的网站用什么来实现分布式事务?

    作者回复: 你好,peter,很高兴收到你的再次留言,1.XA的bug体现在偶尔特殊情况下事务遗留,什么时候commit到binlog,个别事务回滚失败,一般推荐使用TCC,这里用XA讲解是方便快速理解。2.没错,具体实现可以不同,甚至事务一直不关闭维持链接,等待最终commit。3.seata是一个组件,里面很多种方式,其中at可以根据修改sql自动生成回滚sql。4大厂会尽力修改事务的粒度,分区,分片,分块。5,小规模的普遍tcc或比较复杂的组件实现,比如seata的saga,大规模的利用分布式数据库的分布式事务

    2022-11-11归属地:北京
    2
    4
  • Sam Fu
    老师 xa这玩意有人用吗

    作者回复: 你好,目前XA在开源数据库还在不断改进不能保证完全可用,还有很多问题,实际使用过程中还存在问题,应用范围其实并不广,但是这个协议能够帮助我们快速理解多模块分别提交的思路所以这节课重点拿他作为例子,理解XA以后其他解决方案你会发现理解起来十分容易。

    2023-09-01归属地:北京
    1
  • 花花大脸猫
    前提是能接受短暂的数据不一致(非强一致性),所以业务上我们一般很少会使用分布式事务来管控,而是通过补偿机制来实现业务数据的一致性,但是如果调用的链路很长的话,补偿也是一个很头疼的事情

    作者回复: 没错,带条件的回滚更麻烦,如果中断了更麻烦

    2022-11-18归属地:北京
    1
  • txjlrk
    厉害,由浅入深,由理论到实践,面面俱到。 分布式事务也分为柔性和刚性两种

    作者回复: 你好,老铁,我查了下这个归类方式不错,柔性相对的性能更好类似TCC ,刚性类似2pc 与xa

    2022-11-11归属地:北京
    1
  • 阿昕
    思考题:1.利用本地消息表+mq,或者mq的事务消息实现,可以达到解耦的目的;2.利用seata类框架,对复杂场景或者长事务可以使用sega模式。

    作者回复: 不管哪个选择,都会有取舍

    2023-04-06归属地:浙江
  • 👽
    有一个没用的废话就是,要尽可能减少分布式事务的发生以及,尽可能使分布式事务的力度更细。 比如现在创建订单和支付行为很多厂商似乎就是拆开的。 似乎基本都是: 1. 创建订单的同时扣减库存。这一部分是一个事务; 2. 用户付款,扣减用户余额,同时修改订单状态。这部分是另外的事务; 至于如何处理事务,个人都是事务补偿会好一些。因为是人工处理的,所以更加可控。现在解决分布式事务的组件,貌似没有看到哪个实现方式是特别可用的。 而且有时候不得不考虑一个问题,多个服务间很可能不是同一套协议,也不适合让人去兼容你的事务解决方案。

    作者回复: 没错,这类问题在行业不断提出,才会有更深的思考

    2023-03-31归属地:广东
  • Mr.差不多
    您好,老师 TCC 和二阶段是什么关系?

    作者回复: 你好,Mr.差不多,很高兴收到你的留言,TCC也是二阶段的只不过他的思路和传统的二阶段的“先锁定预占然后等待所有步骤完成后再一起提交” 有所不同,他是先将所需的争抢资源先全抢到,然后再做最后执行,并且提交和回滚是支持多次执行的,不过TCC缺点就是很多需要人工做更多事情

    2023-03-03归属地:上海
  • jjn0703
    AT和Saga这是另外的两种模式吗?

    作者回复: 是的

    2023-02-11归属地:江苏
    2
  • 李二木
    TCC 协议 是2pc 吗

    作者回复: 你好,李二木,也是两阶段提交,只不过所有逻辑是自己实现的,回滚也是

    2022-11-22归属地:北京
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部