开发者学堂课程【全面讲解Spring Cloud Alibaba技术栈（知识精讲+项目实战）第五阶段：分布式事务解决方案-全局事务】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/687/detail/11923
分布式事务解决方案-全局事务
内容介绍
一、总述
二、全局事务解决方案
一、总述
此前简要地介绍了分布式事务相关的基础理论知识，并且分析了产生
分布式事务的场景。现在就针对于这些场景介绍几个在业界比较流行
的分布式事务解决方案。大体上分为四个类别。
第一个为全局事务解决方案；第二个为基于可靠消息服务来实现分布
式事务的解决方案；第三个为最大努力通知的解决方案；第四个为
TCC 事务，也称作补偿性事务的解决方案。
二、全局事务解决方案
1、场景模拟
在介绍全局事务解决方案之前，首先通过画图的形式把分布式事务问
题描述出来。这样对于理解全局事务是非常有益处的。首先来模拟一
个分布式事务的场景。
这个场景使用以前经常使用的订单和商品模型，即订单微服务和商品
微服务。随后又分别画出订单数据库和商品数据库。接下来对下单的
场景进行模拟，这里有一个下订单的需求，下单时订单微服务所做的
首先是调用商品微服务查询商品信息，下订单的过程就是对订单数据
库的一个写入的操作。
写入订单完成以后订单微服务仍要调用商品微服务完成另外一个称
作“扣减库存”的操作。下订单之后商品对应的库存肯定要做较少，
否则商品数据库中的库存永远是不变的，这就是不正确的。这两件事
情应该是一个原则性的操作。
下订单成功后，库存就应该减少。下订单后而库存未减少或者是写入
订单失败库存反而减少了，这都是不合适的。
写入订单和减少库存两者是事务性的操作。但是写入订单和减少库存
二者是属于不同的微服务和不同的数据库，也就是会存在分布式事务
的问题。
接下来就基于这样的场景介绍一下全局事务解决方案是如何解决这种场景之下的分布式事务问题的。
2、全局事务的基本介绍
全局事务是基于 DTP 模型来实现的。DTP 模型是由 X/Open 组织提出的一种分布式事务模型，全称为 X/Open Distributed Transaction Processing Reference Model，翻译过来就是 X/Open 分布式事务处理参考模型。它提出的仅仅是一种模型，一种思想，并不是一种实际技术。
3、全局事务需要的三种角色
在这种模型之下规定了要实现分布式事务，需要三种角色的参与。
(1) AP：Application 应用系统
全称为 Application，翻译后就是应用系统。这其实就是微服务。自主开发的小型项目就是 AP。上图的订单微服务和商品微服务就是 AP。
(2) TM: Transaction Manager 事务管理器
这是用来做全局事务管理的。上图中也会有一个全局事务管理者来管理写入订单和扣减库存这两个原则性的操作。(3) RM: Resource Manager 资源管理器
就可以把其当作数据库，即对应上图中的订单数据库和商品数据库。
4、全局事务的两个阶段
在全局事务中，会将整个事务分成两个阶段。
(1)阶段一:表决阶段，所有参与者都将本地事务执行预提交，并将能否成功的信息反馈发给协调者。
(2)阶段二: 执行阶段，协调者根据所有参与者的反馈，通知所有参与者是否能够进行提交和回滚。就是将写入订单和扣减库存这两个事情纳入统一的全局事务管理，并且分成两个步骤进行。
①第一步骤
可以是询问步骤，是 TM 对于 RM 进行询问。写入订单执行一个预写订单的操作，这里有一个字眼为“预提交”，它并没有真正地把订单写入进数据库中，只是预提交的一个测试。
如果预提交成功，就会向 TM 反馈一个结果。对于商品微服务同样是这个原理，它会执行一个“预扣除库存”这样的效果，如果成功的话 RM（商品数据库）就会向 TM 反馈。如果 TM 反馈执行，两个 RM（订单数据库、商品数据库）就会同时进行数据库的写入。
②第二步骤
第二步骤是根据结果进行提交，如果情况会有所不同，比如 TM 反馈订单数据库进行预提交，提交成功后就反馈给 TM 能成功。但是在库存这一方面，商品数据库执行后，从扣除一个库存到扣除三个库存，一定是无法成功的。商品数据库反馈出扣除库存无法成功，于是 TM 就反馈出全部的操作都撤销。在此需要注意的是预提交和表决阶段的时间占比是很大的。表决阶段会准备资源并进行提交等各种各样的事需要做，它的时间是很长的。
而对于执行阶段时间就变得很短，因为这只是修改一个状态的事情。比如10秒钟的时间，表决阶段会占据9秒，执行阶段只占据1秒。失败或者发生异常仅是在这1秒的时间之内。因为在前面9秒的时间是预支型，如果出现异常也没有关系。出现异常在返回的时候 TM 就反馈给回滚的信息。但是在提交的过程中成功或失败是存在分布式事务的问题的。
两个阶段的提交只是降低了分布式事务出现的概率，并不能保证把分布式事务全部解决。问题会发生在第二阶段的提交中，因为第二次提交有可能成功，也有可能会失败。
情况一：
事务管理器会对订单和商品两个 RM 作出询问，询问是否能进行成功的提交，订单数据库和商品数据库反馈能，接下来执行阶段开始事务管理器就进行提交了，但并不一定全部都能提交成功。这是第一种情况。
情况二：
第二种情况是事务管理器询问两个应用是否能提交，其中一个反馈可以，另一个反馈到不可以。事务管理器反馈到既然有不能提交的，全部就不提交了。这就是全局事务所涉及到的原理部分。
5、全局事务的优缺点
(1)优点：提高了数据一致性的概率，实现成本较低。
提高概率就是指把原来10秒钟的概率压缩成1秒钟，因为只有在那1秒可能发生异常，导致失败。实现成本较低是因为它是基于数据库组图来实现的，对于应用来讲是不必做许多代码的。
(2)缺点
①单点问题：事务协调者宕机。这里有一个很重要的角色为全局事务管理者，一旦它出现问题，那么全局事务就崩溃了。
②同步阻塞：虽然延迟了提交时间，但加长了资源阻塞的时间。从预提交到正式提交的10秒钟都会持有数据库的资源锁。所以这里是延长了资源锁的持有时间。
③数据不一致：提交的第二个阶段不一定全部都会成功，这时如果一个提交成功，一个提交失败依旧会出现数据不一致的问题。
