分布式事务概述

概述

       RocketMQ官网介绍中这样描述RocketMQ的事务消息“消息队列 RocketMQ 版提供类似 X/Open XA 的分布式事务功能，通过消息队列 RocketMQ版事务消息能达到分布式事务的最终一致”。这段描述给我带来的困惑一点都不比出门没带手机更让我难受的多。我的逻辑回路里面一个高可用的分布式服务是无法满足分布式事务的一致性。因为消息传递过程具有不可靠性，所以分布式服务要做到每个环节都满足事务的ACID，最终事务也满足ACID是不可能的。那么剩下的问题就是理解出现了分歧，本文的目的就是在于解决分布式事务方面理解出现的偏差。

一、事务简介

       事务是一个完整的工作单元。

       事务(Transaction)起源于数据库操作理论，在关系数据库中，一个事务由一组SQL语句组成。在《企业应用架构模式》中，事务是实现业务的一系列工作步骤。但是不管什么场景，事务都应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性，以数据库事务为例，ACID具体包含以下几个方面：
 原子性（atomicity）：事务是一系列不可分割的操作的集合，事务中包括的所有操作要么全部执行成功，要么全部执行失败。
 一致性（consistency）：事务是使数据从一个状态变到另一个状态过程中数据整体完整保持一致性。
 隔离性（isolation）：事务的执行彼此独立互不干扰，隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。
 持久性（durability）：事务一旦提交，它对数据库中数据的改变就应该是永久性的。

        任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务，即使不能都很好的满足，也要考虑支持到什么程度。

  
二、本地事务

        大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务称之为本地事务(Local Transaction)。本地事务的ACID特性是数据库直接提供支持。

三、分布式事务

         分布式事务就是为了保证不同资源服务器的数据一致性。一个事务的执行对所有资源服务器的操作要么全部成功，要么全部失败。一个分布式事务可以分为全局事务，
典型的分布式事务场景：
1、跨库事务
 跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。
2、分布式数据库
3、分库分表
通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。
4、业务服务化
      应用功能以对外服务的方式发布，并将这些服务之间通过接口和协议联系起来，构建完整的业务服务，这就是业务服务化。业务服务化中应用功能之间独立操作数据库，或者会操作多个数据库。

       通常不同的应用功能都会操作不同的数据库，同一个应用多次操作同一个数据库，同一个应用多次操作不同数据库等等，都需要保证事务的对多个数据库的操作要不都成功，要不都失败，实际上这可能是最典型的分布式事务场景。当然一个典型的分布式事务场景并不要求一定要有数据库操作，重要的是数据持久化。如果没有数据持久化，就相当于做一件事情有起点有过程没有终点。对比事务的概念这样的事务是不完整的。

四、X/Open DTP模型与XA规范

X/Open国际联盟有限公司是一个欧洲基金会。他是一个国际性的自由开放组织，主要的目标是促进对UNIX语言、接口、网络和应用的开放式系统协议的制定。就分布式事务处理(Distributed Transaction Processing,简称DTP)而言，X/Open主要提供了以下参考文档：
   DTP 参考模型： <<Distributed Transaction Processing: Reference Model>>
   DTP XA规范： << Distributed Transaction Processing: The XA Specification>>

4.1 DTP模型
      在X/Open中，DTP是一种软件架构模型，他允许多个应用程序共享多个资源管理器提供的资源，并允许应用之间满足全局事务的规范。在DTP参考模型第三版中指出，DTP模型包含应用程序、资源管理器、事务管理器、通信资源管理器、通信协议五个基础部分。

应用程序 (an Application Program，简称AP)：应用程序定义了事务边界（即事务的开始和结束）并指定了构成事务的操作（即事务对资源做的处理）。
资源管理器(Resource Managers ，简称RMs)：资源管理器提供对资源的管理和访问方式，如数据库，文件系统等。
事务管理器(a Transaction Manager 简称TM)：负责给所有的事务分配唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。之所以是所有事务，因为分布式环境中，事务包含一个全局事务和若干分支事务组成。
通信资源管理器(Communication Resource Managers，简称CRMs)：控制同TM域或者跨TM域的分布式应用之间的通信。
通信协议(a communication protocol，简称CP)：为分布式应用或者支持CRMs的服务提供底层通信服务。

        参照X/Open DTP模型列举了一种可移植的高级语言（HTL，high-level TP language）,一系列可移植的接口和便利的系统级接口，具体包括：
•应用程序源代码的可移植性
•TMs、RMs和CRMs的可互换性
•同一全局事务中不同TMs、RMs和CRMs的互操作性

2、模型实例(Instance of the Model)

一个DTP模型实例至少包含三个部分：一个应用程序（AP），一个事务管理器（TM），多个资源管理器（RMs）。

类比一下华为分布式数据库中间件DDM，用户应用就是AP，DDM就是一个事务管理器TM，数据就是多个资源管理器（RMs）。应用程序AP需要操作多个数据库RMs,通过DDM也就是（TM）声明一个全局事务，DDM通过监控所有数据库（RMs），来协调不同数据库上的提交和回滚。

补充：这里我们可以发现，数据库（RMs）本身也有自己的事务管理器（TM），这是由于TMs、RMs和CRMs的可互换性，DTP模型规定了要有这些组成部分，但是组成部分之间是单独实现还是融合实现并没有规定。

3、事务管理器作用域 （TM domain）

一个TM域由一个或多个使用相同TM的实例组成.对于在TM域中运行的所有应用程序，使用公共的事务管理器。类比我们分库分表场景，所有的库表使用的都是同样的事务管理策略。公共TM使用逻辑共享的数据用于全局事务管理的结构和日志。

4.通信资源管理器(CRMs)

在跨应用的分布式模型中，比如大部分SOA服务，为了满足不同服务之间的事务管理，每个DTP模型实例需要引入一个通信资源管理器（CRM），多个实例之间的CRM构成通信管理器组（CRMs）。

 CRM具备事务传播能力，用于满足跨域应用或者同域应用之间的通信，CRMs通过支持以下接口来提供全局事务：
 1.在AP和CRM之间使用的通信范型(TxRPC、XATMI或CPI-C，版本2)
 2.在TM与CRM之间使用XA+ 通信
 3.CRM和OSI TP之间的XAP-TP通信。

5.全局事务树形结构(Global Transaction Tree Structure)
在X/Open的DTP模型中，提出对分布式应用操作的全局事务采用树结构进行管理的概念。

当两个实例之间发生分布式通信时，他们有一种上级和下级的关系，全局事务中发出请求的实例称为上级实例，被请求的实例称为从属实例，没有上级实例的实例称为根实例。
一个全局事务包含一个或者多个事务分支，每个事务分支提现支持由TM和一组参与的RMs参与的全局事务中的一部分工作。在两个事务通信过程中，由一个上级事务服务管理协调同级的下级事务，并逐级上报给上级事务，直到根事务，从而实现全局事务监管。

6 XA规范
XA提供了DTP组件之间通信交互的规范。（Common Application Environment，CAE）通用应用环境和。下图展示了一个典型的DTP模型中，应用程序调用事务管理器构建事务的过程。图中方框代表应用组件，箭头代表调用方向。在一个工作流程中可能存在多个DTP实例，XA规范并不要求所有组件保持独立，也不需要单独的线程去控制。也就是说DTP模型中的组件并没有一个一成不变的角色。比如，一个事务管理器可能用资源管理器来完成事务监管的工作。
6.1接口规范

6.2事务完成和恢复
参考OSI DTP规范(模型)，TMs和RMs使用假定回滚的两阶段提交模式。
第一阶段：TM要求所有的RMs准备提交(或准备)事务分支。
这将询问RM是否能够保证其提交事务分支的能力。如果一个RM可以提交它的工作，它稳定地记录它需要完成的工作，然后对TM做出应答。如果失败，RM自己会回滚，并放弃当前分支事务信息。
第二阶段：TM向所有RMs发出一个实际请求来提交或回滚事务分支。所有的RMs提交或回滚对共享资源的更改，然后将状态返回给TM，然后，TM可以放弃其关于全局事务的知识。

五、经典的分布式系统理论-CAP

2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。Brewer认为在设计一个大规模的分布式系统时会遇到三个特性：一致性（consistency）、可用性（Availability）、分区容错（partition-tolerance），而一个分布式系统最多只能满足其中的2项。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。 
  一致性(Consistency）    所有节点在同一时间访问到的数据完全一致
  可用性(Availability）   即服务整体一直可用，能及时对每一个请求能做出响应。
  分区容错性（Partition Tolerance）   当集群中的某些结点无法联系时仍能正常提供服务

总结： 既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，我们就需要做出相应的取舍。由于网络问题是分布式系统必然要遇到的问题，也就是说分布式系统必须解决分区容错性，因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡。目前大部分互联网公司都选择采用基于BASE理论的柔性事务，选择可用性和分区容错性，舍弃强一致性。

参考资料：

 http://www.tianshouzhi.com/api/tutorials/distributed_transaction/383

https://pubs.opengroup.org/onlinepubs/9294999599/toc.pdf

https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf