上一篇著作咱们将统共这个词交往系统进行了微劳动化，拆分为了多个互相落寞的业务组件王老撸，每个业务组件不仅仅包含我方业务的微劳动，还包括了落寞管束的数据库。那么，咱们来琢磨下单的场景，用户下拜托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是送达给到撮合引擎。这三步需要保证事务的一致性。在劳动和数据库都不拆分的情况下，是很容易平静的。但拆分之后，这几个设施的操作也分开到不同行务组件了，劳动是分开的，数据库亦然分开的。在这种分散式的环境下，又要如何保证事务的一致性，这等于分散式事务问题了。
那分散式事务问题都有哪些处治决议？如何选型？如何落地？本篇著作咱们就来逐个解答这些问题。
从 ACID 说起ACID 是数据库事务平时履行的四个脾气，分别指：原子性（Atomicity）、一致性（Consistency）、禁绝性（Isolation）、抓久性（Durability）。
原子性要求一个事务的一系列操作要么全部完成，要么全部不完成，不可停滞在中间某个过错。如果中间发生纵情，应该回滚到事务出手前的景色。
抓久性则要求事务收尾后，其成果应该是抓久化的。在数据库层面，广漠都是用 WAL（Write-Ahead Logging） 本事来保证原子性和抓久性的。
禁绝性是为了应答并发事务的，要求并发履行的各个事务之间是互相禁绝的，防患多个事务并发履行时由于交叉履行导致数据的不一致。如果不琢磨禁绝，则可能会出现脏读、不可重迭读、幻读等问题。骨子上，禁绝的收场其实等于并发为止。SQL 模范中，界说了 4 种禁绝级别，由低到高分别为：未提交读（Read Uncommitted）、已提交读（Read Committed）、可重迭读（Repeatable Read）、串行化（Serializable）。禁绝级别越低的事务，并发性更好，但一致性更低。而模范界说的这 4 种禁绝级别，其实只适用于基于锁的事务并发为止。自后，出现了基于 MVCC（多版块并发为止） 机制的禁绝决议，该机制联系于基于锁的并发为止主要特色是读不上锁，这种脾气关于读多写少的场景，大大提高了系统的并发性能，因此大部分数据库都收场了 MVCC。
一致性很容易和 CAP 中的 C 混浊，但其实两者是不同宗旨。CAP 中的一致性，具体到数据库上，指的是在分散式数据库中，每一个节点关于肃清个数据必须有沟通的拷贝。而事务的一致性，确保事务只可将数据库从一种有用景色滚动到另一种有用景色，并保抓数据库不变性，不存在可感知的中间景色。所谓有用景色等于平静预定的拘谨，包括数据库层面的多样拘谨，也包括业务逻辑上的拘谨。
解释事务一致性最常用的例子等于转账，假定 A 向 B 转账 100 元。如果 A 的账户余额只剩下 90 元，而数据库对账户余额的拘谨条款是不可小于 0，那如果还能转账获胜的话，A 的账户余额将变成负数，不合适拘谨条款，也就不平静一致性。如果 A 的账户余额满盈，那就需要分两个设施，先扣减 A 的账户余额 100 元，再给 B 的账户余额增加 100 元，如果只完成了第一步，事务就收尾了，那业务逻辑上等于不正确的，即统共这个词事务也不平静一致性。只须 A 的账户余额扣减了 100 元，同期 B 的账户余额增加了 100 元，两步都一王人获胜，且不受其他并发事务的打扰，这时统共这个词事务才保证了一致性。
从骨子上来说，原子性、禁绝性、抓久性，最终主见都是为了保证一致性。即一致性是最终策划，原子性、禁绝性、抓久性不错说都是为了收场这还是营的技巧。
是以，非论是土产货事务，如故分散式事务，最终的策划都是为了保证一致性。仅仅针对不同场景，有着不同的收场决议，且对一致性的强弱进程有所弃取。
XA 范例分散式事务的处治决议有许多种，XA 范例是其中一种有代表性的模范决议，是由 X/Open 组织在 1991 年提议来的，该范例的文档为：《Distributed Transaction Processing: The XA Specification》。
XA 范例里面目了一个 DTP 模子，这是一个收场分散式事务处理系统的宗旨模子。其实不仅仅 X/Open，OSI 其实也有崇拜文档对 DTP 模子进行了面目。XA 范例里面目了该模子包含三类脚色：
AP：Application Pragram，应用规范，界说了事务的鸿沟，以及指定了构成一个事务的行动，不错调处为等于事务发起的某个微劳动。RMs：Resource Managers，资源管束器，有多个，不错调处为等于分散式数据库中的每一个数据库实例。TM：Transaction Manager，事务管束器，负责合作和管束事务，是一个为止全局事务的合作家。之是以引入 TM，是因为统共这个词全局事务被分散到多个节点之后，每个节点固然不错知谈我方操作是否获胜，可是却无法得知其他节点上操作是否获胜，靠分散的节点自身并无法保证全局事务的一致性，因此需要引入一个合作家来管束全局，进而才调保证全局事务的 ACID。
这三者的关系图如下：
图片
XA 范例里还界说了一系列接口，称为 XA 接口，用于 TM 和 RM 之间通讯的接口，主要包含了以下这些接口：
图片
TM 与 RM 之间收场事务的完成和回滚，是使用了 2PC（Two-Phase Commit） 条约——即两阶段提交条约来收场的。2PC 条约的提议时辰比拟 XA 范例早得多，最早是分散式事务的内行 Jim Gray 在 1977 年的一篇著作 《Notes on Database Operating Systems》 中说起。
2PC 条约2PC = Two-Phase Commit，两阶段提交，将事务分割成先后两个阶段：Prepare 阶段和 Commit 阶段。
在出手两阶段提交之前，触及的 RM 是需要先注册到 TM 的。然后，AP 向 TM 发起一个全局事务，之后，就出手参预该事务的两阶段提交了。
Prepare 阶段，由 TM 向触及的每个 RM 都发送 prepare 肯求，并恭候 RMs 的反馈。RM 接管到肯求之后，履行土产货事务但不会提交，并记载下事务日记，即 undo 和 redo 日记。RM 的土产货事务如果履行获胜，则复返给 TM ok 的反馈，如果土产货事务履行失败，则反馈 error。在这一阶段，RM 履行土产货事务获胜的话，因为莫得提交，就会一直锁定事务资源，并恭候 TM 的下一步领导。
Prepare 阶段收尾后，会存在三种可能性：
统共的 RM 都反馈 ok一个或多个 RM 反馈 errorTM 恭候 RM 的反馈超时Commit 阶段，把柄以上三种不同成果，会履行不一样的操作。如果是统共 RM 都反馈 ok，那 TM 就向统共 RM 发送 commit 肯求。如果出现其他两种情况，则由 TM 向统共 RM 发送 rollback 肯求。RM 收到 commit 肯求的话，就会将上一阶段未提交的土产货事务进行提交操作，如果收到 rollback 肯求，那就回滚土产货事务。
统共这个词经由苟简如下图：
图片
经由上固然通俗，但分散式系统，随时可能发生网罗超时、网罗重发、劳动器宕机等问题，因此也会给分散式事务带来一些问题。主要有幂等处理、空回滚、资源吊挂这几个问题。
当 TM 向 RM 发送 commit/rollback 肯求时，如果出现网罗抖动等原因，导致肯求超时或中断，那 TM 就需要向 RM 重迭发送 commit/rollback 肯求。对 RM 来说，第一次 commit/rollback 肯求可能已经接管到了，且已经处理过了，但因为网罗原因导致 TM 充公到反馈。那 RM 再次收到不异的 commit/rollback 肯求，确信不可再处理一次土产货事务。正确的作念法等于 RM 的 commit/rollback 接口需要保证幂等性。
如果 RM 充公到 prepare 肯求，但收到了 rollback 肯求，那这个 rollback 肯求其实是无效的，即本次 rollback 就属于空回滚。要处治空回滚的问题，那 rollback 时需要识别到前一阶段的 prepare 是否已经履行。
如果 prepare 肯求因为网罗拥挤而超时，之后 TM 发起了 rollback，而最终 RM 又收到了超时的 prepare 肯求，但 rollback 比 prepare 先到达 RM。这种情况下，收到 prepare 的时候，统共这个词全局事务其实已经收尾了，如果再履行 prepare 肯求，就会锁定关系资源，但事务已经收尾，锁定的资源将无法开释。至此，就形成了资源吊挂。
处治这三个问题的决议，广漠都不错用事务景色为止表来处治，该表主要包含了全局事务ID、分支事务ID、分支事务景色。
XA/2PC 小结XA/2PC 用在分散式事务，一般情况下能够保证事务的 ACID 脾气，能欺诈数据库自身的收场进行土产货事务的提交和回滚，对业务莫得侵入。但 2PC 的污点主要有以下几个：
同步阻碍：在履行过程中，统共 RM 都是事务阻碍型的，如果 RM 占有了大家资源，那其他第三方要访谒大家资源时就会处于阻碍景色。TM单点故障：一朝 TM 发生故障，RMs 会由于恭候 TM 的音信，而一直锁定事务资源，导致统共这个词系统被阻碍。数据不一致：在第二阶段中，当 TM 向 RMs 发送 commit 肯求之后，发生了局部网罗相配或者在发送 commit 肯求过程中 TM 发生了故障，导致只须部分 RMs 接到了 commit 肯求。这部分 RMs 接到 commit 肯求之后就会履行 commit 操作，可是其他未接到 commit 肯求的 RMs 则无法履行事务提交。于是统共这个词分散式系统便出现了数据不一致的风光。事务景色省略情：TM 发出 commit 音信之后宕机，而接管到这条音信的 RM 同期也宕机了，那么即使通过选举条约产生了新的 TM，这条事务的景色亦然省略情的，集群中无法判断出事务是否已经被提交。2PC 最大的问题其实是性能差，处理短事务可能还好，若是处理长事务，那资源锁定时辰更长，性能更差，压根无法哑忍。
为了革命 2PC，自后又提议了 3PC。3PC 给 RMs 也增加了超时机制，而且把统共这个词事务拆成了三个阶段。不外，3PC 也仅仅处治了 2PC 的部分问题，并莫得处治性能差的问题，而且因为多增加了一个阶段，导致性能更差了。因此，3PC 险些没东谈主使用，我也没找到落地收场，是以我也不蓄意久了去磨真金不怕火 3PC。2PC 固然有劣势，反而还有落地收场，开源框架就有 Atomikos、Bitronix 以及 Seata 的 XA 时势，另外，大部分主流数据库厂商也落地收场了 XA/2PC。因此，对强一致性有要求的场景，2PC 依然如故最好选择。
说到开源框架，我要补充一下，现在纯属的分散式事务框架，包括底下提到的，基本都是基于 Java 的，其他话语的落地收场都还不纯属。
柔性事务合适 ACID 脾气的事务，也不错称为刚性事务，主要保证强一致性。XA/2PC 等于处治刚性分散式事务的主要决议，但因为性能太差，并不恰当高性能、高并发的互联网场景。为了处治性能问题，就有东谈主基于 BASE 表面提议了柔性事务的宗旨。BASE 表面其实等于 Basically Available（基本可用）、Soft state（软景色）、Eventual consistency（最终一致性） 三个短语的缩写，其中枢念念想等于：
即使无法作念到强一致性（Strong consistency），但每个应用都不错把柄自身的业务特色，领受妥当的式样来使系统达到最终一致性（Eventual consistency）。
前边咱们说过，事务的（强）一致性，确保事务只可将数据库从一种有用景色滚动到另一种有用景色，不存在可感知的中间景色。柔性事务就允许数据存在中间景色（即软景色），只须经过一段时辰后，能达到最终一致性即可。最终一致性的骨子是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。跨行转账等于最好的一个示例，转账时，其实有个资金冻结的中间景色，且要经过一段时辰才知谈转账成果，即达到最终一致性的成果。
刚性事务在禁绝性方面，主若是通过资源锁定的式样收场资源禁绝的，在数据库层面自身就提供了这种禁绝收场，不需要业求收场。而柔性事务则一般不必锁，而是通过资源预留（比如冻结金额）的式样收场禁绝，且这种资源预留的禁绝式样，是需要业务我方去收场并保证禁绝性的。
柔性事务的处治决议主要分为抵偿型和奉告型两大类，抵偿型的决议主要有 TCC 和 Saga 两种时势，奉告型的决议则又分为事务音信型和最大勤勉奉告型。抵偿型事务一般是同步的，奉告型事务则是异步的，是以也有同步事务和异步事务的分裂。
TCCTCC = Try-Confirm-Cancel，等于三个单词的缩写。TCC 最早的出现其实不错回顾到 2007 年的一篇论文：《Life beyond Distributed Transactions: an Apostate’s Opinion》，在该论文中，其实蓝本的三个单词是 Tentative-Confirmation-Cancellation，崇拜以 Try-Confirm-Cancel 行为称号的是 Atomikos 公司，且还注册了 TCC 商标。
TCC 其实亦然基于 2PC 的遐想念念路演变过来的，也不异分两个阶段进行事务提交，第一阶段提交 Try 接口，第二阶段提交 Confirm 或 Cancel 接口。TCC 的 Try-Confirm-Cancel 固然与 2PC 的 Prepare-Commit-Rollback 很相似，但收场却大不同。
2PC 其实是数据库层面或者说是资源层面的分散式事务决议，Prepare-Commit-Rollback，这几个操作其实都在数据库里面完成的，缔造者层面是感知不到的。
TCC 则是业务层面的分散式事务决议，Try-Confirm-Cancel 都是在业务层面收场的操作，缔造者是能感知到的，是需要缔造者我方去收场这几个操作的。
Try 阶段，主要会完成统共业务查抄，并对需要用到的业务资源转为中间景色，通过该式样收场资源预留。比如，转账时将金额冻结。
如果 Try 阶段，统共分支业务都复兴 OK，第二阶段就对统共分支业务提交 Confirm，证据履行业务，这时候就无需再作念业务查抄了，而是顺利将中间景色的资源转为最终景色。
如果 Try 阶段，并非统共分支业务都复兴 OK，这时就要走抵偿机制了，对那些 Try 操作 OK 的分支业务，履行 Cancel 抵偿操作，回滚 Try 操作，将中间景色的资源收复到事务前的景色。
TCC 的具体经由如下图所示：
图片
瞩目，第一阶段的 Try 接口是由业务应用调用的（实线箭头），第二阶段的 Confirm 或 Cancel 接口则是事务合作器 TM 调用的（虚线箭头）。这等于 TCC 模子的二阶段异步化功能，分支业务劳动的第一阶段履行获胜，业务应用就不错提交完成，然后再由事务合作器异时局履行各分支业务劳动的第二阶段。
TCC 中会添加事务日记，如果 Confirm 或者 Cancel 阶段出错，则会进行重试，是以这两个阶段都需要撑抓幂等。如果重试失败，则需要东谈主工介入进行收复和处理了。TCC 除了需要撑抓幂等处理，前边提到的空回滚、资源吊挂的问题也不异需要处治。
TCC 相对 2PC，因为对资源不加锁，不会影响并发事务对资源的访谒，是以性能获取大幅提高，就恰当处理高并发的场景，也恰当处理长事务。
但 TCC 的污点等于对业务侵入性太强，需要广漠缔造使命进行业务改革，给业务升级和运维都带来难题。TCC 落地收场的开源框架主要有 ByteTCC、TCC-transaction、Himly、Seata TCC 时势等。
SagaSaga 的发源比 TCC 早得多，发源于 1987 年的一篇论文《Sagas》，申诉的是如哪里理 long lived transaction（长活事务）。Saga 的中枢念念想等于将一个长事务领会为多个短事务（也哨子事务），每个子事务都是能保证自身一致性的土产货事务，且每个子事务都有相应的履行模块和抵偿模块。当其中任意一个子事务出错了，就不错通过调用关系的抵偿方法收复到事务的开动景色，从而达到事务的最终一致性。
总的来说，Saga 的构成包含两部分：
每个 saga 事务由一系列子事务 Ti 所构成每个 Ti 都有对应的抵偿动作 Ci，用于铲除 Ti 酿成的成果和 TCC 比拟，Saga 事务莫得分两阶段提交，莫得“预留”的动作，Ti 是顺利提交到库的。因此，有东谈主就会发问了：那 Saga 如何保证禁绝性的呢？其实，Saga 自身并不保证禁绝性，需要业务我方为止并发，即在业务层我方收场对资源的加锁或预留。
最好情况等于统共这个词子事务序列 T1, T2, ..., Tn 全部都履行获胜，统共这个词 Saga 事务也就履行获胜了。
如果履行到某一子事务失败了，那有两种收复式样：上前收复和向后收复。
上前收复：重试失败的事务，假定每个子事务最终都会获胜向后收复：抵偿统共已完成的事务，骨子等于统共已完成的土产货事务进行回滚操作昭着，上前收复就没必要提供抵偿方法。如果你的业务中，子事务最终总会获胜，或抵偿方法难以界说或不可能，上前收复更合适你的需求。
向后收复的话，如果出现子事务失败，会立行将失败信息反馈给 AP，之后的抵偿操作则是异门径行的。
表面上，抵偿方法是必须要获胜的，如果履行抵偿操作时，因为劳动器宕机或网罗抖动等原因导致抵偿失败，那就需要对抵偿方法也进行重试，如果重试依然失败，那就需要东谈主工介入进行处理了。
Saga 的收场式样，主要分采集式和非采集式两种。
采集式的收场需要依赖中心化的合作器（TM）负责劳动调用和事务合作，主若是基于 AOP Proxy 的遐想收场，华为的 ServiceComb Saga 就用这种收场式样。采集式的收场式样比较直不雅而且容易为止，缔造通俗、学习老本低，污点等于业务耦合进程会比较高。
非采集式的收场，也称为分散式的收场，不依赖于中心化的 TM，而是通过事件驱动的机制进行事务合作，Seata Saga 就领受了这种机制，收场了一个景色机。非采集式的收场的优点：领受事件源的式样裁减系统复杂进程，提高系统膨胀性， 处理模块通过订阅事件的式样裁减系统的耦合进程。污点则是：Saga 系统会触及广漠的业务事件，这么会对编码和调试带来一些问题；还有等于关系的业务逻辑处理是基于事件，关系事件处理模块可能会有轮回依赖的问题。
Saga 因为莫得两阶段提交，是以，Saga 处理事务肯求所消耗的时辰可能仅仅 TCC 的一半， 因为 TCC 需要与每个劳动至少进行两次通讯，而 Saga 只需要通讯一次。因此，表面上，Saga 的性能比 TCC 至少不错高一倍。且因为 Saga 对业务的侵入性较小，是以 Saga 是现在行业内落地较多的获胜决议。
事务音信型事务音信型，也称异步确保型，中枢念念路等于：用音信队伍（MQ）来保证最终一致性。比拟同步的抵偿型决议，引入 MQ 的异步决议，主要有以下优点：
不错裁减不同分支事务的微劳动之间的耦合度不错提高各劳动的蒙胧量不错增强举座劳动的可用性那么，引入 MQ 之后，最中枢的问题在于如何处治劳动土产货事务处理获胜与音信发送获胜两者的一致性问题。即 MQ 音信的上游劳动处理完土产货事务之后，如何才调保证音信可靠地传递给到下流劳动。而现在业界处治该问题的决议有两种：
基于 MQ 自身的事务音信基于 DB 的土产货音信表MQ 事务音信基于 MQ 自身的事务音信决议，据了解，现在只须 RocketMQ 提供了撑抓，其他主流的 MQ 都还不撑抓，是以咱们对该决议的讲授都是基于 RocketMQ 的。该决议的遐想念念路是基于 2PC 的，事务消拒却互经由如下图所示：
图片
其中，触及几个宗旨要评释一下：
事务音信：音信队伍 MQ 提供肖似 X/Open XA 的分散式事务功能，通过 MQ 事务音信能达到分散式事务的最终一致。半事务音信：暂不可送达的音信，发送方已经获胜地将音信发送到了 MQ 劳动端，可是劳动端未收到坐蓐者对该音信的二次证据，此时该音信被标志成“暂不可送达”景色，处于该种景色下的音信即半事务音信。音信回查：由于网罗闪断、坐蓐者应用重启等原因，导致某条事务音信的二次证据丢失，MQ 劳动端通过扫描发现某条音信永迢遥于“半事务音信”时，需要主动向音信坐蓐者接洽该音信的最终景色（Commit或是Rollback），该接洽过程即音信回查。事务音信发送设施如下：
发送方将半事务音信发送至 MQ 劳动端。MQ 劳动端将音信抓久化获胜之后，向发送方复返 Ack 证据音信已经发送获胜，此时音信为半事务音信。发送方出手履行土产货事务逻辑。发送方把柄土产货事务履行成果向劳动端提交二次证据（Commit 或是 Rollback），劳动端收到 Commit 景色则将半事务音信标志为可送达，订阅方最终将收到该音信；劳动端收到 Rollback 景色则删除半事务音信，订阅方将不会领受该音信。事务音信回查设施如下：
在断网或者是应用重启的荒芜情况下，上述设施4提交的二次证据最终未到达劳动端，经过固定时辰后劳动端将对该音信发起音信回查。发送方收到音信回查后，需要查抄对应音信的土产货事务履行的最终成果。发送方把柄查抄获取的土产货事务的最终景色再次提交二次证据，劳动端仍按照设施4对半事务音信进行操作。有小数需瞩目，如果发送方莫得实时收到 MQ 劳动端的 Ack 成果，那就可能酿成 MQ 音信的重迭送达，因此，订阅方必须对音信的消费作念幂等处理，不可酿成肃清条音信重迭消费的情况。
MQ 事务音信决议的最大污点等于对业务具有侵入性，业务发送方需要提供回查接口。
土产货音信表土产货音信表决议发轫是由 ebay 提议的，自后通过支付宝等公司的布谈，在国内被无为使用。关于不撑抓事务音信的 MQ 则不错领受此决议，其中枢的遐想念念路等于将事务音信存储到土产货数据库中，而且音信数据的记载与业务数据的记载必须在肃清个事务内完成。将音信数据保存到 DB 之后，就不错通过一个定时任务到 DB 中去轮询问出景色为待发送的音信，然后将音信送达给 MQ，获胜收到 MQ 的 ACK 证据之后，再将 DB 中音信的景色更新或者删除音信。交互经由如下图所示：
图片
处理设施如下：
音信坐蓐者在土产货事务中处理业务更新操作，并写一条事务音信到土产货音信表，该音信的景色为待发送，业务操作和写音信表都在肃清个土产货事务中完成。定时任务束缚轮询从土产货音信表中查询出景色为待发送景色的音信，并将查出的统共音信送达到 MQ Server。MQ Server 接管到音信之后，就会将音信进行抓久化，然后复返 ACK 给到音信坐蓐者。音信坐蓐者收到了 MQ Server 的 ACK 之后，再从土产货音信表中查询出对应的音信记载，将音信的景色更新为已发送，或者顺利删除音信记载。MQ Server 复返 ACK 给到音信坐蓐者之后，接着就会将音信发送给音信消费者。音信消费者接管到音信之后，履行土产货事务，临了王老撸复返 ACK 给到 MQ Server。因为 MQ 宕机或网罗中断等原因，坐蓐者有可能会向 MQ 发送重迭音信，因此，消费者接管音信后的处理需要撑抓幂等。
该决议，比拟 MQ 事务音信决议，其优点等于弱化了对 MQ 的依赖，因为音信数据的可靠性依赖于土产货音信表，而不依赖于 MQ。还有一个优点等于容易收场。污点则是土产货音信表与业务耦合在一王人，难以作念成通用性，且音信数据与业务数据同个数据库，占用了业务系统资源。土产货音信表是基于数据库来作念的，而数据库是要读写磁盘 I/O 的，因此在高并发下是有性能瓶颈的。
最大勤勉奉告型最大勤勉奉告型亦然基于事务音信型膨胀而来的，其应用场景主要用于奉告外部的第三方系统。即是说，最大勤勉奉告型决议，主要处治的其实是跨平台、跨企业的系统间的业务交互问题。而事务音信型决议则适用于同个网罗体系的里面劳动间的分散式事务。
最大勤勉奉告型一般会引入一个奉告劳动，由奉告劳动向第三方系统发送奉告音信。其简化的经由如下图：
图片
奉告劳动与第三方系统之间的交互一般是奉告劳动通过调用第三方系统的接口完成的，发送的奉告音信不错允许丢失。
奉告劳动会提供递增多挡位时辰隔断(5min、10min、30min、1h、24h)，用于失败重试调用第三方系统的接口。在奉告 N 次之后就不再奉告，这等于所谓的最大勤勉奉告，N 次奉告之后都失败的话，那就需要报警+记日记+东谈主工介入了。
因为奉告劳动可能会屡次调用第三方系统，是以第三方系统提供的接口就需要作念幂等处理。
奉告劳动还需要有按时校验机制，对业务数据进行兜底，防患第三方无法履行包袱时进行业务回滚，确保数据最终一致性。
如何选型至此，不错处治分散式事务问题的决议咱们基本都讲了个遍，那要把分散式事务落地到咱们的交往系统中，应该如何选型呢？咱们将每种决议先作念个对比吧，看下表：
属性
XA/2PC
TCC
Saga
MQ事务音信
土产货音信表
最大勤勉奉告型
事务一致性
强
中
弱
弱
弱
弱
性能
低
中
高
高
高
高
业务侵入性
小
大
小
中
中
中
复杂性
中
高
中
低
低
低
爱戴老本
低
高
中
中
低
中
而具体如何选型，其实如故需要把柄场景而定。在第一篇著作就说过，咱们应该由场景驱动架构，离开场景谈架构等于耍流氓。
如果是要处治和外部第三方系统的业务交互，比如交往系统对接了第三方支付系统，那咱们就只可选择最大勤勉奉告型。
如果对强一致性有刚性要求的短事务，对高性能和高并发则没要求的场景，那不错琢磨用 XA/2PC，如果是用 Java 的话，那落地收场不错顺利用 Seata 框架的 XA 时势。
欧美性爱如果对一致性要求高，实时性要求也高，履行时辰详情且较短的场景，就比较恰当用 TCC，比如用在互联网金融的交往、支付、账务事务。落地收场如果是 Java 也建议不错顺利用 Seata 的 TCC 时势。
Saga 则恰当于业务场景事务并发操作肃清资源较少的情况，因为 Saga 自身不可保证禁绝性。而且，Saga 莫得预留资源的动作，是以抵偿动作最好亦然容易处理的场景。
MQ 事务音信和土产货音信表决议适用于异步事务，对一致性的要求比较低，业务上能容忍较万古辰的数据不一致，事务触及的参与方和参与过错也较少，且业务上还有对账/校验系统兜底。如果系统顶用到了 RocketMQ，那就不错琢磨用 MQ 事务音信决议，因为 MQ 事务音信决议现在只须 RocketMQ 撑抓。不然，那就琢磨用土产货音信表决议。
其实，还有一个选型，等于业务逃匿，真谛等于说不错从业务上稍作治愈，从而逃匿掉分散式事务，这是处治分散式事务问题最优雅的决议，莫得之一。业务逃匿，骨子上等于隐匿掉问题自身，需要换位念念考，跳出惯性念念维从不同维度去念念考处治问题的决议，未必候可能还会葬送一些业务脾气。不外，履行情况却是，大部分场景下很难作念到业务逃匿，那只可老古道实地处治分散式事务问题。
另外，有些履行场景还具有荒芜性，这时候就不可顺利套用上头的说法，而要把柄具体场景而治愈决议。比如，具体到咱们的交往系统，咱们来望望下单这个业务的分散式事务处理决议。
下单其实存在三个设施：
创建订单；冻结用户的金钱账户余额；将订单送达给到撮合引擎进行撮合。下单事务的发起方是交往劳动，第一步亦然在交往劳动完成的，而第二步应该是在大家劳动完成的——因为咱们还莫得将账户劳动抽离出来——第三步则是通过 MQ 将订单送达给到撮合引擎。
从上头提到的场景分类来说，咱们的交往场景属于互联网金融的交旧事务，那比较恰当用 TCC，但临了一步又是异步事务，这又该如何选呢？其实，前两步用 TCC 保证同步事务的一致性，而第三步用土产货音信表来异步确保音信的可靠送达，这么的处理是不错的。但必须前两步的事务履行获胜后，才把音信写入音信表。而撮合引擎行为 MQ 的消费者，就需要作念幂等处理了。
因此，一个事务未必候并非就只可用一种单一的决议，不错组合，不错演变的。分散式事务问题之是以复杂，最压根的原因也在此，履行场景远比表面复杂多变。
归来咱们用了很长的篇幅磨真金不怕火了分散式事务的多样处治决议，从 ACID 讲起，再讲了 XA、2PC、TCC、Saga、MQ 事务音信、土产货音信表、最大勤勉奉告型，临了对统共决议作念了汇总的对比，以及面目了适用的场景。不外，分散式事务的话题还远不是这一篇著作就能说得完的，因为篇幅所限，许多遐想细节也没张开，而且更具体的落地收场还会更复杂。另外，如果系统的缔造话语不是 Java 的话，那大致率是需要我方来收场处治分散式事务的。
临了，我上头所说的不一建都是对的，如果有食言或遗漏的所在，迎接留言并指出。
本站仅提供存储劳动，统共内容均由用户发布，如发现存害或侵权内容，请点击举报。