上一篇博客《分布式事务--Fescar》中我们已经了解到Fescar相关的知识，Fescar也是基于阿里巴巴的GTS开源的。这篇转载博客理解学习一下GTS相关的知识内容。
全局事务服务（Global Transaction Service，简称 GTS）是阿里新推出的分布式事务处理方案，对其深入分析的资料相对匮乏。本文的目标是剖析GTS的技术路线，厘清其优势与约束。文章参考了GTS公开的专利、产品文档、相关网页，文章中肯定有不准确的地方，欢迎各位同学拍砖与指正。
一、GTS的目标
GTS是一个面向互联网交易场景的分布式事务解决方案。
制约分布式事务的三个因素
分布式事务是互联网交易场景面临的关键问题之一。不同于搜索、社交、联机分析应用，电子商务、支付是典型的交易场景，数据的错误会带来严重的后果，对数据的一致性与可用性有很高的要求。互联网环境带来了海量的数据容量、连接数与访问量，单一数据库节点无法应对，成为整个系统的瓶颈。为解决单一数据库成为瓶颈的问题，通过数据拆分实现数据库能力的线性扩展。数据拆分是使用分库分表的方式，将数据存储在多个数据库节点，利用分布式数据库平台解决数据库瓶颈的问题。分布式数据库环境中，一个事务会跨越多个数据库，面临分布式事务处理的问题。
分布式事务解决方案面临应用灵活性、数据一致性、性能三者的挑战。目前已有多种成熟方案，每种方案都是对这三个方面做出的取舍。
相互制约的三个因素为：
- 应用灵活性：应用访问数据的方式是否需要修改，以及修改的程度。
- 一致性：数据是强一致，还是最终一致的（允许中间不一致的状态）。
- 系统性能：分布式事务对整体性能的影响。
现有分布式处理方案
现有成熟的分布式解决方案包括XA两阶段提交、可靠消息与TCC模式等类型。XA两阶段提交属于强一致事务，可靠消息与TCC模式属于柔性事务。
XA两阶段提交
XA 是指由 X/Open 组织提出的分布式事务处理的规范。XA规范主要定义了Transaction Manager（TM）和Resource Manager（RM）之间的接口，结构如下图所示。
XA协议的流程可大致分为三个步骤：
- 步骤1：APP向TM创建全局事务，TM向APP返回全局事务号。
- 步骤2：APP使用全局事务号，访问RM的资源（当RM为数据库时，资源访问就是SQL操作）。当RM第一次收到访问时，使用该全局事务号向TM注册，TM返回事务分支事务号。
- 步骤3：APP向TM发出全局事务提交请求，TM与参与事务的RM通信，进行提交处理，全部完成后，向APP返回结果。
TM与RM之间的提交处理，采用两阶段提交协议。TM在第一阶段对所有的参与事务的RM请求“预备”操作，达成关于分布式事务一致性的共识。事务参与者必须完成所有的约束检查，并且确保后续提交或放弃时所需要的数据已持久化。在第二阶段，根据之前达到的提交或放弃的共识，请求所有参事务的RM完成相应的操作。
提交事务的过程中需要在多个资源节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，所以两阶段提交在执行同样的事务时会比一阶段提交消耗更多的时间。当事务并发量达到一定数量时，就会出现大量事务积压甚至出现死锁，系统性能和处理吞吐量就会严重下滑。
可靠消息
可靠消息的一种可能实现的结构如下图。
说明：
- 业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。
- 业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息。
- 业务处理服务在业务事务回滚后，向实时消息服务取消发送。
- 消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。
通过消息进行事务异步的方式，可以保证业务数据操作和消息的发送同时执行成功或失败，保持了事务的最终一致性。
采用可靠消息的方式，在两个事务间实现分布式事务时，可以很好地满足事务最终一致性以及事务的回滚，但如果一个事务上下文中超过两个事务操作后，需要开发人员实现整个事务流程的操作日志的记录、每个事务分支的回滚以及整个流程的准确调度。
TCC模式
TCC模式为全局事务执行提供了一个框架，开发人员只需要实现每个事务分支的回滚，不需要记录整个事务流程的操作日志。TCC模式结构如下图。