13 | 全局事务和共享事务是如何实现的？
全局事务
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了分布式系统中的全局事务和共享事务的实现方式。全局事务通过XA协议实现多个数据源的统一提交或回滚，保持数据一致性。文章介绍了两种全局事务处理方式：两段式提交和三段式提交。两段式提交存在单点问题、性能问题和一致性风险，而三段式提交改善了单点问题和回滚时的性能问题，但并未解决一致性风险问题。共享事务是指多个服务共用同一个数据源，虽然在实际应用中已经很少见，但仍然有一定的使用群体。全局事务和共享事务中的两段式提交和三段式提交模式仍然会在一些多数据源的场景中用到，但现在系统设计的主流已经转向不追求ACID而是强调BASE的弱一致性事务。下一讲将学习分布式事务。总的来说，全局事务和共享事务在分布式环境中非常重要，但两段式和三段式提交都存在各自的局限性，需要根据具体场景进行选择和权衡。
请先领取课程
全部留言(31)
- 最新
- 精选
zhanyd学校组织知识竞赛，学生们（参与者）以一组为单位参加比赛，由一个监考老师（协调者）负责监考。 考试分为考卷和答题卡，学生必须先在十分钟内把答案写在考卷上（记录日志），然后在三分钟内把答案涂到答题卡上（提交事务）。 两段式提交 准备阶段：老师宣布：“开始填写考卷，时间十分钟”。 十分钟内，写好考卷的学生就回答：Prepared,十分钟一到，动作慢，还没写好学生，就回答：Non-Prepared。 如果有学生回答Non-Prepared，该小组被淘汰。 提交阶段：如果所有的学生都回答了Prepared，老师就会在笔记本上记下，“开始填答题卡”（Commit），然后对所有的学生说：“开始填答题卡”（发送 Commit 指令）。 学生听到指令后，就开始根据考卷去涂答题卡。 如果学生在涂答题卡的时候，过于紧张把答题卡涂错了，还可以根据考卷重新涂。 如果所有的学生在规定时间内都填好了答题卡，老师宣布该小组考试通过。 三段式提交 CanCommit阶段：老师先给学生看一下考卷，问问学生能不能在十分钟内做完。如果有学生说没信心做完，该小组直接淘汰。 PreCommit阶段：如果学生都说能做完，老师就宣布：“开始填写考卷，时间十分钟”，和两段式提交的准备阶段一样。 DoCommit阶段：和两段式提交的提交阶段一样。作者回复: 为你点赞*2
2020-12-179138
马成我没有使用过xa，看到说协调者也是由数据库扮演的，那么扮演协调者的数据库要和其他数据库通讯需要先认证，难道要把其他数据库的连接信息配置到协调者数据库？感觉这样使用太反直觉了作者回复: 原文写的是“通常是由数据库本身来扮演的”。 协调者确实需要知道每一个数据库的信息，如果协调者是数据库的话，它需要知道各个资源管理器的信息。写“通常”是因为XA协议是主要从数据库本身的协同工作出发的。举个例子，MySQL就支持多个数据库引擎之间通过XA组成全局事务，此时可以完全没有Java（或其他语言）作为应用层的存在，你直接向MySQL发送XA START、XA END 、XA PREPARE/COMMIT/ROLLBACK等指令就可以驱动事务运行。 实际应用中，由各种异构数据源（不同数据库、消息列、缓存、etc，反正只要支持XA协议）来组成的XA事务，通过其上的应用层扮演协调者也是普遍行为，此时协调者与客户端在逻辑上仍是独立的角色，但物理上完全有可能是同一台应用服务器去扮演。 这两个例子中，前者通常被称为内部XA，后者被称为外部XA。
2020-12-1834
知行合一想请问下，协调者是如何选择出来的？作者回复: XA协调者并没有自动选主的设计，如果是应用程序访问一堆数据库，那它是那个应用程序。如果是一群数据库之间（譬如你直接发送SQL语句）的XA事务，那它是发起事务的那个数据库。
2021-02-0412
渁皛の巧尅劦老师 共享事务需要以中间件的形式来提供链接共享 那么分布式里面的一个服务A的多个实例链接的同一个数据库 这种应该算哪种事物呢作者回复: 这些服务实例本身都是独立的，相互之间没有交互，那这个其实就是最基本的本地事务而已。
2021-03-253
蓝蓝【在部署应用集群时最常采用的模式是，将同一套程序部署到多个中间件服务器上，构成多个副本实例来分担流量压力。它们虽然连接了同一个数据库，但每个节点配有自己的专属数据源，通常是中间件以 JNDI 的形式开放给程序代码使用。 这种情况下，所有副本实例的数据访问都是完全独立的，并没有任何交集，每个节点使用的仍是最简单的本地事务。】 请教下老师，这里说的多个副本用不同数据源，应该数据源的数据库用户是一样的吧，因为每个副本都要能实现一样的功能？那访问的数据应该是可能不同副本访问到同一张表吧，可能会遇到一致性问题吧？我知道的太少了，若老师能回答，非常感谢作者回复: 确实是同一套用户，也确实是会访问到同一张表。但请注意文中说的是“数据访问”是独立的，而非“数据”是独立的。这里的意思是说，两个独立服务，即使同访问同一个库同一张表，也必定是分处于两个不同事务之中的独立操作，并不会涉及操作同一个事务中的数据而互相产生影响。 两个独立的事务会不会产生一致性的问题，这个理论上可以保证不会（A、I、D保证了C），实际上取决于隔离级别的设定如何。这方面内容在本地事务的两节中已探讨过，你可以参考一下。
2020-12-2933- bigbenTCC老师讲不讲？
作者回复: 后面2节分布式事务的课会介绍
2020-12-173 
不在低谷拂袖去关于 2PC 的前提条件中的“假设网络在提交阶段是可靠的”有一些疑问 提交阶段丢失数据，参与者不会超时处理吗？ 还有一个连带问题，在 2PC 阶段的缺点之“单点问题”中提到“参与者等待协调者指令时无法做超时处理” 这是为什么呢？作者回复: 因为准备阶段结束，所有参与者都回复了Prepared的那一刻起，整个集群的数据状态就无法再改变了。 你可以想像一下这个情景：假设某个参与者在应答Prepared消息后从网络中断开，丢失了协调者的后续指令，如果允许超时，超时之后它应该如何处理呢？如果它选择Rollback了数据，万一协调者收到所有Prepared消息后，发出的是Commit指令，那其他参与者会提交事务，这样该节点超时后重新上线，它后超时回滚掉那部分数据就与其他参与者的不一致了。反之，超时提交也是不合适的，因为怕协调者发出的是Abort指令。
2020-12-2232- 流云老师您好，请问消息队列方式共享事务怎么实现呢，如果用户、商家、仓库服务都发送一条消息，消费者怎么同时消费这三条消息呢
作者回复: 我赞同Jxin同学的回复。可以点开看一下。
2020-12-1641 - Scott我觉得多个服务同一个数据源是挺常见的需求，比如买书的业务，需要一份敏感书籍的黑名单，这个是经常修改的权威数据，然后每一个服务都要读它。
作者回复: 尽管直接读在现实中非常常见，但推荐的做法是把这个黑名单独立成为一个服务，通过服务而不是数据源来使用它。 这个黑名单并非CRUD，涉及到一些逻辑的话，有归属的服务会健壮且方便许多。
2021-04-30 - Helios两阶段提交和三阶段提交如果应用到分布式事务中，是不是也是可行的呢，就是效率会变的低
作者回复: 这个得看你怎么定义“可行”了
2021-02-032