大家好，我是老三，上次发文的时候还是上次发文的时候，这篇文章分享分布式事务，看完要是你们不懂，那肯定是不明确。

从本地事务到分布式事务

事务大家应该都晓得，事务将一组操作纳入到一个不可分割的执行单元，这个执行单元里的操作都胜利时能力提交胜利。

简略地说，事务提供一种要么不做，要么全做机制。

ACID

咱们先简略理解一下事务的四大个性：

• A 原子性(Atomicity)

一个事务(transaction)中的所有操作，要么全副实现，要么全副不实现，不会呈现局部胜利局部失败的状况。。

• C 一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务胜利地实现，那么零碎中所有变动将正确地利用，零碎处于无效状态。如果在事务中呈现谬误，那么零碎中的所有变动将主动地回滚，零碎返回到原始状态。

• I 隔离性(Isolation)

指的是在并发环境中，当不同的事务同时操纵雷同的数据时，每个事务都有各自的残缺数据空间。由并发事务所做的批改必须与任何其余并发事务所做的批改隔离。事务查看数据更新时，数据所处的状态要么是另一事务批改它之前的状态，要么是另一事务批改它之后的状态，事务不会查看到中间状态的数据。

• D 持久性(Durability)

指的是只有事务胜利完结，它对数据库所做的更新就必须永恒保留下来。即便产生零碎解体，重新启动数据库系统后，数据库还能复原到事务胜利完结时的状态。

单体事务

在单体架构时代，所有的业务只用一个数据库。

单体架构时代事务的是实现很简略，咱们操作的是同一个数据库，利用数据库自身提供的事务机制反对就能够了。

例如咱们比拟相熟的MySQL数据库：

• 事务的隔离性是通过数据库锁的机制实现的。
• 事务的一致性由undo log来保障：undo log是逻辑日志，记录了事务的insert、update、deltete操作，回滚的时候做相同的delete、update、insert操作来复原数据。
• 事务的原子性和一持久性由redo log来保障：redolog被称作重做日志，是物理日志，事务提交的时候，必须先将事务的所有日志写入redo log长久化，到事务的提交操作才算实现。

具体理解倡议浏览《MySQL技术底细 InnoDB存储引擎》7.2节。

分布式事务

随着业务倒退，单体架构顶不住了，缓缓进入分布式时代——SOA或者粒度更细的微服务。

当然随同而来的就是分库分表。

• 咱们可能会依据业务服务拆分的形式，对应地垂直拆分大库，例如原始大库拆分成订单库、商品库、领取库。
• 同时因为业务数据可能会高速减少，很快就成了亿级，咱们不得不又程度分库，来加重单个数据库的压力。

不论是怎么分库的，最初的后果就是咱们一个操作可能要横跨多个数据库。

数据库自身的事务机制只能保障它本人这个库的事务，然而没法保障到其它的库。咱们要保障跨多个库的操作还具备事务的个性，就不得不上分布式事务了。

在后面 分布式必备实践根底：CAP和BASE 里，讲了分布式的实践根底——CAP和BASE，这里就不再多讲。

咱们只须要晓得，BASE实践是对CAP中AP的一个延申，在没法保障强一致性的前提下，尽可能达到最终的一致性。

咱们的分布式事务通常也做不到本地事务那么强的一致性，个别都是对一致性(Consistency)适当做了一些放宽，只须要达到最终的一致性。

分布式事务解决方案

XA /2PC两阶段提交

XA

XA是一个分布式事务协定，由Tuxedo提出。

在这个协定里，有三个角色：

• AP（Application）：利用零碎（服务）
• TM（Transaction Manager）：事务管理器（全局事务管理）
• RM（Resource Manager）：资源管理器（数据库）

XA标准次要定义了 事务管理器（Transaction Manager）和资源管理器（Resource Manager）之间的接口。

XA协定采纳两阶段提交形式来治理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。

2PC 两阶段提交

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

两阶段提交的两个阶段：第一阶段：筹备阶段，第二阶段：提交阶段

![两阶段-参考[2]](https://gitee.com/sanfene/pic…)

筹备阶段 Prepares

协调者向所有参与者询问是否能够执行提交操作，所有参与者执行事务，将后果返回给协调者。

提交阶段 commit

• 如果第一阶段汇中所有参与者都返回yes响应，协调者向所有参与者收回提交申请，所有参与者提交事务
• 如果第一阶段中有一个或者多个参与者返回no响应，协调者向所有参与者收回回滚申请，所有参与者进行回滚操作

两阶段提交长处：尽量保障了数据的强统一，但不是100%统一

两阶段提交同样有一些毛病：

• 单点故障

  因为协调者的重要性，一旦协调者产生故障，参与者会始终阻塞，尤其时在第二阶段，协调者产生故障，那么所有的参与者都处于锁定事务资源的状态中，而无奈持续实现事务操作。

• 同步阻塞

  它是一个强一致性的同步阻塞协定，也就是所谓刚性事务，事务执⾏过程中须要将所需资源全副锁定，会比拟影响性能。

• 数据不统一

  在第二阶段中，当协调者想参与者发送提交事务申请之后，因为网络抖动，如果第二阶段只有局部参与者收到提交申请，那么就会导致数据不统一。

3PC 三阶段提交

三阶段提交（3PC）是二阶段提交（2PC）的一种改良版本 ，为解决两阶段提交协定的单点故障和同步阻塞问题。上边提到两阶段提交，当协调者解体时，参与者不能做出最初的抉择，就会始终放弃阻塞锁定资源。

2PC 中只有协调者有超时机制，3PC 在协调者和参与者中都引入了超时机制，协调者呈现故障后，参与者就不会始终阻塞。而且在第一阶段和第二阶段中又插入了一个预提交阶段，保障了在最初提交阶段之前各参加节点的状态是统一的。

三阶段提交的三个阶段：CanCommit，PreCommit，DoCommit三个阶段

![三阶段协定-参考[2]](https://gitee.com/sanfene/pic…)

筹备阶段 CanCommit

协调者向参与者发送commit申请，参与者如果能够提交就返回Yes响应，否则返回No响应。

预提交阶段 PreCommit

协调者依据参与者在筹备阶段的响应判断是否执行事务还是中断事务

• 如果所有参与者都返回Yes，则执行事务
• 如果参与者有一个或多个参与者返回No或者超时，则中断事务

参与者执行完操作之后返回ACK响应，同时开始期待最终指令。

提交阶段 DoCommit

协调者依据参与者在筹备阶段的响应判断是否执行事务还是中断事务

• 如果所有参与者都返回正确的ACK响应，则提交事务
• 如果参与者有一个或多个参与者收到谬误的ACK响应或者超时，则中断事务
• 如果参与者无奈及时接管到来自协调者的提交或者中断事务申请时，在期待超时之后，会持续进行事务提交

协调者收到所有参与者的ACK响应，实现事务。

能够看出，三阶段提交解决的只是两阶段提交中 单体故障和同步阻塞的问题，因为退出了超时机制，这里的超时的机制作用于 预提交阶段 和 提交阶段。如果期待 预提交申请 超时，参与者间接回到筹备阶段之前。如果等到提交申请超时，那参与者就会提交事务了。

无论是2PC还是3PC都不能保障分布式系统中的数据100%统一

TCC弥补事务

TCC Try-Confirm-Cancel 的简称，是两阶段提交的一个变种，针对每个操作，都须要有一个其对应的确认和勾销操作，当操作胜利时调用确认操作，当操作失败时调用勾销操作，相似于二阶段提交，只不过是这里的提交和回滚是针对业务上的，所以基于TCC实现的分布式事务也能够看做是对业务的一种弥补机制。

TCC的三阶段：

1. Try 阶段：对业务零碎做检测及资源预留
2. Confirm 阶段：对业务零碎做确认提交，Try阶段执行胜利并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只有Try胜利，Confirm肯定胜利
3. Cancel 阶段：在业务执行谬误，须要回滚的状态下执行的业务勾销，预留资源开释

在Try阶段，是对业务零碎进行查看及资源预览，比方订单和库存操作，须要查看库存残余数量是否够用，并进行预留，预留操作的话就是新建一个可用库存数量字段，Try阶段操作是对这个可用库存数量进行操作。

例如下单减库存的操作：

执行流程：

1. Try阶段：订单零碎将以后订单状态设置为领取中，库存零碎校验以后残余库存数量是否大于1，而后将可用库存数量设置为库存残余数量-1，
2. 如果Try阶段执行胜利，执行Confirm 阶段，将订单状态批改为领取胜利，库存残余数量批改为可用库存数量
3. 如果Try阶段执行失败，执行Cancel 阶段，将订单状态批改为领取失败，可用库存数量批改为库存残余数量

TCC 不存在资源阻塞的问题，因为每个办法都间接进行事务的提交，一旦出现异常通过则 Cancel 来进行回滚弥补，这也就是常说的补偿性事务。

然而，应用TCC，本来一个办法，当初却须要三个办法来反对，能够看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要思考到网络稳定等起因，为保障申请肯定送达都会有重试机制，所以还须要思考接口的幂等性。

本地音讯表

本地音讯表的核心思想是将分布式事务拆分老本地事务进行解决。

例如，能够在订单库新增一个音讯表，将新增订单和新增音讯放到一个事务里实现，而后通过轮询的形式去查问音讯表，将音讯推送到MQ，库存零碎去生产MQ。

执行流程：

1. 订单服务，增加一条订单和一条音讯，在一个事务里提交
2. 订单服务，应用定时工作轮询查问状态为未同步的音讯表，发送到MQ，如果发送失败，就重试发送
3. 库存服务，接管MQ音讯，批改库存表，须要保障幂等操作
4. 如果批改胜利，调用rpc接口批改订单零碎音讯表的状态为已实现或者间接删除这条音讯
5. 如果批改失败，能够不做解决，期待重试

订单服务中的音讯有可能因为业务问题会始终反复发送，所以为了防止这种状况能够记录一下发送次数，当达到次数限度之后报警，人工接入解决；库存服务须要保障幂等，防止同一条音讯被屡次生产造成数据不统一。

本地音讯表这种计划实现了最终一致性，须要在业务零碎里减少音讯表，业务逻辑中多一次插入的DB操作，所以性能会有损耗，而且最终一致性的距离次要有定时工作的间隔时间决定。

MQ音讯事务

音讯事务的原理是将两个事务通过消息中间件进行异步解耦。

订单服务执行本人的本地事务，并发送MQ音讯，库存服务接管音讯，执行本人的本地事务，乍一看，如同跟本地音讯表的实现计划相似，只是省去 了对本地音讯表的操作和轮询发送MQ的操作，但实际上两种计划的实现是不一样的。

音讯事务肯定要保障业务操作与音讯发送的一致性，如果业务操作胜利，这条音讯也肯定投递胜利。

执行流程：

1. 发送prepare音讯到消息中间件
2. 发送胜利后，执行本地事务
3. 如果事务执行胜利，则commit，消息中间件将音讯下发至生产端
4. 如果事务执行失败，则回滚，消息中间件将这条prepare音讯删除
5. 生产端接管到音讯进行生产，如果生产失败，则一直重试

音讯事务依赖于消息中间件的事务音讯，例如咱们相熟的RocketMQ就反对事务音讯（半音讯），也就是只有收到发送方确定才会失常投递的音讯。

这种计划也是实现了最终一致性，比照本地音讯表实现计划，不须要再建音讯表，对性能的损耗和业务的入侵更小。

最大致力告诉

最大致力告诉相比实现会简略一些，实用于一些最终一致性要求较低的业务，比方领取告诉，短信告诉这种业务。

以领取告诉为例，业务零碎调用领取平台进行领取，领取平台进行领取，进行操作领取之后领取平台会去同步告诉业务零碎领取操作是否胜利，如果不胜利，会始终异步重试，然而会有一个最大告诉次数，如果超过这个次数后还是告诉失败，就不再告诉，业务零碎自行调用领取平台提供一个查问接口，供业务零碎进行查问领取操作是否胜利

执行流程：

1. 业务零碎调用领取平台领取接口， 并在本地进行记录，领取状态为领取中
2. 领取平台进行领取操作之后，无论胜利还是失败，同步给业务零碎一个后果告诉
3. 如果告诉始终失败则依据重试规定异步进行重试，达到最大告诉次数后，不再告诉
4. 领取平台提供查问订单领取操作后果接口
5. 业务零碎依据肯定业务规定去领取平台查问领取后果

Saga事务

Saga事务，核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果失常完结那就失常实现，如果某个步骤失败，则依据相同程序一次调用弥补操作。

和本地事务undo log有点像，出问题了，逆向操作来解救。

Sega简介：

• Saga = Long Live Transaction (LLT，长活事务)
• LLT = T1 + T2 + T3 + … + Ti（Ti为本地短事务）
• 每个本地事务Ti 有对应的弥补 Ci

Sega的执行程序：

• 失常状况：T1 T2 T3 … Tn
• 异常情况：T1 T2 T3 C3 C2 C1

Saga两种复原策略

• 向后复原，如果任意本地子事务失败，弥补已实现的事务。如异常情况的执行程序T1 T2 Ti Ci C2 C1.
• 向前复原，即重试失败的事务，假如最初每个子事务都会胜利。执行程序：T1, T2, …, Tj(失败), Tj(重试),…, Tn。

举个例子，假如用户下订单，花50块钱购买了10瓶可乐，则有这么一些短事务和回滚操作：

T1=下订单 => T2=用户扣50块钱 => T3=用户加10瓶可乐= > T4=库存减10瓶可乐

C1=勾销订单 => C2= 给用户加50块钱 => C3 =用户减10朵玫瑰 = > C4=库存加10朵玫瑰

Seata

看了这么些事务的计划，介绍了相干的原理，然而这些原理怎么落地呢？各种各样的坑怎么解决呢？

—— 人生苦短，我用开源。

阿里巴巴开源了一套开源分布式事务解决方案——Seata。Seata可能并不称之为完满，但对代码入侵性十分小，根本环境搭建实现的话，应用的时候在只须要办法上增加一个注解@GlobalTransactional就能够开启全局事务。

Seata 也是从两段提交演变而来的一种分布式事务解决方案，提供了 AT、TCC、SAGA 和 XA 等事务模式，咱们来看一下AT模式。

Seata 中次要有这么几种角色：

TC（Transaction Coordinator）：事务协调者。治理全局的分支事务的状态，用于全局性事务的提交和回滚。

TM（Transaction Manager）：事务管理者。用于开启、提交或回滚事务。

RM（Resource Manager）：资源管理器。用于分支事务上的资源管理，向 TC 注册分支事务，上报分支事务的状态，接管 TC 的命令来提交或者回滚分支事务。

咱们看一下Seata大略的一个工作流程：

执行流程：

1. 服务A中的 TM 向 TC 申请开启一个全局事务，TC 就会创立一个全局事务并返回一个惟一的 XID
2. 服务A中的 RM 向 TC 注册分支事务，而后将这个分支事务纳入 XID 对应的全局事务管辖中
3. 服务A开始执行分支事务
4. 服务A开始近程调用B服务，此时 XID 会依据调用链流传
5. 服务B中的 RM 也向 TC 注册分支事务，而后将这个分支事务纳入 XID 对应的全局事务管辖中
6. 服务B开始执行分支事务
7. 全局事务调用解决完结后，TM 会依据有误异常情况，向 TC 发动全局事务的提交或回滚
8. TC 协调其管辖之下的所有分支事务，决定是提交还是回滚

对于Seata的应用，和更具体的原理，这里挖个坑，当前有工夫再细讲。

总结

上边简略介绍了 2PC、3PC、TCC、本地音讯表、最大致力告诉、MQ、Sega、Seata 这8种分布式事务解决方案，但不论咱们选哪一种计划，咱们能够看到真要落地要思考的点都很多，一个不慎，可能踩坑。

即便是看起来很省心的Seata，我之前的我的项目花了不少w买了它的商业化版本GTS，然而反对方依然列出了一些“禁忌”，像长事务、大量数据、热点数据、异步调用等等，都可能会呈现问题。

所以在我的项目中利用分布式事务要审慎再审慎，除非真的有一致性要求比拟强的场景，能不必就尽量不必。

如果感觉文章有帮忙， 点赞、关注、珍藏 素质三连，抱拳！

参考：

[1]. 再有人问你分布式事务，把这篇扔给他

[2]. 让咱们聊一聊分布式事务

[3]. 分布式事务，这一篇就够了

[4].从分布式事务解决到Seata应用，一梭子给你整明确了

[5]. 看了 5种分布式事务计划，我司最终抉择了 Seata，真香！

[6]. 后端程序员必备：分布式事务根底篇