CN109977171B - 一种保证事务一致性和线性一致性的分布式***和方法 - Google Patents

Abstract

本发明涉及一种保证事务一致性和线性一致性的分布式***和方法，其包括多个客户端以及由接入层、元信息管理集群、全局Gts生成集群和事务处理及存储层构成的数据库服务端；客户端用于为用户提供与数据库服务端进行交互的接口，将用户请求发送到数据库服务端；接入层用于接收客户端发送的请求，并解析生成执行计划；元信息管理集群用于分布式集群的管理；全局Gts生成集群，用于生成全局时间戳，对分布式***中的全局事务进行唯一排序以实现线性一致性；事务处理及存储层包括多个资源管理节点，用于根据接入层发送的执行计划执行事务逻辑，得到的结果经接入层返回客户端。本发明可以广泛应用于数据处理领域。

Description

一种保证事务一致性和线性一致性的分布式***和方法

技术领域

本发明涉及数据处理技术领域，特别是关于一种保证事务一致性和线性一致性的分布式***和方法。

背景技术

首先，对分布式事务的一致性进行介绍。数据处理技术需要事务的语义并借用关系数据库的ACID四个特性，来保证***的事务特性，以满足商业社会的电子交易的需求。其中，A是原子性，C是一致性，I是隔离性，D是持久性。电子交易类操作，需要由这四个特性来保证交易的安全、可靠。

分布式事务处理技术，同样需要满足事务的ACID四个特性。为满足ACID四个特性，数据处理技术需要多种技术做保障。其中最重要的是数据的一致性和隔离性，这是因为数据的一致性决定了数据的正确性问题，而隔离性决定了并发***的性能问题。

实现事务一致性，主要依赖于并发访问控制算法。常见的并发访问控制算法有：基于锁的并发访问控制协议、基于时间戳排序的并发访问控制协议、基于MVCC的并发访问控制协议和基于OCC的并发访问控制协议。这些算法首先需要保证数据不出现异常，即满足事务的可串行化调度，如此才能确保正确性。其次，不同的并发访问控制算法，决定了事务处理的并发度，进而影响***的事务吞吐量，这是一个性能问题。

事务的一致性在分布式数据库中的体现，是跨界点的分布式事务保证一致性。文献《Distributed snapshot isolation:global transactions pay globally,localtransactions pay locally》(分布式快照隔离：全局事务在全局执行，本地事务在本地执行)提及了两种分布式***下存在的数据异常，这两个异常如果发生，则不能保证事务的一致性。

其次，对CAP理论涉及的外部一致性进行介绍。基于CAP(又称为布鲁尔定理)理论，分布式***中的一致性被定义为多个级别，并可被分为“强一致性”和“弱一致性”两类。

对于强一致性，要求分布式***要保证线性一致性。线性一致性需要保证全局关系，为线性一致性所遵从的定义，其明确要求线性一致性要满足所有操作全局有序，且操作之间必须保证有returns-before(返回后可见)偏序关系。也即要求从外部观察者的角度看，具有时间序的事件发生后，其对数据产生的影响能按照事件序读取到。线性一致性是分布式***的特性，和数据库本身没有直接关联。但是分布式数据库***，顾名思义，需要满足外部一致性。

对于弱一致性，其中比较常用的是因果一致性。因果一致性的定义明确要求因果一致性只对有因果关系的操作进行顺序约束，即因果一致性要求弱于线性一致性。因果一致性要求如果进程A先读取了某一数据项的旧值，然后更新产生该数据项的新值，那么另一个进程B对该数据项的读取操作，必须保证先完成的事务不会比后完成的事务先读到新值，即必须要保证进程A中已经确定的偏序关系。与此同时，与进程A无关系的进程C数据访问无限制。

分布式***中，如果采用全局唯一的事务管理器，是一种可行的保证事务一致性的方法。但是，依靠全局事务管理器，仍然存在三大问题：

1、全局事务管理器实现较为复杂，有很多技术难点需要花费时间克服，对技术人员的挑战很大。

2、不能有效利用处于其下层、即单节点上的单机数据库的事务处理机制，因为上层实现了事务管理的功能，底层已经不需要再实现。这意味着单点的数据库事务型引擎被废弃，转到上层重复造轮子，浪费时间和人力、财力。

3、全局事务管理器，是一个单点的架构，这不符合去中心化的分布式思想，是一个性能瓶颈点。

目前，关于分布式***中保证事务一致性和线性一致性的方案有以下几种：

第一种：如图1所示，为Postgres-XC(Postgres数据库的集群解决方案)的全局事务管理实现方式，Postgres-XC由一个GTM(全局事务管理器)、多个Coordinator(协调节点)、多个Datanode(数据节点)组成。其中，GTM是Postgres-XC的核心组件，用于全局事务控制以及tuple的可见性控制。GTM的作用在于分配全局事务号和管理PGXC MVCC模块,在一个CLUSTER中只能有一台主的GTM。

然而，由之前的说明可见，并发访问的核心技术(数据库***中最难最复杂的部分，也是代码量最多遍及整个存储引擎的部分)，都处于GTM这个模块。这样做为唯一的一个全局事务管理节点，所做的工作又复杂且架构上又是一个单点，故很容易成为一个瓶颈点。

第二种，为相关文献介绍的一种完全去中心化的事务管理器的算法，该算法在每一个节点(独立的数据库)都维护一个“全局事务管理器GTM”，一个集群中有多少节点就有多少个GTM。其中，GTM负责维护全局事务的可串行化，每个全局事务会被赋予整个集范围内唯一递增的一个全局事务标识，此标识是一个时间戳值，表示了全局事务之间的顺序，以便实现事务的可串行化调度。之后，全局事务会被分解为在不同节点上执行的子事务，全局事务的子事务带着全局事务的时间标识在各个节点执行(各个节点采用S2PL算法)，因事务标识(子事务标识)依赖时间戳排序故全局有序所以子事务在子各个相关节点上都执行成功则全局事务可以提交。此算法在把多个全局事务分散在了各个节点执行，达到了去掉全局事务管理器的目的。但是全局事务的时间戳(称为GTS)的分配，依赖于单个节点的本地时钟，作者认为多个节点的时钟需要同步但时钟是否同步并不影响其算法的正确性，这是因为算法中把每个全局已经提交的事务的时间戳值存储到了涉及到的子节点，作为子节点下一个时间戳值生成的依据，并且算法中用这个时间戳值作为事务回滚的条件，把新事务启动时间戳值与GTS比较，时间戳值小于GTS的全局新事务被回滚。

然而，该算法没有使用全局的事务之间的冲突信息作为冲突解决的依据，而是依赖时间排序全局事务实现可串行化，引入了较多的回滚情况；子节点的时间戳值依赖于已经提交的事务的时间戳值，引入了事务时间戳的向后推延的情况。而且，对于并发访问控制不基于MVCC的数据库***，在读事务较多的情况下，事务处理的性能不高。

第三种，Google的Spanner***，该***采用Truetime机制(此机制依赖物理的设备：GPS和原子钟)，可以实现去中心化的事务管理机制，且不依赖全局的时间戳作为事务的并发访问互斥依据(采取SS2PL+MVCC技术作为并发访问控制算法)，也不依赖全局的时间戳作为线性一致性的实现依据。然而，由于该机制依赖于物理的设备：GPS和原子钟，其费用较高，从经济的角度看，不适合所有的用户使用。

发明内容

针对上述问题，本发明的目的是提供一种保证事务一致性和线性一致性的分布式***和方法，该***能够保证分布式架构中跨节点的分布式事务的事务一致性和CAP理论涉及的线性一致性，以便在包括分布式数据库(SQL、NoSQL、NewSQL，关系型、非关系型)***、分布式大数据处理***、存在跨节点的全局写操作的事务型***等的数据处理***中，保证跨节点的全局事务所操作的数据是事务一致的、且是线性一致的。

为实现上述目的，本发明采取以下技术方案：一种保证事务一致性和线性一致性的分布式***，其包括：多个客户端以及由接入层、元信息管理集群、全局Gts生成集群和事务处理及存储层构成的数据库服务端；所述客户端用于为用户提供与所述数据库服务端进行交互的接口，将用户请求发送到所述数据库服务端；所述接入层用于接收所述客户端发送的请求，并解析生成执行计划；所述元信息管理集群用于对所述分布式***的分布式集群进行统一管理；所述全局Gts生成集群，用于生成全局时间戳，对分布式***中的全局事务进行唯一排序以实现线性一致性；所述事务处理及存储层包括多个资源管理节点，所述资源管理节点包括协调节点和数据节点，所述协调节点和数据节点用于根据接入层发送的执行计划执行事务逻辑，得到的结果经所述接入层返回所述客户端。

进一步的，所述数据节点用以将所述分布式***中的数据进行分区存放，所述协调节点用于对所述分布式***中的事务进行协调处理；对于所有所述资源管理节点的用途，有如下两种分配方式：主从模式：将其中一部分资源管理节点专门用做事务处理的协调节点，同时将剩余资源管理节点用作数据节点；对等模式：所有所述资源管理节点是对等的，每个所述资源管理节点都同时具有数据节点和协调节点两个功能。

进一步的，所述全局Gts生成集群的全局时间戳由八字节组成，且八字节采用混合物理时钟方式组成：a)前44位为物理时间戳值；b)后20位为在一毫秒内的单调递增计数。

进一步的，所述分布式***涉及的基本数据结构包括全局事务状态表、本地事务状态表、数据项数据结构、事务的全局读集写集以及通信协议及消息四类数据结构；

所述全局事务状态表用于维护从分布式***全局来看的事务状态，用六元祖{TID,Lowts,Uppts,Status,Gts,Nodes}表示，其中，TID代表事务唯一标识，Lowts代表事务逻辑提交时间戳下界，Uppts代表事务逻辑提交时间戳上界，Status代表当前事务在全局所处的状态，Gts代表事务全局提交/回滚完成的时间戳，Nodes代表当前事务涉及到的数据节点；

所述本地事务状态表用于维护事务在每个资源管理节点上的本地事务状态，用{TID,Lowts,Uppts,Status}表示，其中，TID代表事务唯一标识，Lowts代表事务逻辑提交时间戳下界，Uppts代表事务逻辑提交时间戳上界，Status代表事务的本地状态；

所述数据项数据结构包括作为线性一致性依据的第一组数据元素和作为分布式事务一致性的第二组数据元素，所述第一组数据元素包括{gts,info_bit}，其中，gts代表一个事务在分布式***中的全局唯一的顺序，info_bit用以标识当前在gts字段中记录的是Gts还是TID；所述第二组数据元素包括{wts,rts}，其中，wts用于记录创建该数据项版本的事务的逻辑时间戳，rts用于记录最新读过该数据项的事务的逻辑时间戳；

所述事务的全局读集用于记录事务所读全部数据项，用{BlockAddress,Offset,Size,Value}表示，其中，BlockAddress代表数据项对应块地址，Offset代表数据项在块内的偏移量，Size代表数据项大小，Value代表数据项值；

所述事务的全局写集用于记录事务需要更新的全部数据项，用{BlockAddress,Offset,Size,NewValue，OperationType}表示，其中，BlockAddress代表数据项对应块地址，Offset代表数据项在块内的偏移量，Size代表数据项大小，NewValue代表数据项值，OperationType代表操作是更新、***还是删除操作；

所述通信协议及消息包括所述协调节点发往所述数据节点的消息、所述数据节点发往所述协调节点的消息、所述协调节点发往所述全局Gts生成集群的消息、所述全局Gts生成集群发往所述协调节点的消息；所述协调节点发往所述数据节点的消息包括读数据请求消息、验证请求消息、写入提交/回滚请求；所述数据节点发往所述协调节点的消息包括读请求反馈消息、本地验证反馈消息；所述协调节点发往所述全局Gts生成集群的消息包括全局时间戳请求消息；所述全局Gts生成集群发往所述协调节点的消息包括全局时间戳请求反馈消息。

一种保证事务一致性和线性一致性的分布式***的多级别一致性方法，其包括以下步骤：1)建立能够实现多级别一致性的统一致性模型；2)根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性要求的一致性执行算法，对分布式***中的分布式事务和单机事务进行执行，得到事务执行结果。

进一步的，所述步骤1)中，建立能够实现多级别一致性的统一致性模型的方法，包括以下步骤：

1.1)采用基于DTA的OCC策略进行事务并发访问控制，建立用于保证事务一致性的RUC-CC算法；

1.2)基于全局Gts生成集群生成的全局时间戳以及全局事务状态，建立基于全局时间戳的线性一致性保证算法，用于保证事务之间线性一致性；

1.3)采用进行两次数据读取的方法，建立两次读线性一致性保证算法，用于保证事务之间一致性；

1.4)将步骤1.1)～步骤1.3)的事务一致性和线性一致性以及MVCC算法进行组合，建立能够满足多种一致性级别的统一致模型。

进一步的，所述步骤1.1)中，采用基于DTA的OCC策略进行事务并发访问控制，建立RUC-CC算法的方法，包括以下步骤：

1.1.1)对由客户端发送的事务T，在协调节点上完成相应的初始化工作；

1.1.2)将事务的全局执行阶段分为3个阶段：读取阶段、验证阶段以及提交写入/回滚阶段，并在协调节点的协调下，与操作相关的各数据节点对事务进行执行，并对事务状态表中提交或回滚事务的对应表项进行清除。

进一步的，所述步骤1.1.2)中，将事务的全局执行阶段分为3个阶段：读取阶段、验证阶段以及提交写入/回滚阶段，并在协调节点的协调下，与操作相关的各数据节点对事务进行执行，包括以下步骤：

1.1.2.1)事务T按照执行逻辑读取所需数据，并将更新写到事务T的本地内存，

1.1.2.2)事务T验证自身是否同其他事务存在冲突，得到验证结果；

1.1.2.3)事务T根据验证阶段的验证结果，选择执行写入提交还是回滚。

进一步的，所述步骤1.1.2.1)中，事务T按照执行逻辑读取所需数据，并将更新写到事务T的本地内存的方法为：

首先，事务T的协调节点需要向数据项x所在的数据节点发送读数据项x的读数据请求消息；

然后，数据项x所在数据节点收到读数据请求消息后，首先对事务T的本地事务状态表进行建立或更新，然后在事务T的逻辑生命周期内查找数据项x的可见版本，并向事务T的协调节点发送读请求反馈消息；

最后，事务T的协调节点收到所有数据节点的读请求反馈消息后，对是否需要回滚进行判断，如果需要回滚，则进入全局回滚阶段，否则事务继续执行。

进一步的，所述步骤1.1.2.2)中，事务T验证自身是否同其他事务存在冲突，得到验证结果的方法为：

首先，事务T的协调节点修改全局事务状态表中事务T的状态为：Gvalidating；然后向事务T涉及的每个数据节点发送验证请求消息和本地写集；

其次，事务T涉及到的每个数据节点收到验证请求消息后，执行本地验证操作，具体包括以下步骤：

①更新本地事务状态表中事务T的T.Lowts＝max(T.Lowts,vrm.Lowts)、T.Uppts＝min(T.Uppts,vrm.Uppts)；

②检查T.Lowts是否大于T.Uppts，是则验证失败，向事务T的协调节点返回Abort消息进入回滚，否则进入步骤③；

③找到事务写集中的每一个数据项y，然后查看数据项y的WT是否为空：

如果不为空，则向事务T的协调节点发送Abort消息进入回滚；

否则进入步骤④；

④更新写集中每个数据项y的WT为T.TID，并调整本地事务状态表中事务T的时间戳下界，使其大于y的rts；

⑤检查T.Lowts是否大于T.Uppts，是则验证失败，本地回滚，然后向事务T的协调节点返回Abort消息；否则，进入步骤⑥；

⑥对写集中每个元素y，调整事务T或者RTlist中事务的时间戳，消除读写冲突；

⑦根据数据项y的更新值，创建数据项y的新版本，同时设置表示新版本并未全局提交的flag；

⑧向事务T的协调节点返回事务T的本地验证反馈消息lvm，其中lvm的Lowts和Uppts分别记录了事务T在本地数据节点上的逻辑时间戳上下界；

最后，事务T的协调节点收到所有资源管理节点的本地验证反馈消息后，根据收到的消息来决定事务T能否通过验证。

进一步的，所述步骤1.2)中，基于全局Gts生成集群生成的全局时间戳以及全局事务状态，建立的基于全局时间戳的线性一致性保证算法，包括以下步骤：

1.2.1)客户端发起事务T请求，由接入层与其建立连接，形成一个会话；

1.2.2)接入层将事务T进行解析，并选取协调节点来负责管理该事务的执行过程；

1.2.3)读事务T开始时，从全局Gts生成集群获得事务开始时的全局时间戳，并在该读事务的全局事务状态表中记录Gts；协调节点与所有本读事务相关的数据节点建立连接，将解析后的查询执行计划和全局时间戳Gts形成数据包，通过网络通信下发给所有相关的数据节点；

1.2.4)所有数据节点各自进行数据读取操作，确定符合选择条件的数据项，然后对每一个有多个版本的数据项，从最新版本开始进行遍历，直至找到其第一个可见版本；

1.2.5)协调节点汇总所有数据节点返回的数据，并返回给接入层，接入层向建立会话关系的客户端返回数据，当前读事务完成。

进一步的，所述步骤1.3)中，采用进行两次数据读取的方法，建立的两次读线性一致性保证算法的流程为：

1.3.1)客户端发起事务T请求，由接入层与其建立连接，形成一个会话；

1.3.2)接入层将事务T进行解析，并选取协调节点来负责管理该事务的执行过程；

1.3.3)协调节点与所有本读事务相关的数据节点建立连接，向所有相关数据节点发送数据获取请求，所有相关数据节点执行第一次数据读取算法，并将数据返回给协调节点，协调节点基于所有返回的数据项确定当前读事务T的全局时间戳Gts；

1.3.4)协调节点向所有数据节点再次发送数据获取请求，并将确定的当前读事务T的全局时间戳Gts发送给所有数据节点，在数据节点上执行第二次数据读取算法，返回对于当前读事务T的全局时间戳Gts满足线性一致性的数据版本；

1.3.5)协调节点汇总所有数据节点返回的数据，并返回给接入层，接入层向建立会话关系的客户端返回数据，当前读事务完成。

进一步的，所述步骤2)中，根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的分布式事务进行执行的方法，包括以下步骤：

2.1)依据事务是否需要对多个资源管理节点上的数据进行操作，将分布式***中涉及的事务分为分布式事务和单机事务两种；

2.2)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的分布式事务进行执行；

2.3)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的单机事务进行执行。

进一步的，所述步骤2.2)中，采用与一致性级别要求相适应的一致性执行算法，对分布式***中的分布式事务进行执行的流程为：

2.2.1)客户端负责发出执行事务T的请求，接入层负责接收客户端发来的请求，并与客户端建立会话关系；

2.2.2)接入层接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，并通过路由分配给不同的协调节点；

2.2.3)协调节点优化SQL并生成物理执行计划，并进行全局事务初始化工作，记录全局事务状态信息，然后将执行计划分解为每个数据节点上的执行计划，发送到相应的数据节点，并将全局事务状态记为正在运行状态；

2.2.4)各数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务执行状态，当数据节点本地执行数据读写完成后，向协调节点发送“可以验证”指令；具体的：

当为事务逻辑一致性和事务因果一致性要求时：数据节点根据执行计划，采用RUC-CC算法进行数据操作和事务调度；

当为线性一致性级别要求时：数据节点根据执行计划，采用线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度；

当为完全一致性级别要求时：数据节点根据执行计划，采用线性一致性保证算法结合RUC-CC算法进行数据操作和事务调度；

2.2.5)协调节点收到全部相关数据节点发来“可以验证”指令后，记录全局事务状态为正在验证，并向所有相关数据节点发送“进行验证”指令；

2.2.6)数据节点收到“进行验证”指令后；进入本地验证流程，如果验证通过，则发送“验证通过”指令给协调节点；

2.2.7)协调节点收到全部相关数据节点发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与全局Gts生成集群进行交互以获取事务的全局时间戳，并记录全局事务状态为已提交；然后，同时开启两个线程：第一个用来将结果集返回给接入层，由接入层负责将执行结果返回给客户端；第二个将向所有相关数据节点发送“进行提交”指令；

当为事务逻辑一致性要求时：协调节点收到全部相关数据节点发来的“验证通过”指令后，记录全局事务状态为已提交；

当为事务因果一致性级别、线性一致性和完全一致性要求时：协调节点收到全部相关数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交；

2.2.8)各数据节点收到“进行提交”指令后，进入本地提交流程。

进一步的，所述步骤2.3)中，根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的单机事务进行执行的方法，包括以下步骤：

2.3.1)客户端负责发出执行事务T的请求，接入层负责接收客户端发来的请求，并与客户端建立会话关系；

2.3.2)接入层接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，通过路由分配给不同的协调节点；

2.3.3)协调节点优化SQL，并生成物理执行计划，将物理执行计划发送给选定的数据节点，协调节点进行事务初始化工作，记录事务状态为正在运行后，直接将执行计划发送到相应的数据节点；

2.3.4)数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务状态，当数据节点本地执行数据读写完成后，直接进入验证流程，如果验证通过，则发送“验证通过”指令给协调节点，并进入本地提交流程；

当为事务逻辑一致性和事务因果一致性级别要求时，数据节点通过RUC-CC算法进行数据操作和事务调度；

当为线性一致性级别要求时，数据节点通过线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度；

当为完全一致性级别要求时，数据节点通过线性一致性保证算法结合RUC-CC算法进行数据操作和事务调度；

2.3.5)协调节点收到数据节点发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与全局Gts生成集群进行交互以获取事务的全局时间戳，并记录事务状态为已提交，然后将结果集返回给接入层，由接入层负责将执行结果返回给客户端；

当为事务逻辑一致性要求时：协调节点收到数据节点发来的“验证通过”指令后，记录全局事务状态为已提交；

当为事务因果一致性级别、线性一致性和完全一致性要求时：协调节点收到数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交。

本发明由于采取以上技术方案，其具有以下优点：1)本发明提出了基于动态时间戳调整的乐观并发访问控制算法(RUC-CC算法)，是一个去中心化的、高效的、能确保***全局的事务ACID特性的事务调度算法，保证了分布式事务的冲突可串行化调度。2)本发明通过“全局Gts生成集群”，保证了***中所有的操作都和全局时钟下的顺序一致，将“全局Gts生成集群”与MVCC算法相结合，提出线性一致性保证算法，能够保证外部一致性中最强的线性一致性。3)本发明通过对数据项基本结构的设计，是的把事务一致性保证算法和线性一致性保证算法在形式上解耦，使得二者不互相影响，但是，从算法和功能上，二者又能高效融合，因此，能够保证多种级别的一致性，从而满足不同应用场景对一致性正确性和分布式数据库***效率的多种需求。

附图说明

图1是Postgres-XC架构图；

图2是本发明分布式数据库***架构图；

图3是本发明全局事务状态结构图；

图4是本发明本地事务状态结构图；

图5是本发明数据项结构图及其所需维护信息结构图；

图6是本发明RUC-CC下全局执行阶段事务执行时序图；

图7是本发明多级别一致性示意图。

具体实施方式

下面结合附图和实施例对本发明进行详细的描述。

如图2所示，本发明提出的一种保证事务一致性和线性一致性的分布式***，其包括多个客户端(Client)以及由接入层(Proxy)、元信息管理集群(Metadata Manager)、全局Gts生成集群(Gts Manager)和事务处理及存储层构成的数据库服务端。其中，客户端用于为用户提供与数据库服务端进行交互的接口，将用户请求发送到数据库服务端；接入层用于接收客户端发送的请求，并解析生成执行计划；元信息管理集群用于对分布式***中的各个***进行统一管理，例如维护每个数据节点的路由信息等；全局Gts生成集群，用于生成全局时间戳，对分布式***中的全局事务进行唯一排序以实现线性一致性；事务处理及存储层包括多个资源管理节点(Resource Manager，以下简称RM)，用于根据接入层发送的执行计划执行事务逻辑，得到的结果经接入层返回客户端。

进一步的，事务处理及存储层中，资源管理节点分为两类，一是作为分布式数据库中的数据节点，用以将数据进行分区存放；二是作为事务处理的协调节点，即host node。因此，对于所有RM的用途，有如下两种分配方式：

主从模式：将其中一部分RM专门用做事务的协调节点，这部分RM用host node表示；同时将剩余RM用作数据节点。

对等模式：所有RM是对等的，所有RM都可以作为host node，所有的RM都可作为数据节点，即每个RM都同时具有数据节点和事务协调节点两个功能。

进一步的，全局Gts生成集群的全局时间戳(Gts)由八字节组成，且八字节采用混合物理时钟方式组成：

a)前44位为物理时间戳值(即Unix时间戳，精确到毫秒)。共可表示2^44个无符号整数，因此理论上一共可以表示约为

年的物理时间戳。

b)后20位为在某一毫秒内的单调递增计数(即为每毫秒2^20-1个，约100万个)

c)基于此数据结构，如果单机的事务吞吐量为10W/s，理论上可以支持包含1万个数据节点的分布式数据库集群。同时，Gts的数量代表了分布式***理论上所能支持的总事务数，也即基于本结构，理论上分布式***可以支持(2^44-1)*(2^20)个事务。

d)根据需要，Gts的位数可以扩展，以满足对更多的节点数、事务处理数的支持。

全局Gts生成集群在实现上是通过一主多从(主节点--多从节点)的形式提供服务，即由多台服务器组成集群，提供高可用服务，因此不会成为单点的性能瓶颈。

进一步的，本发明中分布式***涉及的基本数据结构包括全局事务状态表、本地事务状态表、数据项数据结构、事务的读集写集以及通信协议及消息四类数据结构。各数据结构详细介绍如下。

如图3所示，全局事务状态表称为GlobalTS，即维护从分布式***全局来看的事务状态。GlobalTS结构在host node集合中的每一个节点上均存在。对于全局事务T而言，其全局事务状态维护在全局事务T的协调节点host node上。对于每一个全局事务T，其全局事务状态用六元组{TID,Lowts,Uppts,Status,Gts,Nodes}表示，其中每个字段的含义为：

a)TID：代表事务唯一标识，由8字节组成，通过两部分组合来对***内的所有事务进行唯一标识，TID在事务初始化时进行分配：

①前14位用来记录该事务host node的编号，host node代表处理该事务的协调节点。14位共可以表示16383(2^14-1)个无符号整数，因此，可以和估算得到的全局时间戳Gts所能支持的节点数对应。

②后50位由该host node内的单调递增计数填充，区分host node中的不同事务，共2^50-1个，该数量级理论上可保证TID在Gts所规定的总事务数范围内保证不会重复。

③假如在某一host node上的TID的后50位已经分配到2^50-1，此时需要通过TID复用机制，来对TID进行循环利用，TID复用机制参考PostgreSQL提供的冻结机制进行设计，该机制为本领域技术人员公知常识，在此不做详细介绍。同时，理论上本发明设计的TID足够***正常运行使用。

b)Lowts：代表事务逻辑提交时间戳下界，即事务可以提交的最早逻辑时间，取值为非负整数，取8字节；

c)Uppts：代表事务逻辑提交时间戳上界，即事务可以提交的最晚逻辑时间，取值为非负整数，取8字节；

事务逻辑提交时间戳下界和事务逻辑提交时间戳上界构成构成事务的逻辑生命周期：[Lowts，Uppts]，一个事务的初始生命周期是[0，+∞]，全局事务T的最终逻辑提交时间戳T.cts是从区间[Lowts,Uppts]中获得。事务的逻辑生命周期是相对的，其生命周期的调整，依赖于动态时间戳算法(DTA)，具体算法在下文中介绍。

d)Status：代表当前事务在全局所处的状态。本发明中，用Grunning代表事务正在执行；用Gvalidating代表事务正处在验证阶段；用Gcommitting代表事务已经完成验证，正在提交阶段；用Gaborting代表事务正处于回滚阶段；用Gcommitted代表事务已经全局提交完成；用Gaborted代表事务已经全局回滚完成。

e)Gts：代表事务全局提交/回滚完成的时间戳，通过“全局Gts生成集群”进行生成，保证全局有序。

TID是作为全局事务在***内的唯一编号来使用，在全局事务开始时进行赋值，并且对于相同host node上的事务TID之间是有序的，因此，可以认为是一种偏序关系的体现。Gts代表全局时间戳，其含义为事务在***全局视角下的顺序，因此，认为是一种全序关系。所以，TID和Gts都能唯一标识一个事务，但区别在于两者所标识的顺序含义不同。

f)Nodes：代表当前事务涉及到的数据节点，即数据节点的集合。

进一步的，如图4所示，为维护事务在每个资源管理节点上的状态，本发明为每个事务维护本地事务状态表，称为LocalTS。LocalTS结构在每个RM上均存在。对于全局事务T而言，其对应的本地事务状态有多份，分别维护在全局事务T所涉及到的每个RM上。本地事务状态表包含{TID,Lowts,Uppts,Status}4个字段，其含义是：

a)TID：事务唯一标识，事务开始时分配，取8字节，与全局事务状态中的TID含义相同；

b)Lowts：与全局事务状态中Lowts的含义相同，取8字节；

c)Uppts：与全局事务状态中Uppts的含义相同，取8字节；

d)Status：用来描述事务的本地状态，采用4字节大小，事务有4个本地状态：正在运行态(Running)、本地验证通过态(Validated)、本地提交完成态(Committed)和本地回滚态(Aborted)。

进一步的，如图5所示，本发明数据项的基本结构中，每个数据项包含两部分：数据项头信息和若干数据版本。在这两部分中包含了与分布式事务处理相关的2组三个元素，使得线性一致性和分布式事务一致性解耦，含义如下：

第一组：线性一致性依据。

a)gts：全局时间戳或者称为全局线性标识，用以表示一个事务在分布式***中的全局唯一的顺序，每个数据版本都具有一个gts。其赋值过程如下：

①在产生本数据项的事务还未全局提交时，gts字段复用来记录该事务的全局事务号TID，用来唯一标识当前产生该版本的事务，方便对该事务的全局事务状态进行定位。

②当产生本数据项的事务已经全局提交，gts赋值为本事务在全局事务状态中记录的全局时间戳Gts，标志本事务在整个分布式***内部的全局顺序，从而实现线性一致性。

b)info_bit：代表标志位，1位，用以标识当前在gts字段中记录的是Gts还是TID。如果info_bit为1，则代表记录的是Gts，如果为0，则为TID。

第二组：分布式事务一致性依据。

a)wts：数据项的每个版本维护一个wts，该wts记录创建该数据项版本的事务的逻辑时间戳，每个数据项版本均需维护一个wts；

b)rts：记录最新读过该数据项的事务的逻辑时间戳，每个数据项维护一个rts，因此将其维护在数据项头信息中；

为保证分布式事务一致性，每个数据项还记录了哪些事务正在读写数据项，其含义是：

a)RTlist：记录访问过该数据项最新版本的活跃事务列表，列表的每个元素记录了具体事务的事务TID；

b)WT：记录了想要修改(写)该数据项的活跃事务，形式上是一个List，元素的具体记录内容为活跃事务的TID；

c)通过RTlist、WT可以对事务的逻辑生命周期作出调整。

进一步的，关于事务的读集写集数据结构：

事务T的全局读集记录了该事务T所读全部数据项；事务T在某一资源管理节点RM上所读数据项的集合构成了事务T在该资源管理节点RM上的本地读集，该本地读集是全局读集的一个子集；事务T在所有相关RM上的本地读集的并集等于事务T的全局读集。在本发明中，将在事务T所涉及的每个RM上维护该事务的本地读集。记录事务T的读集作用有2个：

a)在事务T提交时，更新读集中数据项的rts字段；

b)在事务T提交时，从每个读集元素x的RTlist中将T删除；

在本发明中使用一个链表结构来维护事务T的读集，每个链表节点代表一个读集元素x，其由4个字段构成：

a)BlockAddress：取8字节，块地址，表明了数据项x对应块地址；

b)Offset：取4字节，块内偏移量，表明了数据项x在块内的偏移量；

c)Size：取4字节，数据项大小，记录了数据项x对应元组的大小，即指明了Value字段的字节数。

d)Value：变长，数据项值，实际记录了数据项x的取值；

事务T的全局写集记录了该事务需要更新的全部数据项；事务T在某一RM上的本地写集记录了该事务要更新RM上的哪些数据项。事务的本地写集是全局写集的一个子集，事务T在所有RM上的本地写集的并集等于T的全局写集。记录事务T的写集作用有2个：

a)在验证阶段，T的host node根据写元素所在RM的不同，将全局写集分为若干本地写集，并将每个本地写集以消息的形式发送给相关RM，要求RM根据本地写集中元素的值创建新的数据版本；

b)在提交阶段，事务T的每个子RM清理每个写集元素的WT；

在该发明中使用一个链表结构来维护事务T的写集，每个链表节点对应一个写集数据项y，由5个字段构成：

a)BlockAddress：取8字节，块地址，表明了数据项y对应块地址；

b)Offset：取4字节，块内偏移量，表明了数据项y在块内的偏移量；

c)Size：取4字节，数据项大小，记录了数据项y对应元组的大小，即指明了NewValue字段的字节数。

d)NewValue：变长，数据项值，实际记录了数据项y更新后的值；

e)OperationType：取1字节，指明操作是更新、***还是删除操作，取值为0表示更新，取值为1表示***，取值为2表示删除。

在事务T的读取阶段，T的全局写集将维护在T的host node上；在T的验证阶段，T根据写元素所在RM的不同将全局写集分为若干本地写集，并将每个本地写集发送到对应的RM上维护。

进一步的，本发明中，协调节点host node与数据节点、协调节点host node与“全局Gts生成集群”需要以消息的形式进行通信，按照发送方与接收方的不同，本发明将通信协议及消息分为以下4大类：

1、host node发往数据节点的消息，主要包括3种：

a)读数据请求消息，ReadRequestMessage：事务T的读取阶段，host node发送该消息给RM，请求读取RM上的相关数据。该消息包括以下4个字段：

①TID：事务标识，取8字节，指明哪个事务请求读数据；

②Lowts：事务逻辑时间戳下界，取8字节，指明host node上事务T的逻辑时间戳下界；

③Uppts：事务逻辑时间戳上界，取8字节，指明host node上事务T的逻辑时间戳上界。

④ReadPlan：读取数据项x的查询计划；

b)验证请求消息，ValidateRequestMessage：事务T的验证阶段，host node发送该消息给数据节点，请求数据节点执行事务T的本地验证。该消息包括以下4个字段：

①Type：消息类型，取1字节，指明该消息为验证请求消息；

②TID：事务标识，取8字节，指明需要数据节点对哪个事务执行本地验证；

③Lowts：事务逻辑时间戳下界，取8字节，指明host node上事务T的逻辑时间戳下界；

④Uppts：事务逻辑时间戳上界，取8字节，指明host node上事务T的逻辑时间戳上界。

c)写入提交/回滚请求，CommitOrAbortRequestMessage：事务T的写入提交/回滚阶段，host node发送该消息给数据节点，请求数据节点完成本地提交或回滚。该消息包括以下5个字段：

①Type：消息类型，取1字节，指明该消息为写入提交/回滚请求消息；

②TID：事务标识，取8字节，指明需要数据节点对哪个事务执行本地提交；

③IsAbort：是否回滚，取1字节，如果值为1表示需要回滚事务T，取其他值不需要回滚T。

④Cts：事务逻辑提交时间戳，取8字节，指明host node为T选定的逻辑提交时间戳；

⑤Gts：事务全局时间戳，取8字节，指明全局Gts生成集群为事务T分配的全局提交时间戳。

2、数据节点发往host node的消息，主要包括2种；

a)读请求反馈消息，ReadReplyMessage：事务T的读取阶段，数据节点向host node返回所读数据项的值，该消息包含以下6个字段：

①TID：事务标识，取8字节，指明哪个事务的读请求反馈消息；

②IsAbort：是否回滚，取1字节，如果值为1表示需要回滚事务T，取其他值不需要回滚T。

③Lowts：事务逻辑时间戳下界，取8字节，指明本地数据节点上事务T的逻辑时间戳下界；

④Uppts：事务逻辑时间戳上界，取8字节，指明本地数据节点上事务T的逻辑时间戳上界。

⑤Size：取4字节，指明了Value字段的大小；

⑥Value：数据项值，记录了所读数据项的值；

b)本地验证反馈消息，LocalValidateMessage：事务T的验证阶段，数据节点通过本地验证消息后，向host node发送该消息，其包括以下5个字段：

①Type：消息类型，取1字节，指明该消息为本地验证反馈消息；

②TID：事务标识，取8字节，指明哪个事务本地验证反馈消息；

③IsAbort：是否回滚，取1字节，如果值为1表示事务需要回滚事务T，取其他值不需要回滚T。

④Lowts：事务逻辑时间戳下界，取8字节，指明数据节点上事务T的逻辑时间戳下界；

⑤Uppts：事务逻辑时间戳上界，取8字节，指明数据节点上事务T的逻辑时间戳上界。

3、host node发往全局Gts生成集群的消息，主要包括1种，即：全局时间戳请求消息，GtsRequsetMessage。事务T通过验证后，host node向全局Gts生成集群发送该消息，为事务T请求一个全局时间戳，该消息主要包含以下2个字段：

a)Type：消息类型，取1字节，指明该消息为全局时间戳请求消息；

b)TID：事务标识，取8字节，指明为哪个事务请求全局时间戳。

4、全局Gts生成集群发往host node的消息，主要包括1种，即：全局时间戳请求反馈消息，GtsReplyMessage。全局Gts生成集群为事务T分配全局时间戳后，以该消息的形式发送给host node。该消息主要包含以下3个字段：

a)Type：消息类型，取1字节，指明该消息为全局时间戳请求反馈消息；

b)TID：事务标识，取8字节，指明为哪个事务分配了全局时间戳；

c)Gts：事务全局时间戳，取8字节，指明事务的全局时间戳值。

基于上述对保证事务一致性和线性一致性的分布式***的框架的介绍，本发明还提供一种保证事务一致性和线性一致性的多级别一致性方法，其包括以下步骤：

1)建立能够实现多级别一致性的统一致性模型(United Consistency Mode,简称UCM)。

2)根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的分布式事务和单机事务进行执行。

上述步骤1)中，建立统一致性模型的方法，包括以下步骤：

1.1)采用基于DTA(Dynamic Timestamp Allocation，以下简称DTA)的OCC(Optimistic Concurrency Control,以下简称OCC)策略进行事务并发访问控制，建立RUC-CC算法，用于保证分布式***中事务一致性。

1.2)基于全局Gts生成集群生成的全局时间戳以及全局事务状态，建立基于全局时间戳的线性一致性保证算法，用于保证事务之间线性一致性。

1.3)采用进行两次数据读取的方法，建立两次读线性一致性保证算法，用于保证事务之间线性一致性。

1.4)将步骤1.1)～步骤1.3)的事务一致性、线性一致性以及MVCC(Multi-VersionConcurrency Control，以下简称MVCC)算法进行组合，建立能够满足多种一致性级别的统一致模型。

上述步骤1.1)中，为实现分布式去中心化的事务调度，保证事务一致性，本发明采用基于DTA的OCC策略来进行事务并发访问控制，策略中主要应用了OCC的算法框架，并结合DTA减小事务的回滚率，从而提升事务的并发处理能力，为叙述方便，本发明将其命名为RUC-CC算法。

如图6所示，在RUC-CC调度下，事务的生命周期被分为2个阶段：全局初始化阶段、全局执行阶段。此2个阶段，是在host node节点的协调，在host node和事务操作的相关数据节点上完成的。所以，如下按不同节点，细化各个阶段的工作流程，把工作分为全局初始化、全局执行个阶段。具体包括以下步骤：

1.1.1)全局初始化阶段：对由客户端发送的事务T，在host node上完成相应的初始化工作。

1.1.2)全局执行阶段：将事务的全局执行阶段分为3个阶段：读取阶段、验证阶段以及提交写入/回滚阶段，并在host node的协调下，与操作相关的各RM对事务进行执行，之后对事务状态表中提交或回滚事务的对应表项进行清除。

上述步骤1.1.1)，全局初始化阶段：对由客户端发送的事务T，在host node上完成相应的初始化工作，具体包含以下步骤：

1.1.1.1)为事务T分配一个全局唯一的事务号TID；

1.1.1.2)在host node上的GlobalTS中记录事务T的状态，其status状态置为Grunning，Lowts和Uppts分别初始化为0和+∞。

上述步骤1.1.2)中，全局执行阶段的具体流程包括以下步骤：

1.1.2.1)读取阶段，事务T按照执行逻辑读取所需数据，并将更新写到事务T的本地内存(即host node的本地内存)。

1.1.2.2)验证阶段，事务T验证自身是否同其他事务存在冲突，得到验证结果。

1.1.2.3)写入提交或回滚阶段：事务T根据验证阶段的验证结果，选择执行写入提交还是回滚。

上述步骤1.1.2.1)中，读取阶段当事务T需要读取数据项x时，具体流程包括以下步骤：

I、事务T的host node需要向数据项x所在的数据节点发送读x的读数据请求消息ReadRequestMessage rrqm。

其中，读数据请求消息ReadRequestMessage rrqm四个字段的值分别为：

a)TID，事务T的TID；

b)Lowts，事务T在host node上的Lowts；

c)Uppts，事务T在host node上的Uppts；

d)ReadPlan，事务T读x的查询计划；

II、数据项x所在数据节点收到消息rrqm后，首先对事务T的本地事务状态表进行建立或更新，然后在事务T的逻辑生命周期内查找数据项x的可见版本，并向事务T的hostnode发送读请求反馈消息rrpm。

III、事务T的host node收到数据节点发送的读请求反馈消息rrpm后，对是否需要回滚进行判断，如果需要回滚，则进入全局回滚阶段，否则事务继续执行。

上述步骤1.1.2.1)的步骤II中，数据项x向事务T的host node发送读请求反馈消息的具体流程为：

①检查数据节点的本地事务状态表LocalTS中是否包含事务T的信息：

a)如果没有，则在其上初始化事务T的信息，即在LocalTS中***一条记录，值分别是rrqm.TID、rrqm.Lowts、rrqm.Uppts和rrqm.Running；

b)如果有，即事务T读取数据项x之前，访问过该数据节点上的其他数据项，则更新事务T的信息，使T.Lowts＝max(T.Lowts,rrqm.Lowts)、T.Uppts＝min(T.Uppts,rrqm.Uppts)。

②检查事务T的逻辑提交时间戳下界是否小于其逻辑提交时间戳上界，即检查T.Lowts是否小于等于T.Uppts：

如果是，则继续读取数据x；

否则，更新LocalTS中事务T的状态为Aborted，即T.Status＝Aborted，并向事务T的host node返回Abort消息，即向事务T的host node发送读请求反馈消息rrpm，其中rrpm.IsAbort＝1；

③数据节点按照事务T的逻辑生命周期[Lowts,Uppts]找到数据项x的合适的可见版本。

其中，寻找x的合适可见版应首先从最新提交版本开始检查，如果T.Uppts大于最新版本的wts，该最新版本即为合适的可见版本。否则，则不是合适可见版本，需要查找上一个版本，直到找到第一个满足T.Uppts>wts的数据版本x.v为止，其中wts为x.v的创建时间戳。

④找到数据项x的合适版本x.v后，修改事务T的Lowts，使T.Lowts>x.v.wts(消除写读异常)；另外如果找到的版本为数据项x的最新版本，则需要执行以下操作：

a)检查x.v对应的WT(WT记录了正在修改x，并且通过验证的事务的事务标识)是否为空，如果不为空(假定值为TID1，TID1对应的事务为T1)，则调整事务T的Uppts，使其满足T.Uppts<T1.Lowts(消除读写冲突)；

b)将T.TID添加到x.v的RTlist列表中；

c)将数据项x添加到事务T的本地读集中；

⑤向事务T的host node返回读请求反馈消息，ReadReplyMessage rrpm。

其中，rrpm的Lowts和Uppts分别记录了当前数据节点上事务T的逻辑时间戳上下界，Value记录了所读数据项的值。

上述步骤1.1.2.1)的步骤III中，事务T的host node收到数据节点读请求反馈消息rrpm后，对是否需要回滚进行判断的具体流程为：

①检查收到的消息是否为Abort，即检查rrpm.IsAborts是否等于1，如果是，则进入全局回滚阶段；否则继续执行；

②更新GlobalTS中事务T的状态：更新T的T.Lowts＝max(T.Lowts,rrpm.Lowts)、T.Uppts＝min(T.Uppts,rrpm.Uppts)；

③检查GlobalTS中T.Lowts是否大于T.Uppts，如果是，则进入到全局回滚阶段；否则继续事务的执行。

在规则③中，如果host node决定回滚事务T，需要修改GlobalTS中T的状态为Gaborting，通知相关子节点执行局部回滚；

由上述规则可知，在事务T的读取阶段，通信主要在事务T的host node和相关子RM之间发生。事务T每成功读取一次数据需要两次通信：

a)事务T的host node发送读数据请求信息到相关子RM上；

b)相关子数据节点发送读请求反馈信息到host node上；

因此读取阶段最多进行2n次通信，最大通信量为n×(请求消息大小+相应消息大小)，其中n为远程读取的次数。一种节省通信次数的优化方式是：事务T需要某相关子数据节点的多个数据时，可以将请求打包发送，批量读取这些数据。

上述步骤1.1.2.2)中，验证阶段，事务T验证自身是否同其他事务存在冲突的具体流程为:

I、事务T的host node首先修改GlobalTS中事务T的状态为：Gvalidating；然后向T涉及的每个RM发送验证请求消息vrm和本地写集。

其中，验证请求消息ValidateRequestMessage vrm，vrm中的Lowts和Uppts分别记录了事务T在GlobalTS中事务逻辑时间戳上下界，另外随验证请求消息一同发往数据节点的还包括数据节点的本地写集。

II、事务T涉及到的每个数据节点收到验证请求消息vrm后，执行本地验证操作。

III、事务T的host node收到所有数据节点的本地验证反馈消息lvm后，根据收到的消息来决定事务T能否通过验证。

上述步骤1.1.2.2)的步骤II中，本地验证操作需要按序执行如下步骤：

①更新LocalTS中T的T.Lowts＝max(T.Lowts,vrm.Lowts)、T.Uppts＝min(T.Uppts,vrm.Uppts)，需要注意的是，这里更新的是本地事务状态表中事务的逻辑时间戳信息，用于事务并发访问控制，即用于保证事务一致性；

②检查T.Lowts是否大于T.Uppts，是则验证失败，向事务T的host node返回Abort消息(进而引发全局回滚),即发送本地验证反馈消息lvm，其中lvm.IsAbort＝1；否则进入下一步的验证；

③找到写集中的每一个数据项y，然后查看数据项y的WT是否为空：

如果不为空，则说明有其他事务正在修改数据项y，并且该事务已经进入了验证阶段，需要回滚事务T以消除写写冲突，即向事务T的host node发送Abort消息；

否则，继续下一步操作：对数据项y的WT加锁，防止其他并发事务并发修改y(在数据项y上施加建议锁，只互斥对数据项y的WT的修改操作)。

④更新写集中每个数据项y的WT为T.TID(表示进入验证阶段的事务T要修改y)，并调整本地事务状态表中事务T的时间戳下界，使其大于y的rts，即T.Lowts＝max(T.Lowts,y.cts+1)(消除读写冲突)；实现上，使用无锁的CAS技术(CAS(比较与交换,Compare andswap)是一种有名的无锁算法)为y的WT赋值，以提高性能(也不排除普通方式，如加锁后再为y的WT赋值)。

⑤检查T.Lowts是否大于T.Uppts，是则验证失败，本地回滚，然后向T的host node返回Abort消息；否则，并进入下一步的验证；

⑥对写集中每个元素y，调整事务T或者RTlist中事务的时间戳，消除读写冲突。

调整规则为：

a)读写冲突解决：本事务写、其他已经完成的事务过去发生的读，使得本事务写操作的发生推后到已经完成读的事务的读操作之后。

首先，找到所有的已处于提交或者通过本地验证状态的事务T1，调整T本身的时间戳区间下界，使其大于T1的Uppts，即T.Lowts＝max(T.Lowts,T1.Uppts+1)。

然后，检查事务T的时间戳区间是否依然合法，如果不合法，则返回Abort消息，否则更新事务T的本地事务状态为Validated，即T.Status＝Validated，并进入下一步调整。

b)读写冲突解决：本事务写，其他正在进行的事务读，使得其他事务读不到本事务写的数据：

找出所有处于Running状态的事务T2，调整T2的时间戳区间，使其时间戳上界小于T的Lowts。即T2.Uppts＝min(T2.Uppts,T.Lowts-1)。如果事务T2的Lowts>Uppts，则可通知事务T2应该回滚。

⑦到此步，表示事务T已经通过本地验证，根据y的更新值，创建y的新版本，但需要设置flag，表示新版本并未全局提交，在RUC-CC协议下对外不可见；

⑧向事务T的host node返回事务T的本地验证反馈消息lvm，其中lvm的Lowts和Uppts分别记录了事务T在本地数据节点上的逻辑时间戳上下界；其中需要注意的是，如果事务T本地验证失败，需要更新LocalTS中事务T状态为Aborted，即T.Status＝Aborted。

上述步骤1.1.2.2)的步骤III中，事务T的host node收到所有数据节点的本地验证反馈消息lvm后，根据收到的消息来决定事务T能否通过验证，其主要分为以下几种情况：

①如果含有IsAbort字段等于1的lvm，表明事务没有通过全部的本地验证，则决定全局回滚事务T；同时更新GlobalTS中事务的状态为：Gaborting；通知所有子节点完成回滚，即向相关数据节点发送写入提交/回滚消息coarm，其中coarm.IsAbort＝1。

②否则，将收到的所有事务T的时间戳区间求交集，得到新的时间戳区间[T.Lowts,T.Uppts]，如果T.Lowts>T.Uppts，则决定全局回滚事务，更新GlobalTS中T的状态为Gaborting，并通知所有子节点完成回滚；否则进入下一步；

③决定事务T通过验证，并从区间[T.Lowts,T.Uppts]随机选择一个时间点作为事务T的逻辑提交时间戳为cts赋值。如选择一个T.Lowts作为T的逻辑提交时间戳。

④更新GlobalTS中T.Lowts＝T.Uppts＝T.cts；更新GlobalTS中事务的状态为：Gcommitting；此时进一步将全局事务状态记为Gcommitted，同时请求全局Gts生成集群分配全局时间戳，记录到全局事务状态的Gts字段中。

⑤通知相关数据节点完成提交，即向相关数据节点发送写入提交/回滚消息coarm，其中coarm.IsAbort＝0，coarm.Cts和coarm.Gts分别记录了事务的逻辑时间戳和全局时间戳。

由上述规则可知，在事务T的验证阶段，通信主要在T的host node和相关子数据节点之间发生。通信主要包含以下两步：

a)T的host node向每相关子数据节点发送验证请求消息及数据节点的本地写集；

b)每个相关子数据节点发送本地验证反馈消息到T的host node。

因此，验证阶段最多需要2m次通信，通信量的大小为m×(请求验证消息大小+验证反馈消息大小)+全局写集大小，其中m为与事务T相关的子数据节点的个数。

一个优化点：如果事务是一个本地事务，在验证阶段，可将全局事务状态表中事务的状态修改为Gvalidating后，在本地数据节点直接执行验证流程(即1.1.2.2)的步骤II中的②～⑦)：

1)如果检测到事务需要回滚，则首先修改本地事务状态表为Aborted，并完成相关回滚操作，然后直接修改全局事务状态表为Gaborted；

2)如果事务顺利通过，则执行验证阶段并在本地数据节点执行完事务的提交操作。

上述步骤1.1.2.3)中，如果事务T通过验证则进入写入提交阶段，即将事务T对数据的更新持久化到数据库中，并做一些后续清理工作。本地数据节点在写入提交阶段需要执行如下操作：

I、对每个读集元素x：

a)修改x的rts，使其大于等于T.cts，即x.rtx＝max(x.rtx,T.cts)；

b)从RTlist(x)中将自己删除；

II、对每个写集元素y：

c)更新y新版本的wts和rts，其中wts＝T.cts；

d)更新y的rts＝max(x.rtx,T.cts)

e)将y持久化到数据库中，并修改flag，标识在RUC-CC协议下对外可见；

f)将y的RTlist列表内容清空；

g)将y的WT内容清空。

III、清空事务T的本地读集和写集；

IV、更新LocalTS中T的Lowts＝T.cts，以及状态为committed(此时本地事务状态表，仅用于事务一致性，没涉及全局事务状态的同步)

V、向事务T的host node返回完成提交成功的ACK；

事务T的host node收到所有完成提交ACK后，将全局事务状态修改为Gcommitted。并通知每个数据节点可以从本地事务状态表中清理事务T的状态。

如果事务T没有通过验证，进入全局回滚阶段，即将事务T回滚，并做相应的清理工作，清理工作内容包括：

I、对每个读集元素x，从RTlist(x)中将T删除；

II、对每个写集元素y，清理新创建的版本y，并将y的WT内容清空；

III、清空事务T的本地读集和写集；

IV、更新事务T的本地事务状态为Aborted；

V、向事务T的host node返回完成回滚的ACK；

由上述规则可知，在事务T的提交/回滚阶段，通信主要在事务T的host node和相关子RM之间发生，通信主要包含以下两步：

a)事务T的host node向每个相关子RM发送提交/回滚请求消息；

b)每个相关子RM向host node发送提交/回滚完成相应消息。

因此，提交/回滚阶段最多进行2m次通信，通信量的大小为m×(提交/回滚请求消息大小+提交/回滚请求消息大小)，其中m为事务T相关子RM的个数。

事务T的host node收到所有完成回滚ACK后，将全局事务状态修改为Gaborted。并通知每个RM可以从LocalTS中清理事务T的状态。一种优化方式是：***可以批量的向RM发送清理消息来减少通信次数。

上述步骤1.2)中，基于全局时间戳的线性一致性保证算法，在基于读事务开始时，向全局Gts生成集群获取的全局时间戳，来确定该读事务在***全局时钟下的顺序，从而确定哪些数据对于当前读事务符合线性一致性。本算法将事务在时间段内的操作看做是一个时间点上的操作，基于全局事务状态及全局时间戳，来保证事务之间的线性一致性，主要算法流程如下：

1.2.1)客户端发起事务T请求，由Proxy与其建立连接，形成一个会话。

1.2.2)Proxy将事务T进行解析，并选取host node来负责管理该事务的执行过程。

1.2.3)读事务T开始时，从全局Gts生成集群获得事务开始时的全局时间戳，并在该读事务的全局事务状态中记录Gts。host node与所有本读事务相关的数据节点建立连接，将解析后的查询执行计划和Gts形成数据包，通过网络通信下发给所有相关的数据节点。

1.2.4)数据节点各自进行数据读取操作，确定符合选择条件的数据项，然后对每一个有多个版本的数据项，从最新版本开始进行遍历，直至找到其第一个可见版本。

上述步骤1.2.4)中，对每一个逻辑数据项，找到第一个可见版本的方法为：

1.2.4.1)执行事务状态提取算法，获取产生该版本的写事务相对于当前读事务的事务状态快照。

1.2.4.2)利用Gts可见性判断算法，根据读事务全局时间戳和产生该版本写事务的事务状态快照，判断该版本是否可见。

上述步骤1.2.4.1)中，事务状态提取算法的目的是找到对于当前读事务T.Gts时刻产生某一版本的写事务的事务状态。该写事务如果没有全局提交，其状态在读事务执行过程中可能被更新，所以需要找到对读事务T，保证一致性的事务快照，该算法的流程如下：

I、根据数据版本v上的gts字段，读取产生该版本的事务的全局状态记录。

a)如果数据项上已经记录了全局时间戳Gts，则获得产生该数据项的事务已经处于已全局提交Gcommitted状态，且全局时间戳为Gts。

b)如果数据项上记录的是TID，需要根据TID中包含的RM.ID，通过网络通信向远程host node发送请求，在远程host node上的全局事务状态列表内查找TID对应的事务状态记录。

II、根据上一步中获取到的全局状态记录和读事务Gts，还原得到对读事务T，保证一致性的事务快照。

因为此时数据版本被读入内存，我们将快照信息将直接记录到版本v的gts字段上，供可见性判断算法使用。快照获取方法为：

a)如果数据版本v对应的全局事务状态记录的status为Gcommitted，则对v.gts进一步判断：

如果v.gts>Gts，则证明在Gts时刻产生版本v的事务未提交，v.gts置为T.Gts+1。

如果v.gts<＝Gts，则证明在Gts时刻为Gcommitted状态。因为本发明中在验证完成并进入提交阶段即进行全局提交确认，所以认为产生版本v的事务在Gts时已经全局提交，不需要修改v.gts。

b)如果v对应的全局事务状态记录的status为Grunning或者Gvalidating，则在T.Gts时产生版本v的事务一定未全局提交。

c)如果v对应的全局事务状态记录的status为Gaborted或者Gaborting，则对v.gts进一步判断：

如果v.gts>Gts，在Gts时刻产生版本v的事务为Grunning或Gvalidating或Gaborting状态(即未全局提交)；

如果v.gts<＝Gts，在Gts时刻产生版本v的事务为Gaborted状态。

上述步骤1.2.4.2)中，利用Gts可见性判断算法，根据读事务全局时间戳和产生该版本写事务的事务状态快照，判断该版本是否可见的具体流程为：

I、每个RM将可见数据形成数据包，通过网络通信发送给host node。

II、host node汇总所有数据节点返回的数据，并返回给Proxy，Proxy向建立会话关系的客户端返回数据，当前读事务完成。

III、该算法通过一轮通信，可以返回数据，且需要和“全局Gts生成集群”进行一次通信。

Gts可见性判断算法作用于各个数据节点上，用以判断得到全局线性一致的数据。根据只读事务Gts和元组上的gts字段，判断数据项是否可见。同时满足产生该版本的事务对于给出时间点已经全局提交和修改该版本的事务对于给出时间点全局还未完成，即可保证数据版本v对读事务T可见。因此，可见性的判断条件如下：

IV、如果满足v.info_bit！＝0&&v.gts<T.Gts，即满足当前gts字段记录的是全局时间戳Gts，并且v.gts小于T.Gts，则该版本可见，即符合线性一致性。

V、对于每个逻辑数据项，找到第一个满足判断条件的物理版本(最新可见版本)，即为该数据项对于本次读事务可见的版本。原因是版本的遍历过程是由较新版本到较老版本，所以当第一次条件被满足，读到的版本一定是数据项最新修改的可见版本。

上述步骤1.3)中，两次读线性一致性保证算法，是指在读事务开始时，省去向全局Gts生成集群申请全局时间戳的过程，采用进行两次数据读取的思路，并通过计算当前读操作的全局时间戳，来确定当前读操作在全局的顺序，从而获得符合全局线性一致的数据。其算法的主要过程如下：

1.3.1)客户端发起事务T请求，由Proxy与其建立连接，形成一个会话。

1.3.2)Proxy将事务T进行解析，并选取host node来负责管理该事务的执行过程。

1.3.3)第一轮通信，host node与所有本读事务相关的数据节点建立连接，向所有相关数据节点发送数据获取请求。所有相关数据节点执行第一次数据读取算法，并将数据返回给host node，host node基于所有返回的数据项确定当前读事务T的全局时间戳Gts。

1.3.4)第二轮通信，host node向所有相关数据节点发送数据获取请求，并将T.Gts发送给所有相关数据节点，在数据节点上执行第二次数据读取算法，返回对于T.Gts满足线性一致性的数据版本。

1.3.5)host node汇总数据节点返回的数据，并返回给Proxy，Proxy向建立会话关系的客户端返回数据，当前读事务完成。

上述步骤1.3.3)中，第一轮通信的具体流程为：

1.3.3.1)在每一个数据节点上，对符合选择条件的数据项，遍历每一个数据项的多个版本(从当前最新版本开始进行遍历)，对于每个版本v进行判断，直到找到符合条件的可见版本，并发送到host node。

1.3.3.2)host node根据接收到的可见版本，来确定当前读事务的全局时间戳，从而确定当前读事务T的全局顺序。具体的方法为：遍历所有读取到的数据版本，比对得到数据项上记录的最大的gts值，记为gts_max。则当前读事务的全局时间戳即为gts_max，即T.Gts＝gts_max。同时将T.Gts的最后一个bit置为1，标志当前事务为读事务，且标志其在全局中的顺序为gts_max之后，gts_max+1之前。

上述步骤1.3.3.1)中，对每个版本v进行判断的方法为：

I、如果数据项上已经记录了全局时间戳gts，则证明产生该数据项的事务已经全局提交，且全局时间戳为gts。此时当前该版本为可见版本。

II、如果数据项上在gts字段记录的是TID，在该数据节点上的全局事务状态列表中查找得到TID对应的全局事务状态记录。因为此时该TID对应的事务已经全局通过验证。此时当前该版本为可见版本，并将该数据项上的gts字段记录为TID.Gts。

III、如果数据项上在gts字段记录的是TID，在该数据节点上的全局事务状态列表中没有找到对应的全局事务状态记录，此时无法通过本地信息判断该版本是否可见。此时该版本不可见，需要继续循环并判断其前一个版本的可见性。

上述步骤1.3.4)中，第二轮通信是指在每一个数据节点上，对符合选择条件的数据项，遍历每一个数据项的多个版本(从当前最新版本开始进行遍历)，对于每个版本v，进行如下判断，找到符合线性一致性的数据版本，具体流程为：

1.3.4.1)如果数据项上已经记录了全局时间戳gts，则证明产生该数据项的事务已经全局提交，且全局时间戳为gts。判断如果T.Gts>＝gts，则当前版本为可见版本。

1.3.4.2)如果数据项上在gts字段记录的是TID，在该数据节点上的全局事务状态列表中查找得到TID对应的全局事务状态记录，因为此时该TID对应的事务已经全局通过验证。判断如果T.Gts>＝TID.Gts，则当前版本为可见版本。

1.3.4.3)如果数据项上在gts字段记录的是TID，在该数据节点上的全局事务状态列表中没有找到对应的全局事务状态记录，此时无法通过本地信息判断该版本是否可见。需要根据数据项上记录的全局TID和其中的RM.ID，通过网络通信向远程host node发送请求，在远程host node上的全局事务状态列表内查找TID对应的事务状态记录。需要判断如果TID.status＝Gcommitted or Gcommitting，且T.Gts>＝TID.Gts，则该版本可见，否则该版本不可见，需要继续循环并判断其前一个版本的可见性。

需要注意的是，该算法所采用的通过两次读取的策略来确定读事务全局时间戳的方式，可以判断读写操作之间的全局时钟顺序，但两个读事务之间的顺序无法确定。因此，我们需要在会话层面对读操作的顺序进行限定，来防止读读并发情况下的乱序问题。

上述步骤1.4)中，如图7所示，通过将不同技术进行组合，可以产生多种一致性级别，并达到不同的***效率，从而满足不同的业务需求。本发明中，将一致性级别分别如下四个级别(按外部一致性级别排序)：

完全一致性：代表***同时满足线性一致性和事务一致性，是一致性级别中的最高级别。

线性一致性：代表***完全满足线性一致性的要求，但对事务一致性的保证不做要求。

事务因果一致性：代表***完全满足事务一致性且满足因果一致性。

事务逻辑一致性：代表***完全满足事务一致性但对于外部一致性的级别不做要求。

上述步骤1.4)中，根据划分的四个级别，对事务一致性和线性一致性进行组合的方法为：

1.4.1)将DTA(Dynamic Timestamp Allocation，以下简称DTA)+OCC(OptimisticConcurrency Control,以下简称OCC)算法与MVCC(Multi-Version Concurrency Control，以下简称MVCC)相结合，提出RUC-CC算法以使分布式***满足事务逻辑一致性的要求。

1.4.2)根据MVCC算法与全局Gts相结合，以使分布式***满足全局事务操作满足线性一致性的要求。

1.4.3)在RUC_CC算法中引入全局Gts，以使分布式***满足事务因果一致性的要求。

1.4.4)将RUC-CC算法与线性一致性算法相结合，以使分布式***满足完全一致性的要求。

1.4.5)对步骤1.4.1)～1.4.4)中的多种一致性级别的***执行效率进行比较。

上述步骤1.4.1)中，RUC-CC算法，利用将MVCC的思路结合到DTA+OCC的算法中，实现了较为高效的可串行化隔离级别，主要论证过程如下：

a)在步骤1.1.2.1)部分中介绍的读取阶段的规则中，本发明使用了MVCC技术。存在并发事务T1和T2，如果T2修改了数据项x，从x0版本修改到x1版本，T1需要读取数据项x。本发明利用多版本机制，T1会读取到T2修改前的版本x0，从而消除了则T2和T1之间的写读依赖关系，即***中的任何并发事务之间不存在写读冲突。

b)由于T1会读到T2修改前的版本，因此，逻辑上T1先读，T2再写，存在读写依赖关系。因而保证了MVCC中的“读写互不阻塞”的重要特性。且该依赖关系通过数据结构中的RTlist结构进行了维护，从而用于冲突可串行化的保证。

c)因为写读冲突被消去，且读写冲突用较为轻量级的方式进行了维护，从而在保证可串行化基础上，可以降低事务的回滚率，并提升事务调度的效率，因此，该方法具有较高效的事务调度性能。

上述步骤1.4.2)中，本发明中提出的线性一致性保证算法结合了MVCC的思路，基于***内维护的多个版本，从多个版本中读取到符合线性一致性的数据。本发明中提出的三个算法对于符合线性一致性的数据的可见性判断方法不尽相同，但均基于MVCC的思路进行。例如，基于全局时间戳Gts的算法中，版本的可见性通过数据项上的gts字段和读事务的Gts之间进行比较即可判断，从而利用了多版本的思路，可以方便的定位具体的符合线性一致性的数据版本。

上述步骤1.4.3)中，DTA+OCC算法如果与全局Gts生成技术结合，可保证外部一致性中的因果一致性，论证过程如下。因果一致性的要求为：具有因果联系的操作需要按照因果逻辑有序。

a)假设有事务T1和事务T2存在如下偏序关系：

i.首先事务T1更新数据项R并产生版本R1，然后T1事务提交获得全局时间戳。ii.然后事务T2更新数据项R并产生元组R2，然后T2事务提交获得全局时间戳。

b)假设事务T3和事务T4的操作均为读取数据项R，且与事务T2并发，且存在偏序关系为T3在T4之前。

此时，我们保证因果一致性的方法为：

a)对于每一个事务，隶属于某一个会话(由客户端和***服务建立连接时维护)，都会与“全局Gts生成集群”进行交互，从而获得到各自的顺序。例如T3和T4之间即通过“全局Gts生成集群”保证了顺序为T3要先于T4。

b)T3事务先于T4事务提交，基于DTA+OCC算法，如果T3事务的逻辑时间戳调整到T2之后，即读到版本R2；如果T3事务的逻辑时间戳调整到T2之前，即读到版本R1。因此，T3事务有可能读到版本R1和R2中的一个。

c)T4事务后提交，因此，在T3读到R1的情况下，T4只能读取R1或者R2，不存在读取R0的调度；在T3读到R2的情况下，T4的逻辑时间戳也必然大于T2，因此只能读到R2。

DTA+OCC算法，本身保证了事务一致性，但是如果不结合MVCC，会有回滚率较高的问题，因此，从事务调度层面来看该算法的效率较低。

上述步骤1.4.4)中，将三个技术进行结合，即可实现统一了事务一致性和线性一致性的“完全一致性”(统一致性)，作为分布式数据库***中的最高一致性级别。“完全一致性”的保证具有较大的事务验证开销，因此会在一定程度上影响***性能。但由于一致性和***效率之间存在权衡关系，因此，保证完全一致性需要牺牲一定的***性能。

在“完全一致性”隔离级别下，读操作需要将RUC-CC算法与基于时间戳的线性一致性保证算法结合起来使用，因此，读事务的运行过程需要扩充如下：

a)首先，事务开始时，与“全局Gts生成集群”进行通信，获取当前读事务的全局时间戳T.Gts。

b)然后，在读取阶段，通过DTA+OCC算法获取到所需数据。

c)之后，对读取到的数据进行线性一致性验证操作，此时需要调用基于全局时间戳的线性一致性保证算法，判断当前读到的数据是否符合线性一致性。

i.如果所有数据均通过了线性一致性判断，则汇总数据并返回给用户。

ii.如果存在数据不能通过线性一致性判断，此时有两种处理方法：(1)此读事务回滚；(2)对该读事务进行重试，如果重试三次(参数，可设置)仍然无法读到符合条件的数据，则该事务回滚。

在“事务因果一致性”级别下，出于性能考虑，对于三个技术的结合，也可以实现高效的事务因果一致性。因为DTA+OCC算法结合全局Gts生成技术，即可保证事务因果一致性。此时融合MVCC，即可降低DTA+OCC中的回滚率，从而提升***性能。在此一致性级别下，不用对读操作进行如上所述的线性一致性验证，因而提高了读操作的执行效率。

上述步骤1.4.5)中，不同的一致性级别，需要通过本发明中所提出的不同技术组合来保证，因此，***的效率也会有所差异。我们将不同一致性级别下影响效率的因素进行了总结，并论证了较弱的一致性级别可以具有较好的***效率，但是，由于一致性要求与***效率间的关系必然是负相关，因此，较高的一致性级别性能表现较弱可以被容忍：

①完全一致性级别，必须采用RUC-CC算法结合线性一致性保证算法才能保证。因此，两个算法联合要求额外进行如下两个操作，从而带来一定的性能损耗：

a)读操作额外验证。读操作要求对读取到的数据进行一致性验证，才能使得读到的数据在保证事务一致性的同时保证线性一致性。因此，对两个算法的联合使用，加重了数据验证开销，从而引起性能损耗。

b)事务的额外回滚。存在由RUC-CC算法产生的事务调度满足事务一致性，但不满足线性一致性的情况。所以在完全一致性级别下，这类事务需要被回滚，从而造成了额外的回滚开销。

②线性一致性，由线性一致性保证算法即可保证。省去了完全一致性级别保证中所要求的读操作额外验证和事务的额外回滚操作，因此相较于完全一致性级别具有一定的性能提升。

③事务因果一致性级别，由DTA+OCC+全局时钟保证，进一步省去了执行线性一致性保证算法所造成的开销，因此相较于线性一致性级别具有一定的性能提升。

④事务逻辑一致性，由RUC-CC算法保证。该算法不对外部一致性的保证进行考虑，因此，进一步省去与全局时钟通信的开销。因此相较于事务因果一致性级别具有一定的性能提升。

上述步骤2)中，根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的分布式事务和单机事务进行执行，包括以下步骤：

2.1)依据事务是否需要对多个资源管理节点上的数据进行操作，将分布式***中涉及的事务分为分布式事务和单机事务两种。

2.2)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的分布式事务进行执行；

2.3)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的单机事务进行执行。

上述步骤2.1)中，对分布式***中涉及的事务进行分类是因为分布式数据库***中，最小的操作执行单元为事务。依据事务是否需要对多个数据节点上的数据进行操作，事务可以被分为分布式事务和单机事务两种。针对于这两种事务，本发明分别采取不同的执行流程，来尽量减少节点间的通信开销，提升事务处理效率。

其中，分布式事务代表事务需要跨多个资源管理节点进行读写操作，即事务会对多个RM上的数据进行操作。例如，事务T需要操作节点RM1、RM2和RM3，则该事务为一个分布式事务。这种情况下需要引入协调节点host node，用以在事务执行过程中存放全局事务状态信息，并对事务的执行过程进行管理。协调节点host node的选取方式有如下两种：

a)随机选取机制，即从host node集合中随机选取一个节点，作为host node。

b)确定选取机制，即通过某一确定规则来选取host node。如定义选取规则为从host node集合中通过轮询机制来进行选取。

单机事务代表事务只需要对单个数据节点上的数据进行操作，例如，事务T需要操作节点RM1，则该事务为一个单机事务。单机事务在执行过程中，只需要同协调节点进行一轮通信即可。

上述步骤2.2)中，根据不同一致性级别要求对分布式***中的分布式事务进行执行的流程为：

2.2.1)Client客户端负责发出执行事务T的请求，Proxy负责接收客户端发来的请求，并与客户端建立会话关系。

2.2.2)Proxy接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，路由SQL语句到不同的host node。

2.2.3)host node优化SQL并生成物理执行计划，并进行全局事务初始化工作，记录全局事务状态信息等，然后将执行计划分解为每个节点上的执行计划，发送到相应的数据节点，并将全局事务状态记为正在运行状态。

2.2.4)数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务执行状态，当数据节点本地执行数据读写完成后，向host node发送“可以验证”指令；具体的：

当为事务逻辑一致性和事务因果一致性要求时：数据节点根据执行计划，采用步骤2.1)中的RUC-CC算法进行数据操作和事务调度。

当为线性一致性级别要求时：数据节点根据执行计划，采用步骤1.2)中的线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度。

当为完全一致性级别要求时：数据节点根据执行计划，采用步骤1.2)中的线性一致性保证算法结合步骤1.1)中的RUC-CC算法进行数据操作和事务调度。

2.2.5)host node收到全部相关数据节点发来“可以验证”指令后，记录全局事务状态为正在验证，并向所有相关数据节点发送“进行验证”指令。

2.2.6)数据节点收到“进行验证”指令后，采用步骤1.1.2.2)中的验证方法进入本地验证流程，如果验证通过，则发送“验证通过”指令给host node。

2.2.7)host node收到全部相关数据节点发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与“全局Gts生成集群”进行交互以获取事务的全局时间戳，并记录全局事务状态为已提交。然后，同时开启两个线程：第一个用来将结果集返回给Proxy，由Proxy负责将执行结果返回给客户端；第二个将向所有相关数据节点发送“进行提交”指令。

当为事务逻辑一致性要求时：host node收到全部相关数据节点发来的“验证通过”指令后，记录全局事务状态为已提交。

当为事务因果一致性级别、线性一致性和完全一致性要求时：host node收到全部相关数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交。

2.2.8)数据节点收到“进行提交”指令后，采用步骤1.1.2.3)的提交方法进入本地提交流程。

上述步骤2.3)中，根据不同一致性级别要求对分布式***中的单机事务进行执行的流程为：

2.3.1)Client客户端负责发出执行事务T的请求，Proxy负责接收客户端发来的请求，并与客户端建立会话关系。

2.3.2)Proxy接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，通过路由分配给不同的host node。

2.3.3)host node优化SQL，并生成物理执行计划，将物理执行计划发送给选定的事务协调节点host node。Host node进行事务初始化工作，记录事务状态为正在运行后，直接将执行计划发送到相应的数据节点。

2.3.4)数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务状态，当数据节点本地执行数据读写完成后，直接进入验证流程，如果验证通过，则发送“验证通过”指令给host node，并进入本地提交流程。

当为事务逻辑一致性和事务因果一致性级别要求时，数据节点通过RUC-CC算法进行数据操作和事务调度；

当为线性一致性级别要求时，数据节点通过步骤1.2)中的线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度；

当为完全一致性级别要求时，数据节点通过步骤1.2)中的线性一致性保证算法结合步骤1.1)中的RUC-CC算法进行数据操作和事务调度。

2.3.5)host node收到RM发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与全局Gts生成集群进行交互以获取事务的全局时间戳，并记录事务状态为已提交，然后将结果集返回给Proxy，由Proxy负责将执行结果返回给客户端。

当为事务逻辑一致性要求时：host node收到全部相关数据节点发来的“验证通过”指令后，记录全局事务状态为已提交。

当为事务因果一致性级别、线性一致性和完全一致性要求时：host node收到全部相关数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交。

上述方法中，特殊的，在事务处理过程中，如果事务的读写集较大，超过了***的内存承受能力，则事务会因内存溢出而无法执行。为解决这个问题可以采用以下3种方法：

1.阈值法：当事务T在某个RM的读集或写集大小超过某一阈值threshold时，则终止事务T的执行，防止事务T将***内存耗光，其它事务无法执行，其中threshold的选择可以通过参数进行配置，例如其大小可以等于该RM可用内存的60％。该方法简单易用，但是可能会使这些读写集较大的事务无法得到执行；

2.转储法：当事务T在某个数据节点的读集或写集大小超过某一threshold时，则将事务T的读集或写集刷到磁盘上，当事务T需要访问自己的读写集合时，再将其读入内存，其中threshold的选择可以通过参数进行配置，例如其大小可以等于RM可用内存的60％。该方法虽然不需要终止事务T的执行，但是因为需要读写磁盘，带来了额外I/O代价；

3、优化法：当只读事务T读集过大时，可以不采用RUC-CC的并发访问控制算法进行调度，使用基于全局时间戳的线性一致性保证算法进行数据读取。

需要说明的是，本发明中表述“外部一致性”，是一个泛化的概念，即所有分布式***一致性诸如线性一致性、因果一致性、单调读、单调写等都包括在“外部一致性”的范畴内。全局时钟，是一个逻辑全序的含义，并不特定指物理时间戳。

上述各实施例仅用于说明本发明，其中各部件的结构、连接方式和制作工艺等都是可以有所变化的，凡是在本发明技术方案的基础上进行的等同变换和改进，均不应排除在本发明的保护范围之外。

Claims (15)

1.一种保证事务一致性和线性一致性的分布式***，其特征在于：其包括：多个客户端以及由接入层、元信息管理集群、全局Gts生成集群和事务处理及存储层构成的数据库服务端；

所述客户端用于为用户提供与所述数据库服务端进行交互的接口，将用户请求发送到所述数据库服务端；

所述接入层用于接收所述客户端发送的请求，并解析生成执行计划；

所述元信息管理集群用于对所述分布式***的分布式集群进行统一管理；

所述全局Gts生成集群，用于生成全局时间戳，对分布式***中的全局事务进行唯一排序以实现线性一致性；

所述事务处理及存储层包括多个资源管理节点，所述资源管理节点包括协调节点和数据节点，所述协调节点和数据节点用于根据接入层发送的执行计划执行事务逻辑，得到的结果经所述接入层返回所述客户端。

2.如权利要求1所述的一种保证事务一致性和线性一致性的分布式***，其特征在于：所述数据节点用以将所述分布式***中的数据进行分区存放，所述协调节点用于对所述分布式***中的事务进行协调处理；对于所有所述资源管理节点的用途，有如下两种分配方式：

主从模式：将其中一部分资源管理节点专门用做事务处理的协调节点，同时将剩余资源管理节点用作数据节点；

对等模式：所有所述资源管理节点是对等的，每个所述资源管理节点都同时具有数据节点和协调节点两个功能。

3.如权利要求1所述的一种保证事务一致性和线性一致性的分布式***，其特征在于：所述全局Gts生成集群的全局时间戳由八字节组成，且八字节采用混合物理时钟方式组成：

a)前44位为物理时间戳值；

b)后20位为在一毫秒内的单调递增计数。

4.如权利要求1所述的一种保证事务一致性和线性一致性的分布式***，其特征在于：所述分布式***涉及的基本数据结构包括全局事务状态表、本地事务状态表、数据项数据结构、事务的全局读集写集以及通信协议及消息四类数据结构；

所述全局事务状态表用于维护从分布式***全局来看的事务状态，用六元祖{TID,Lowts,Uppts,Status,Gts,Nodes}表示，其中，TID代表事务唯一标识，Lowts代表事务逻辑提交时间戳下界，Uppts代表事务逻辑提交时间戳上界，Status代表当前事务在全局所处的状态，Gts代表事务全局提交/回滚完成的时间戳，Nodes代表当前事务涉及到的数据节点；

所述本地事务状态表用于维护事务在每个资源管理节点上的本地事务状态，用{TID,Lowts,Uppts,Status}表示，其中，TID代表事务唯一标识，Lowts代表事务逻辑提交时间戳下界，Uppts代表事务逻辑提交时间戳上界，Status代表事务的本地状态；

所述数据项数据结构包括作为线性一致性依据的第一组数据元素和作为分布式事务一致性的第二组数据元素，所述第一组数据元素包括{gts,info_bit}，其中，gts代表一个事务在分布式***中的全局唯一的顺序，info_bit用以标识当前在gts字段中记录的是Gts还是TID；所述第二组数据元素包括{wts,rts}，其中，wts用于记录创建该数据项版本的事务的逻辑时间戳，rts用于记录最新读过该数据项的事务的逻辑时间戳；

所述事务的全局读集用于记录事务所读全部数据项，用{BlockAddress,Offset,Size,Value}表示，其中，BlockAddress代表数据项对应块地址，Offset代表数据项在块内的偏移量，Size代表数据项大小，Value代表数据项值；

所述事务的全局写集用于记录事务需要更新的全部数据项，用{BlockAddress,Offset,Size,NewValue，OperationType}表示，其中，BlockAddress代表数据项对应块地址，Offset代表数据项在块内的偏移量，Size代表数据项大小，NewValue代表数据项值，OperationType代表操作是更新、***还是删除操作；

所述通信协议及消息包括所述协调节点发往所述数据节点的消息、所述数据节点发往所述协调节点的消息、所述协调节点发往所述全局Gts生成集群的消息、所述全局Gts生成集群发往所述协调节点的消息；所述协调节点发往所述数据节点的消息包括读数据请求消息、验证请求消息、写入提交/回滚请求；所述数据节点发往所述协调节点的消息包括读请求反馈消息、本地验证反馈消息；所述协调节点发往所述全局Gts生成集群的消息包括全局时间戳请求消息；所述全局Gts生成集群发往所述协调节点的消息包括全局时间戳请求反馈消息。

5.一种采用如权利要求1～4任一项所述保证事务一致性和线性一致性的分布式***的多级别一致性方法，其特征在于包括以下步骤：

1)建立能够实现多级别一致性的统一致性模型；

2)根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性要求的一致性执行算法，对分布式***中的分布式事务和单机事务进行执行，得到事务执行结果。

6.如权利要求5所述的一种多级别一致性方法，其特征在于：所述步骤1)中，建立能够实现多级别一致性的统一致性模型的方法，包括以下步骤：

1.1)采用基于DTA的OCC策略进行事务并发访问控制，建立用于保证事务一致性的RUC-CC算法；

1.2)基于全局Gts生成集群生成的全局时间戳以及全局事务状态，建立基于全局时间戳的线性一致性保证算法，用于保证事务之间线性一致性；

1.3)采用进行两次数据读取的方法，建立两次读线性一致性保证算法，用于保证事务之间一致性；

1.4)将步骤1.1)～步骤1.3)的事务一致性和线性一致性以及MVCC算法进行组合，建立能够满足多种一致性级别的统一致模型。

7.如权利要求6所述的一种多级别一致性方法，其特征在于：所述步骤1.1)中，采用基于DTA的OCC策略进行事务并发访问控制，建立RUC-CC算法的方法，包括以下步骤：

1.1.1)对由客户端发送的事务T，在协调节点上完成相应的初始化工作；

1.1.2)将事务的全局执行阶段分为3个阶段：读取阶段、验证阶段以及提交写入/回滚阶段，并在协调节点的协调下，与操作相关的各数据节点对事务进行执行，并对事务状态表中提交或回滚事务的对应表项进行清除。

8.如权利要求7所述的一种多级别一致性方法，其特征在于：所述步骤1.1.2)中，将事务的全局执行阶段分为3个阶段：读取阶段、验证阶段以及提交写入/回滚阶段，并在协调节点的协调下，与操作相关的各数据节点对事务进行执行，包括以下步骤：

1.1.2.1)事务T按照执行逻辑读取所需数据，并将更新写到事务T的本地内存，1.1.2.2)事务T验证自身是否同其他事务存在冲突，得到验证结果；

1.1.2.3)事务T根据验证阶段的验证结果，选择执行写入提交还是回滚。

9.如权利要求8所述的一种多级别一致性方法，其特征在于：所述步骤1.1.2.1)中，事务T按照执行逻辑读取所需数据，并将更新写到事务T的本地内存的方法为：

首先，事务T的协调节点需要向数据项x所在的数据节点发送读数据项x的读数据请求消息；

然后，数据项x所在数据节点收到读数据请求消息后，首先对事务T的本地事务状态表进行建立或更新，然后在事务T的逻辑生命周期内查找数据项x的可见版本，并向事务T的协调节点发送读请求反馈消息；

最后，事务T的协调节点收到所有数据节点的读请求反馈消息后，对是否需要回滚进行判断，如果需要回滚，则进入全局回滚阶段，否则事务继续执行。

10.如权利要求8所述的一种多级别一致性方法，其特征在于：所述步骤1.1.2.2)中，事务T验证自身是否同其他事务存在冲突，得到验证结果的方法为：

首先，事务T的协调节点修改全局事务状态表中事务T的状态为：Gvalidating；然后向事务T涉及的每个数据节点发送验证请求消息和本地写集；

其次，事务T涉及到的每个数据节点收到验证请求消息后，执行本地验证操作，具体包括以下步骤：

①更新本地事务状态表中事务T的T.Lowts＝max(T.Lowts,vrm.Lowts)、T.Uppts＝min(T.Uppts,vrm.Uppts)；

②检查T.Lowts是否大于T.Uppts，是则验证失败，向事务T的协调节点返回Abort消息进入回滚，否则进入步骤③；

③找到事务写集中的每一个数据项y，然后查看数据项y的WT是否为空：

如果不为空，则向事务T的协调节点发送Abort消息进入回滚；

否则进入步骤④；

④更新写集中每个数据项y的WT为T.TID，并调整本地事务状态表中事务T的时间戳下界，使其大于y的rts；

⑤检查T.Lowts是否大于T.Uppts，是则验证失败，本地回滚，然后向事务T的协调节点返回Abort消息；否则，进入步骤⑥；

⑥对写集中每个元素y，调整事务T或者RTlist中事务的时间戳，消除读写冲突；

⑦根据数据项y的更新值，创建数据项y的新版本，同时设置表示新版本并未全局提交的flag；

⑧向事务T的协调节点返回事务T的本地验证反馈消息lvm，其中lvm的Lowts和Uppts分别记录了事务T在本地数据节点上的逻辑时间戳上下界；

最后，事务T的协调节点收到所有资源管理节点的本地验证反馈消息后，根据收到的消息来决定事务T能否通过验证。

11.如权利要求6所述的一种多级别一致性方法，其特征在于：所述步骤1.2)中，基于全局Gts生成集群生成的全局时间戳以及全局事务状态，建立的基于全局时间戳的线性一致性保证算法，包括以下步骤：

1.2.1)客户端发起事务T请求，由接入层与其建立连接，形成一个会话；

1.2.2)接入层将事务T进行解析，并选取协调节点来负责管理该事务的执行过程；

1.2.3)读事务T开始时，从全局Gts生成集群获得事务开始时的全局时间戳，并在该读事务的全局事务状态表中记录Gts；协调节点与所有本读事务相关的数据节点建立连接，将解析后的查询执行计划和全局时间戳Gts形成数据包，通过网络通信下发给所有相关的数据节点；

1.2.4)所有数据节点各自进行数据读取操作，确定符合选择条件的数据项，然后对每一个有多个版本的数据项，从最新版本开始进行遍历，直至找到其第一个可见版本；

1.2.5)协调节点汇总所有数据节点返回的数据，并返回给接入层，接入层向建立会话关系的客户端返回数据，当前读事务完成。

12.如权利要求6所述的一种多级别一致性方法，其特征在于：所述步骤1.3)中，采用进行两次数据读取的方法，建立的两次读线性一致性保证算法的流程为：

1.3.1)客户端发起事务T请求，由接入层与其建立连接，形成一个会话；

1.3.2)接入层将事务T进行解析，并选取协调节点来负责管理该事务的执行过程；

1.3.3)协调节点与所有本读事务相关的数据节点建立连接，向所有相关数据节点发送数据获取请求，所有相关数据节点执行第一次数据读取算法，并将数据返回给协调节点，协调节点基于所有返回的数据项确定当前读事务T的全局时间戳Gts；

1.3.4)协调节点向所有数据节点再次发送数据获取请求，并将确定的当前读事务T的全局时间戳Gts发送给所有数据节点，在数据节点上执行第二次数据读取算法，返回对于当前读事务T的全局时间戳Gts满足线性一致性的数据版本；

1.3.5)协调节点汇总所有数据节点返回的数据，并返回给接入层，接入层向建立会话关系的客户端返回数据，当前读事务完成。

13.如权利要求6所述的一种多级别一致性方法，其特征在于：所述步骤2)中，根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的分布式事务进行执行的方法，包括以下步骤：

2.1)依据事务是否需要对多个资源管理节点上的数据进行操作，将分布式***中涉及的事务分为分布式事务和单机事务两种；

2.2)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的分布式事务进行执行；

2.3)采用与一致性级别要求相适应的一致性执行算法，对分布式***中的单机事务进行执行。

14.如权利要求13所述的一种多级别一致性方法，其特征在于：所述步骤2.2)中，采用与一致性级别要求相适应的一致性执行算法，对分布式***中的分布式事务进行执行的流程为：

2.2.1)客户端负责发出执行事务T的请求，接入层负责接收客户端发来的请求，并与客户端建立会话关系；

2.2.2)接入层接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，并通过路由分配给不同的协调节点；

2.2.3)协调节点优化SQL并生成物理执行计划，并进行全局事务初始化工作，记录全局事务状态信息，然后将执行计划分解为每个数据节点上的执行计划，发送到相应的数据节点，并将全局事务状态记为正在运行状态；

2.2.4)各数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务执行状态，当数据节点本地执行数据读写完成后，向协调节点发送“可以验证”指令；具体的：

当为事务逻辑一致性和事务因果一致性要求时：数据节点根据执行计划，采用RUC-CC算法进行数据操作和事务调度；

当为线性一致性级别要求时：数据节点根据执行计划，采用线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度；

当为完全一致性级别要求时：数据节点根据执行计划，采用线性一致性保证算法结合RUC-CC算法进行数据操作和事务调度；

2.2.5)协调节点收到全部相关数据节点发来“可以验证”指令后，记录全局事务状态为正在验证，并向所有相关数据节点发送“进行验证”指令；

2.2.6)数据节点收到“进行验证”指令后；进入本地验证流程，如果验证通过，则发送“验证通过”指令给协调节点；

2.2.7)协调节点收到全部相关数据节点发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与全局Gts生成集群进行交互以获取事务的全局时间戳，并记录全局事务状态为已提交；然后，同时开启两个线程：第一个用来将结果集返回给接入层，由接入层负责将执行结果返回给客户端；第二个将向所有相关数据节点发送“进行提交”指令；

当为事务逻辑一致性要求时：协调节点收到全部相关数据节点发来的“验证通过”指令后，记录全局事务状态为已提交；

当为事务因果一致性级别、线性一致性和完全一致性要求时：协调节点收到全部相关数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交；

2.2.8)各数据节点收到“进行提交”指令后，进入本地提交流程。

15.如权利要求13所述的一种多级别一致性方法，其特征在于：所述步骤2.3)中，根据实际的业务需求确定分布式***需要达到的一致性级别，并基于建立的统一致性模型确定适用于该一致性级别要求的一致性执行算法，对分布式***中的单机事务进行执行的方法，包括以下步骤：

2.3.1)客户端负责发出执行事务T的请求，接入层负责接收客户端发来的请求，并与客户端建立会话关系；

2.3.2)接入层接收到请求信息后，与元数据管理集群进行交互，获取相关元信息后，对请求分析，通过路由分配给不同的协调节点；

2.3.3)协调节点优化SQL，并生成物理执行计划，将物理执行计划发送给选定的数据节点，协调节点进行事务初始化工作，记录事务状态为正在运行后，直接将执行计划发送到相应的数据节点；

2.3.4)数据节点根据执行计划，分别采用与一致性级别要求相适应的算法进行数据操作，并记录本地事务状态，当数据节点本地执行数据读写完成后，直接进入验证流程，如果验证通过，则发送“验证通过”指令给协调节点，并进入本地提交流程；

当为事务逻辑一致性和事务因果一致性级别要求时，数据节点通过RUC-CC算法进行数据操作和事务调度；

当为线性一致性级别要求时，数据节点通过线性一致性保证算法进行数据操作，并基于MVCC算法进行事务调度；

当为完全一致性级别要求时，数据节点通过线性一致性保证算法结合RUC-CC算法进行数据操作和事务调度；

2.3.5)协调节点收到数据节点发来的“验证通过”指令后，根据不同一致性级别要求确定是否需要与全局Gts生成集群进行交互以获取事务的全局时间戳，并记录事务状态为已提交，然后将结果集返回给接入层，由接入层负责将执行结果返回给客户端；

当为事务逻辑一致性要求时：协调节点收到数据节点发来的“验证通过”指令后，记录全局事务状态为已提交；

当为事务因果一致性级别、线性一致性和完全一致性要求时：协调节点收到数据节点发来的“验证通过”指令后，需要同全局Gts生成集群进行交互，获取事务的全局时间戳，并记录全局事务状态为已提交。

Images