1 事务概念

在分布式系统中，为了保证数据的高可用，通常，咱们会将数据保留多个正本(replica)，这些正本会搁置在不同的物理的机器上。为了对用户提供正确的 CRUD 等语义，咱们须要保障这些搁置在不同物理机器上的正本是统一的。分布式事务在当初遍地都是分布式部署的零碎中简直是必要的。

咱们的我的项目用到了数据库，也和事务无关，咱们先剖析一下我的项目的问题，再形容一下事务。

如上图，如果用户打车胜利，须要批改司机状态、下单、记录领取日志，而每个操作都是调用了不同的服务，比方此时hailtaxi-driver服务执行胜利了，然而hailtaxi-order有可能执行失败了，这时候如何实现跨服务事务回滚呢？这就要用到分布式事务。

1.1 事务简介

事务(Transaction)是拜访并可能更新数据库中各种数据项的一个程序执行单元(unit)。在关系数据库中，一个事务由一组SQL语句组成。事务应该具备4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID个性。

原子性（atomicity）：事务是一个不可分割的工作单位，事务中包含的诸操作要么都做，要么都不做。

一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被察看到的。

隔离性（isolation）：一个事务的执行不能被其余事务烦扰。即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可反复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。

持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。接下来的其余操作或故障不应该对其有任何影响。

任何事务机制在实现时，都应该思考事务的ACID个性，包含：本地事务、分布式事务，及时不能都很好的满足，也要思考反对到什么水平。

1.2 本地事务

大多数场景下，咱们的利用都只须要操作繁多的数据库，这种状况下的事务称之为本地事务(Local Transaction)。本地事务的ACID个性是数据库间接提供反对。本地事务利用架构如下所示：

很多java利用都整合了spring，并应用其申明式事务管理性能来实现事务性能。个别应用的步骤如下：

1、配置事务管理器。spring提供了一个PlatformTransactionManager接口，其有2个重要的实现类：

DataSourceTransactionManager:用于反对本地事务,事实上,其外部也是通过操作java.sql.Connection来开启、提交和回滚事务。

JtaTransactionManager：用于反对分布式事务，其实现了JTA标准，应用XA协定进行两阶段提交。须要留神的是，这只是一个代理，咱们须要为其提供一个JTA provider，个别是Java EE容器提供的事务协调器(Java EE server's transaction coordinator)，也能够不依赖容器，配置一个本地的JTA provider。

2、 在须要开启的事务的bean的办法上增加@Transitional注解

能够看到，spring除了反对本地事务，也反对分布式事务，上面咱们先对分布式事务的典型利用场景进行介绍。

1.3 分布式事务

当下互联网倒退热火朝天，绝大部分公司都进行了数据库拆分和服务化(SOA)。在这种状况下，实现某一个业务性能可能须要横跨多个服务，操作多个数据库。这就波及到到了分布式事务，用须要操作的资源位于多个资源服务器上，而利用须要保障对于多个资源服务器的数据的操作，要么全副胜利，要么全副失败。实质上来说，分布式事务就是为了保障不同资源服务器的数据一致性。

1.3.1 跨库事务

跨库事务指的是，一个利用某个性能须要操作多个库，不同的库中存储不同的业务数据。下图演示了一个服务同时操作2个库的状况：

1.3.2 分库分表事务

通常一个库数据量比拟大或者预期将来的数据量比拟大，都会进行程度拆分，也就是分库分表。如下图，将数据库B拆分成了2个库：

对于分库分表的状况，个别开发人员都会应用一些数据库中间件来升高sql操作的复杂性。如，对于sql：insert into user(id,name) values (1,"gupaoedu"),(2,"gpvp")。这条sql是操作单库的语法，单库状况下，能够保障事务的一致性。

然而因为当初进行了分库分表，开发人员心愿将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，别离插入两个不同的分库，此时要保障两个库要不都胜利，要不都失败，因而基本上所有的数据库中间件都面临着分布式事务的问题。

1.3.3 跨利用事务

微服务架构是目前一个比拟一个比拟火的概念。例如下面提到的一个案例，某个利用同时操作了9个库，这样的利用业务逻辑必然非常复杂，对于开发人员是极大的挑战，应该拆分成不同的独立服务，以简化业务逻辑。拆分后，独立服务之间通过RPC框架来进行近程调用，实现彼此的通信。下图演示了一个3个服务之间彼此调用的架构：

Service A实现某个性能须要间接操作数据库，同时须要调用Service B和Service C，而Service B又同时操作了2个数据库，Service C也操作了一个库。须要保障这些跨服务的对多个数据库的操作要不都胜利，要不都失败，实际上这可能是最典型的分布式事务场景。

上述探讨的分布式事务场景中，无一例外的都间接或者间接的操作了多个数据库。如何保障事务的ACID个性，对于分布式事务实现计划而言，是十分大的挑战。同时，分布式事务实现计划还必须要思考性能的问题，如果为了严格保障ACID个性，导致性能重大降落，那么对于一些要求疾速响应的业务，是无奈承受的。

2 分布式实践

分布式事务能够有多种分类，比方柔性事务和强一致性事务，这些事务操作会遵循肯定的定理，比方CAP原理、BASE实践。

2.1 CAP原理

CAP 定理又被称作布鲁尔定理，是加州大学的计算机科学家布鲁尔在 2000 年提出的一个猜测。2002 年，麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜测的证实，使之成为分布式计算畛域公认的一个定理。

布鲁尔在提出CAP猜测时并没有具体定义 Consistency、Availability、Partition Tolerance 这3个词的含意，不同材料的具体定义也有差异，为了更好地解释，上面抉择Robert Greiner的文章《CAP Theorem》作为参考根底。

CAP定理是这样形容的：在一个分布式系统（指相互连贯并共享数据的节点的汇合）中，当波及读写操作时，只能保障一致性（Consistence）、可用性（Availability）、分区容错性（PartitionTolerance）三者中的两个，另外一个必须被就义。

Consistency、Availability、Partition Tolerance具体解释如下：

C-Consistency 一致性

A read is guaranteed to return the most recent write for a given client.
对某个指定的客户端来说，读操作保障可能返回最新的写操作后果。

这里并不是强调同一时刻领有雷同的数据，对于零碎执行事务来说，在事务执行过程中，零碎其实处于一个不统一的状态，不同的节点的数据并不完全一致。

一致性强调客户端读操作可能获取最新的写操作后果，是因为事务在执行过程中，客户端是无奈读取到未提交的数据的，只有等到事务提交后，客户端能力读取到事务写入的数据，而如果事务失败则会进行回滚，客户端也不会读取到事务两头写入的数据。

A-Availability 可用性

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
非故障的节点在正当的工夫内返回正当的响应（不是谬误和超时的响应）。

这里强调的是正当的响应，不能超时，不能出错。留神并没有说“正确”的后果，例如，应该返回 100 但实际上返回了 90，必定是不正确的后果，但能够是一个正当的后果。

P-Partition Tolerance 分区容忍性

The system will continue to function when network partitions occur.
当呈现网络分区后，零碎可能持续“履行职责”。

这里网络分区是指：
一个分布式系统外面，节点组成的网络原本应该是连通的。然而可能因为一些故障（节点间网络连接断开、节点宕机），使得有些节点之间不连通了，整个网络就分成了几块区域，数据就分布在了这些不连通的区域中。

CAP 的抉择

尽管 CAP 实践定义是三个因素中只能取两个，但放到分布式环境下来思考，咱们会发现必须抉择 P（分区容忍）因素，因为网络自身无奈做到 100% 牢靠，有可能出故障，所以分区是一个必然的景象。

为什么必须要抉择P:

如果咱们抉择了 CA（一致性 + 可用性） 而放弃了 P（分区容忍性），那么当产生分区景象时，为了保障 C（一致性），零碎须要禁止写入，当有写入申请时，零碎返回 error（例如，以后零碎不容许写入），这又和 A(可用性) 抵触了，因为 A（可用性）要求返回 no error 和 no timeout。

因而，分布式系统实践上不可能抉择 CA （一致性 + 可用性）架构，只能抉择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中抉择。

针对这两种抉择再来看一下：

1、CP - Consistency + Partition Tolerance （一致性 + 分区容忍性）

如上图所示，因为Node1节点和Node2节点连贯中断导致分区景象，Node1节点的数据曾经更新到y，然而Node1 和 Node2 之间的复制通道中断，数据 y 无奈同步到 Node2，Node2 节点上的数据还是旧数据x。

这时客户端C 拜访 Node2 时，Node2 须要返回 Error，提醒客户端 “零碎当初产生了谬误”，这种解决形式违
背了可用性（Availability）的要求，因而 CAP 三者只能满足 CP。

2、AP - Availability + Partition Tolerance （可用性 + 分区容忍性）

同样是Node2 节点上的数据还是旧数据x，这时客户端C 拜访 Node2 时，Node2 将以后本人领有的数据 x 返回给客户端 了，而实际上以后最新的数据曾经是 y 了，这就不满足一致性（Consistency）的要求了，因而 CAP 三者只能满足 AP。

留神：这里 Node2 节点返回 x，尽管不是一个“正确”的后果，然而一个“正当”的后果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据。

值得补充的是：，CAP实践通知咱们分布式系统只能抉择AP或者CP，但实际上并不是说整个零碎只能抉择AP或者CP，在 CAP 实践落地实际时，咱们须要将零碎内的数据依照不同的利用场景和要求进行分类，每类数据抉择不同的策略（CP 还是 AP），而不是间接限定整个零碎所有数据都是同一策略。

另外，只能抉择CP或者AP是指零碎产生分区景象时无奈同时保障C（一致性）和A（可用性），但不是意味着什么都不做，当分区故障解决后，零碎还是要放弃保障CA。也就是说选了AP不意味着放弃了C，选了CP不意味着放弃了A

2.2 BASE实践

BASE 是指根本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），是基于CAP定理演变而来，是对CAP中一致性和可用性衡量的后果；核心思想是即便无奈做到强一致性（CAP 的一致性就是强一致性），但利用能够采纳适宜的形式达到最终一致性。

BA-Basically Available根本可用

分布式系统在呈现故障时，容许损失局部可用性，即保障外围可用。

这里的关键词是“局部”和“外围”，理论实际上，哪些是外围须要依据具体业务来衡量。例如登录性能绝对注册性能更加外围，注册不了最多影响散失一部分用户，如果用户曾经注册但无奈登录，那就象征用户无奈应用零碎，造成的影响范畴更大。

S-Soft State 软状态

容许零碎存在中间状态，而该中间状态不会影响零碎整体可用性。这里的中间状态就是 CAP 实践中的数据不统一。

E-Eventual Consistency 最终一致性

零碎中的所有数据正本通过肯定工夫后，最终可能达到统一的状态。

这里的关键词是“肯定工夫” 和 “最终”，“肯定工夫”和数据的个性是强关联的，不同业务不同数据可能容忍的不统一工夫是不同的。例如领取类业务是要求秒级别内达到统一，因为用户时时关注；用户发的最新微博，能够容忍30分钟内达到统一的状态，因为用户短时间看不到明星发的微博是无感知的。而“最终”的含意就是不论多长时间，最终还是要达到一致性的状态。

BASE 实践实质上是对 CAP 的延长和补充，更具体地说，是对 CAP 中 AP 计划的一个补充：

  • CP 实践是疏忽延时的，而理论利用中延时是无奈防止的。

    这一点就意味着完满的 CP 场景是不存在的，即便是几毫秒的数据复制提早，在这几毫秒工夫距离内，零碎是不合乎 CP 要求的。因而 CAP 中的 CP 计划，实际上也是实现了最终一致性，只是“肯定工夫”是指几毫秒而已。

  • AP 计划中就义一致性只是指产生分区故障期间，而不是永远放弃一致性。

    这一点其实就是 BASE 实践延长的中央，分区期间就义一致性，但分区故障复原后，零碎应该达到最终一致性。

2.3 刚柔事务

何谓刚柔事务？刚性事务它的事务是原子的，要么都胜利要么都失败，也就是须要保障ACID实践，而柔性事务只须要保障数据最终统一即可，须要遵循BASE实践。

  • 刚性事务满足ACID实践
  • 柔性事务满足BASE实践（根本可用，最终统一）
基于BASE实践的设计思维，柔性事务下，在不影响零碎整体可用性的状况下(Basically Available 根本可用)，容许零碎存在数据不统一的中间状态(Soft State 软状态)，在通过数据同步的延时之后，最终数据可能达到统一。并不是齐全放弃了ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。

3 罕用事务解决方案模型

分布式事务解决方案简直都是柔性事务，分布式事务的实现有许多种，其中较经典是由Tuxedo提出的XA分布式事务协定，XA协定蕴含二阶段提交（2PC）和三阶段提交（3PC）两种实现。

其余还有 TCC、MQ 等最终一致性解决方案，至于工作中用哪种计划，须要依据业务场景选取，2PC/3PC、TCC数据强一致性高，而MQ是最终数据统一。

3.1 DTP模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的规范，也就是了定义了标准和API接口，由厂商进行具体的实现

X/Open DTP中的角色

AP(Application Program)：应用程序，次要是定义事务边界以及那些组成事务的特定于应用程序的操作。

RM(Resouces Manager)：资源管理器，治理一些共享资源的自治域，如提供对诸如数据库之类的共享资源的拜访。譬如：数据库、文件系统等，并且提供了这些资源的拜访形式。

TM(Transaction Manager)：事务管理器，治理全局事务，协调事务的提交或者回滚，并协调故障复原。

DTP模型外面定义了XA协定接口，TM 和 RM 通过XA接口进行双向通信

3.2 2PC

2PC、3PC，都是基于 XA 协定的

计划简介

二阶段提交协定（Two-phase Commit，即2PC）是罕用的分布式事务解决方案，行将事务的提交过程分为两个阶段来进行解决：筹备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。

在分布式系统里，每个节点都能够通晓本人操作的胜利或者失败，却无奈晓得其余节点操作的胜利或失败。当一个事务跨多个节点时，为了放弃事务的原子性与一致性，而引入一个协调者来对立掌控所有参与者的操作后果，并批示它们是否要把操作后果进行真正的提交或者回滚（rollback）。

二阶段提交的算法思路能够概括为：参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈情报决定各参与者是否要提交操作还是停止操作。

核心思想就是对每一个事务都采纳先尝试后提交的解决形式，解决后所有的读操作都要能取得最新的数据，因而也能够将二阶段提交看作是一个强一致性算法。

解决流程

简略一点了解，能够把协调者节点比喻为带头大哥，参与者了解比喻为跟班小弟，带头大哥对立协调跟班小弟的工作执行。
阶段1：筹备阶段
  • 1、协调者向所有参与者发送事务内容，询问是否能够提交事务，并期待所有参与者回答。
  • 2、各参与者执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
  • 3、如参与者执行胜利，给协调者反馈yes，即能够提交；如执行失败，给协调者反馈no，即不可提交。
阶段2：提交阶段

如果协调者收到了参与者的失败音讯或者超时，间接给每个参与者发送回滚(rollback)音讯；否则，发送提交(commit)音讯；参与者依据协调者的指令执行提交或者回滚操作，开释所有事务处理过程中应用的锁资源。(留神:必须在最初阶段开释锁资源)
接下来分两种状况别离探讨提交阶段的过程。

状况1，当所有参与者均反馈yes，提交事务：

  • 1、协调者向所有参与者收回正式提交事务的申请（即commit申请）。
  • 2、参与者执行commit申请，并开释整个事务期间占用的资源。
  • 3、各参与者向协调者反馈ack(应答)实现的音讯。
  • 4、协调者收到所有参与者反馈的ack音讯后，即实现事务提交。

状况2，当任何阶段1一个参与者反馈no，中断事务：

  • 1、协调者向所有参与者收回回滚申请（即rollback申请）。
  • 2、参与者应用阶段1中的undo信息执行回滚操作，并开释整个事务期间占用的资源。
  • 3、各参与者向协调者反馈ack实现的音讯。
  • 4、协调者收到所有参与者反馈的ack音讯后，即实现事务中断。

计划总结

2PC是一个强一致性的同步阻塞协定，事务执⾏过程中须要将所需资源全副锁定，也就是俗称的 刚性事务

2PC计划实现起来简略，理论我的项目中应用比拟少，次要因为以下问题：

  • 性能问题
    所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
  • 可靠性问题
    如果协调者存在单点故障问题，如果协调者呈现故障，参与者将始终处于锁定状态。
  • 数据一致性问题
    在阶段2中，如果产生部分网络问题，一部分事务参与者收到了提交音讯，另一部分事务参与者没收到提交音讯，那么就导致了节点之间数据的不统一。

  • 只实用于单个服务中

    因为应用了XA标准，只反对单体服务的跨库分布式事务，不反对跨服务间的分布式事务

3.3 3PC

计划简介

三阶段提交协定，是二阶段提交协定的改良版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制（2PC 中只有协调者有超时机制）。

三阶段提交将二阶段的筹备阶段拆分为2个阶段，插入了一个preCommit阶段，使得原先在二阶段提交中，参与者在筹备之后，因为协调者产生解体或谬误，而导致参与者处于无奈通晓是否提交或者停止的“不确定状态”所产生的可能相当长的延时的问题得以解决。

解决流程

阶段1：canCommit

协调者向参与者发送commit申请，参与者如果能够提交就返回yes响应(参与者不执行事务操作)，否则返回no响应：

  • 1、协调者向所有参与者收回蕴含事务内容的canCommit申请，询问是否能够提交事务，并期待所有参与者回答。
  • 2、参与者收到canCommit申请后，如果认为能够执行事务操作，则反馈yes并进入准备状态，否则反馈no。
阶段2：preCommit

协调者依据阶段1 canCommit参与者的反馈状况来决定是否能够基于事务的preCommit操作。依据响应状况，有以下两种可能。

状况1，阶段1所有参与者均反馈yes，参与者预执行事务：

  • 1、协调者向所有参与者收回preCommit申请，进入筹备阶段。
  • 2、参与者收到preCommit申请后，执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
  • 3、各参与者向协调者反馈ack响应或no响应，并期待最终指令。

状况2，阶段1任何一个参与者反馈no，或者期待超时后协调者尚无奈收到所有参与者的反馈，即中断事务:

  • 1、协调者向所有参与者收回abort申请。
  • 2、无论收到协调者收回的abort申请，或者在期待协调者申请过程中呈现超时，参与者均会中断事务。
阶段3：do Commit
该阶段进行真正的事务提交，也能够分为以下两种状况：

状况1：阶段2所有参与者均反馈ack响应，执行真正的事务提交：

  • 1、如果协调者处于工作状态，则向所有参与者收回do Commit申请。
  • 2、参与者收到do Commit申请后，会正式执行事务提交，并开释整个事务期间占用的资源。
  • 3、各参与者向协调者反馈ack实现的音讯。
  • 4、协调者收到所有参与者反馈的ack音讯后，即实现事务提交。

阶段2任何一个参与者反馈no，或者期待超时后协调者尚无奈收到所有参与者的反馈，即中断事务：

  • 1、如果协调者处于工作状态，向所有参与者收回abort申请。
  • 2、参与者应用阶段1中的undo信息执行回滚操作，并开释整个事务期间占用的资源。
  • 3、各参与者向协调者反馈ack实现的音讯。
  • 4、协调者收到所有参与者反馈的ack音讯后，即实现事务中断

留神：进入阶段3后，无论协调者呈现问题，或者协调者与参与者网络呈现问题，都会导致参与者无奈接管到协调者收回的do Commit申请或abort申请。此时，参与者都会在期待超时之后，继续执行事务提交。

阶段三 只容许胜利不容许失败，如果服务器宕机或者停电，因为记录的阶段二的数据，重启服务后在提交事务，所以，到了阶段三，失败了也不进行回滚，只容许胜利。

计划总结

长处

相比二阶段提交，三阶段提交升高了阻塞范畴，在期待超时后协调者或参与者会中断事务。防止了协调者单点问题，阶段3中协调者呈现问题时，参与者会持续提交事务。

毛病

数据不统一问题仍然存在，当在参与者收到preCommit申请后期待do commite指令时，此时如果协调者申请中断事务，而协调者无奈与参与者失常通信，会导致参与者持续提交事务，造成数据不统一。

3.4 TCC

计划简介

TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC是服务化的二阶段编程模型，其Try、Confirm、Cancel 3个办法均由业务编码实现；

  • Try操作作为一阶段，负责资源的检查和预留。
  • Confirm操作作为二阶段提交操作，执行真正的业务。
  • Cancel是预留资源的勾销。

TCC事务的Try、Confirm、Cancel能够了解为SQL事务中的Lock、Commit、Rollback。

TCC 为在业务层编写代码实现的两阶段提交。TCC 别离指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个办法。

解决流程

为了不便了解，上面以电商下单为例进行计划解析，这里把整个过程简略分为扣减库存，订单创立2个步骤，库存服务和订单服务别离在不同的服务器节点上。
阶段1：Try 阶段

从执行阶段来看，与传统事务机制中业务逻辑雷同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起能力真正形成一个残缺的业务逻辑，这个阶段次要实现：

  • 实现所有业务查看( 一致性 )
  • 预留必须业务资源( 准隔离性 )
  • Try 尝试执行业务
    TCC事务机制以初步操作（Try）为核心的，确认操作（Confirm）和勾销操作（Cancel）都是围绕初步操作（Try）而开展。因而，Try阶段中的操作，其保障性是最好的，即便失败，依然有勾销操作（Cancel）能够将其执行后果撤销。

假如商品库存为100，购买数量为2，这里检查和更新库存的同时，解冻用户购买数量的库存，同时创立订单，订单状态为待确认。
阶段2：Confirm / Cancel 阶段
依据Try阶段服务是否全副失常执行，继续执行确认操作（Confirm）或勾销操作（Cancel）。
Confirm和Cancel操作满足幂等性，如果Confirm或Cancel操作执行失败，将会一直重试直到执行实现。
Confirm：确认
当Try阶段服务全副失常执行， 执行确认业务逻辑操作

这里应用的资源肯定是Try阶段预留的业务资源。在TCC事务机制中认为，如果在Try阶段能失常的预留资源，那Confirm肯定能残缺正确的提交。Confirm阶段也能够看成是对Try阶段的一个补充，Try+Confirm一起组成了一个残缺的业务逻辑。
Cancel：勾销
当Try阶段存在服务执行失败， 进入Cancel阶段

Cancel勾销执行，开释Try阶段预留的业务资源，下面的例子中，Cancel操作会把解冻的库存开释，并更新订单状态为勾销。

计划总结

TCC事务机制绝对于传统事务机制（X/Open XA），TCC事务机制相比于下面介绍的XA事务机制，有以下长处:

  • 性能晋升
    具体业务来实现管制资源锁的粒度变小，不会锁定整个资源。
  • 数据最终一致性
    基于Confirm和Cancel的幂等性，保障事务最终实现确认或者勾销，保证数据的一致性。
  • 可靠性
    解决了XA协定的协调者单点故障问题，由主业务方发动并管制整个业务流动，业务流动管理器也变成多点，引入集群。

毛病：
TCC的Try、Confirm和Cancel操作性能要按具体业务来实现，业务耦合度较高，进步了开发成本。

3.5 本地音讯表

计划简介

本地音讯表的计划最后是由ebay提出，外围思路是将分布式事务拆分老本地事务进行解决。

计划通过在事务被动发起方额定新建事务音讯表，事务发起方解决业务和记录事务音讯在本地事务中实现，轮询事务音讯表的数据发送事务音讯，事务被动方基于消息中间件生产事务音讯表中的事务。

这样设计能够防止”业务解决胜利 + 事务音讯发送失败“，或”业务解决失败 + 事务音讯发送胜利“的辣手状况呈现，保障2个零碎事务的数据一致性。

解决流程

上面把分布式事务最先开始解决的事务方成为事务被动方，在事务被动方之后解决的业务内的其余事务成为事务被动方。

为了不便了解，上面持续以电商下单为例进行计划解析，这里把整个过程简略分为扣减库存，订单创立2个步骤，库存服务和订单服务别离在不同的服务器节点上，其中库存服务是事务被动方，订单服务是事务被动方。

事务的被动方须要额定新建事务音讯表，用于记录分布式事务的音讯的产生、解决状态。

整个业务解决流程如下：

步骤1 事务被动方解决本地事务。
事务被动方在本地事务中解决业务更新操作和写音讯表操作。
下面例子中库存服务阶段在本地事务中实现扣减库存和写音讯表(图中1、2)。

步骤2 事务被动方通过消息中间件，告诉事务被动方处理事务告诉事务待音讯。
消息中间件能够基于Kafka、RocketMQ音讯队列，事务被动办法被动写音讯到音讯队列，事务生产方生产并解决音讯队列中的音讯。
下面例子中，库存服务把事务待处理音讯写到消息中间件，订单服务生产消息中间件的音讯，实现新增订单（图中3 - 5）。

步骤3 事务被动方通过消息中间件，告诉事务被动方事务已解决的音讯。
下面例子中，订单服务把事务已解决音讯写到消息中间件，库存服务生产中间件的音讯，并将事务音讯的状态更新为已实现(图中6 - 8)

为了数据的一致性，当处理错误须要重试，事务发送方和事务接管方相干业务解决须要反对幂等。具体保留一致性的容错解决如下：

1、当步骤1解决出错，事务回滚，相当于什么都没产生。

2、当步骤2、步骤3解决出错，因为未解决的事务音讯还是保留在事务发送方，事务发送方能够定时轮询为超时音讯数据，再次发送的消息中间件进行解决。事务被动方生产事务音讯重试解决。

3、如果是业务上的失败，事务被动方能够发消息给事务被动方进行回滚。

4、如果多个事务被动方曾经生产音讯，事务被动方须要回滚事务时须要告诉事务被动方回滚。

计划总结

计划的长处如下：

  • 从利用设计开发的角度实现了音讯数据的可靠性，音讯数据的可靠性不依赖于消息中间件，弱化了对MQ中间件个性的依赖。
  • 计划轻量，容易实现。

毛病如下：

  • 与具体的业务场景绑定，耦合性强，不可专用。
  • 音讯数据与业务数据同库，占用业务系统资源。
  • 业务零碎在应用关系型数据库的状况下，音讯服务性能会受到关系型数据库并发性能的局限

3.6 MQ事务

MQ事务保障最终一致性。

计划简介

基于MQ的分布式事务计划其实是对本地音讯表的封装，将本地音讯表存于MQ 外部，其余方面的协定根本与本地音讯表统一。

解决流程

上面次要基于RocketMQ4.3之后的版本介绍MQ的分布式事务计划。

在本地音讯表计划中，保障事务被动方发写业务表数据和写音讯表数据的一致性是基于数据库事务，RocketMQ的事务音讯绝对于一般MQ，绝对于提供了2PC的提交接口，计划如下：

失常状况——事务被动方发消息

这种状况下，事务被动方服务失常，没有产生故障，发消息流程如下：

1、发送方向 MQ服务端(MQ Server)发送half音讯。

2、MQ Server 将音讯长久化胜利之后，向发送方 ACK 确认音讯曾经发送胜利。

3、发送方开始执行本地事务逻辑。

4、发送方依据本地事务执行后果向 MQ Server 提交二次确认（commit 或是 rollback）。

5、MQ Server 收到 commit 状态则将半音讯标记为可投递，订阅方最终将收到该音讯；MQ Server 收到 rollback 状态则删除半音讯，订阅方将不会承受该音讯。

异常情况——事务被动方音讯复原

在断网或者利用重启等异常情况下，图中第4步提交的二次确认超时未达到 MQ Server，此时解决逻辑如下：

  • 5、MQ Server 对该音讯发动音讯回查。
  • 6、发送方收到音讯回查后，须要查看对应音讯的本地事务执行的最终后果。
  • 7、发送方依据查看失去的本地事务的最终状态再次提交二次确认
  • 8、MQ Server基于commit / rollback 对音讯进行投递或者删除

介绍完RocketMQ的事务音讯计划后，因为后面曾经介绍过本地音讯表计划，这里就简略介绍RocketMQ分布式事务：

事务被动方基于MQ通信告诉事务被动方处理事务，事务被动方基于MQ返回处理结果。
如果事务被动方生产音讯异样，须要一直重试，业务解决逻辑须要保障幂等。
如果是事务被动方业务上的解决失败，能够通过MQ告诉事务被动方进行弥补或者事务回滚。

计划总结

相比本地音讯表计划，MQ事务计划长处是：

  • 音讯数据独立存储 ，升高业务零碎与音讯零碎之间的耦合。
  • 吞吐量优于应用本地音讯表计划。

毛病是：

  • 一次音讯发送须要两次网络申请(half音讯 + commit/rollback音讯)
  • 业务解决服务须要实现音讯状态回查接口

本文由传智教育博学谷 - 狂野架构师教研团队公布，转载请注明出处！

如果本文对您有帮忙，欢送关注和点赞；如果您有任何倡议也可留言评论或私信，您的反对是我保持创作的能源