CN112214649B - 一种时态图数据库分布式事务解决*** - Google Patents

Abstract

本发明通过人工智能领域的方法，实现了一种时态图数据库分布式事务解决***，设置客户端、master中心节点，Coordinator，participant结构，通过设计改进两阶段提交对时态图数据库分布式事务进行扩展，并设计时态图数据库在分布式环境中的并发控制机制以及故障恢复机制，对两阶段流程的改进与内存MVCC的设计，提升了在分布式环境中对时态图数据操作的速度，并与现有其他支持事务的分布式数据库TiDB相比有更好的性能，在时态图数据的存储上可以很好的提高读写的并发性能，同时缩小事务执行的时间。

Description

一种时态图数据库分布式事务解决***

技术领域

本发明涉及人工智能领域，尤其涉及一种时态图数据库分布式事务解决***。

背景技术

物联网的发展使得数据每时每刻都在不停的产生，不断产生的数据携带着时间属性，使得我们能够使用时态属性进行分析应用。时态图数据的主要特点有以下几点：图结构变化少，时态属性不断生成，数据量巨大，并发高。对于时态图数据的存储，出现了许多解决方案，但是要将其在分布式数据库中正确的存储，始终绕不开的一个话题就是分布式事务。

数据库事务是构成单一逻辑工作单元的操作集合，可以避免出现部分操作成功和多个用户同时操纵数据库时出现异常等情况。事务具有ACID(原子性、一致性、隔离性、持久性)四大特性，主要通过并发控制与日志恢复实现。传统的并发控制方式主要有基于锁实现、基于时间戳实现、基于有效性检查实现、多版本并发控制等几种方式。日志恢复技术主要包括undo日志、redo日志和设置检查点，通过这三种方式结合可以避免事务故障与***故障。

事务的类型可以分为flat transaction、Checkpoints and save pointstransaction、Distributed and nested transactions和Chained transactions。不同的事务类型有不同的适用场景，flat transaction在当下的***中最常见，所有操作都是处于同一层次，其由BEGINWORK开始，由COMMIT WORK或ROLLBACK WORK结束，期间的操作是原子的，要么都执行，要么都回滚。现有的TGraph事务为单机事务，仅适用于单机数据库。而对于时态图数据而言，单机数据库存在许多局限，如单机***在并发性能上依旧欠佳，无法支持高并发的场景。不仅如此，单机TGraph存储容量存在上限，而时态图数据是源源不断的写入，理论上是不存在上限的，故单机节点也难以保证超大时态图数据的存储。最后，单机TGraph若发生故障，则整个***将无法提供服务，而时态图数据是不断写入的，需要***能长时间稳定的支持时态图数据的读写服务。因此时态图数据库更适合在分布式环境中存储，而TGraph单机事务仅针对数据单机存放，不适用于分布式场景，其并发控制采用的两阶段锁在分布式环境中的表现也非常差。本专利事务类型为分布式事务(Distributedtransaction)，分布式事务依据视图拓扑结构将顶层事务才分为多个子事务，子事务一般为flat transaction。

分布式事务的经典设计模型有两阶段提交、三阶段提交、补偿事务、消息队列等。两阶段提交与三阶段提交分别将事务分为两个阶段和三个阶段，保证了原子性，却使得事务的性能也非常的差。与两阶段、三阶段提交不同的是，补偿事务、消息队列是在业务层面进行两阶段，可以针对业务来确定加锁粒度等、但是二者又有区别，消息队列是异步的，而补偿事务是同步的。

现有的分布式事务以TiDB为代表，采用两阶段提交的方式对事物进行提交，在并发控制时，事务两次从中心节点获取时间戳作为起始版本号，并基于该版本号进行并发控制，但是它不适用于时态图的存储，事务网络交互过多也带来了一定隐患。其原因在于，首先，由于整个事务处理流程网络交互很多，网络交互的增加将会为***带来更多的不确定性。常用的应对方法为将小事务进行合并，合成一个大事务进行处理。然而在许多场景下是无法将小事务合并为大事务处理的。其次TiDB没有对时态图数据进行特定的设计底层的存储，TiKV的存储模块设计既不适合图数据的存储，也不适合时态数据的存储。

那么，就需要对现有技术进行如下方向的改进：

1)分布式扩展单机时态图数据库操作。

当前单机时态图数据库***所有数据都在一个服务器存储，故所有操作都是按照单机进行设计。而在分布式***中，数据分散存储在多个节点，一个事务的操作可能需要多个服务器协同完成，这是单机时态图数据库事务所不能胜任的，因此本事务的设计目标之一是使时态图数据库事务支持分布式操作，支持事务跨存储节点。

2)在分布式环境中保持时态图数据库事务的ACID特性。

在单机环境中时态图数据库使用两阶段锁的形式进行并发控制，维护事务的ACID特性。但是在分布式环境中，两阶段锁的申请与释放将会消耗大量的时延，事务持有锁的时间大大增加，使得并发性能降低。故在分布式环境中保证ACID特性已不能再使用单机时态图数据库两阶段锁的方案，需要重新设计新的并发控制方案来维护时态图数据库分布式事务的AICD特性。

发明内容

为此，本发明提出了一种时态图数据库分布式事务解决***，***设置客户端、Coordinator、master、participant，所述master为中心节点，用于维持心跳并提供全局唯一版本号，所述Coordinator为第二阶段选取的存储节点来指挥其他存储节点进行统一提交，所述participant为其他存储节点，通过设计改进两阶段提交对时态图数据库分布式事务进行扩展，并设计时态图数据库在分布式环境中的并发控制机制以及故障恢复机制；

具体地，所述改进两阶段提交包括：***在用户接口层面提供时态图读写接口，通过网络通信将操作发送到对应的存储节点，并且在存储节点底层调用时态图数据库存储模块接口执行操作，***采用改进两阶段提交的方式对时态图数据库分布式事务进行统一的提交或回滚，由客户端发起，在事务的第一阶段，发起事务的客户端先从master处获取开始版本号，随后将事务发送到各参与事务的存储节点，存储节点第一阶段完成一致性验证与写日志，当存储节点完成第一阶段后将操作结果同时返回给客户端与Coordinator，返回结果后，事务进入第二阶段，若所有存储节点都返回成功，则客户端返回事务成功，后续统一提交将由Coordinator统一指挥完成(提交时Coordinator先从master获取结束版本号，随后发送提交请求通知其他participant提交)。若有存储节点返回事务失败，则由Coordinator统一协调进行回滚；

所述并发控制机制包括多版本并发控制过程以及用于解决读写并发的内存MVCC机制；所述多版本并发控制过程进行并发控制时，数据库维护一个数据的多个版本，每一个版本的数据会附带许多额外的版本信息，保持版本链，同时每个事务携带一个版本号，通过事务之间版本号进行并发协商，随着版本号增大，小的版本号会逐渐退出并发控制，作为历史版本被保存，所述内存MVCC机制只在内存中维护多个版本对象数据，磁盘中仅维护最大版本数据，当***认为不需要该版本数据进行并发控制时内存即清理所述版本数据，所述内存中维护的数据的格式包括TGraph key信息、Start version、end version、Value字段，所述TGraph key信息包括存储节点的id和边的id，属性名称，Start version、end version字段分别为事务开始和结束时从中心节点获取的版本号，所述Value为属性值；所述内存MVCC机制分为写机制和读机制，所述写机制中，事务第一阶段开始时和第二阶段提交时各获取一次版本号作为事务起始版本号，数据在写入时进行判断，如果是最新版本数据，则将带版本号的数据写入内存，同时更新所述磁盘的数据，否则不需要更新所述磁盘，所述读机制中，如果数据只存在于所述磁盘，则读取所述磁盘数据，而如果内存中有多版本数据，则选择结束版本号小于当前事务操作版本号且开始版本号小于并最接近当前事务操作版本号的数据；

所述故障恢复机制采用中心日志的方式，由Coordinator集中存储整个事务的完整redo日志，当集群节点出现故障时，Coordinator协调指挥其进行恢复，通过Coordinator的中心日志保证故障时数据保持一致，所述redo日志包括：Transaction Id、Version、Status、Operation四个字段，所述Transaction Id为事务唯一标识ID、所述Version为事务对应的开始版本号、所述Status为事务当前的状态、所述Operation对应则是整个事务的操作集合，事务状态划分为first done、success与rollback，其中事务在第一阶段完成时写入日志，故在Coordinator写入日志时默认写入状态为first done，完成第一阶段的事务随后进入第二阶段，进行统一的回滚或者提交，若收到所有机器反馈的成功，则提交事务，完成提交的时候Coordinator再次更新日志状态为success，若事务在第二阶段完成了回滚，则将日志状态更新为rollback；所述master与集群维护有心跳，当机器短暂故障并重启时不会影响集群整体的运行，若故障超时未恢复，所述master将发出指令让所有机器停止运行，在宕机期间发起的与故障节点相关的事务全部失败，对于正运行的事务因为机器故障被打断，则会在机器重启后进行恢复，并通过redo日志解决***故障，进而对redo日志设置检查点，检查点对应事务版本号，事务每清理一次内存版本，则更新一次检查点，检查点之前的事务都是已完成的事务，***在重启时从检查点开始，依照版本号大小往后读取事务日志并恢复。

所述磁盘在存储时不包含start version与end version信息。

所述***认为不需要该版本数据进行并发控制的标志为：事务结束版本号加1低于master记录的正运行最小版本号或超时。

所述节点、边和静态属性的版本控制以节点、边为单位进行更新，时态属性进行版本控制的颗粒度小于所述节点、边和静态属性，所述静态属性为属性值极少发生变化的属性，所述时态属性为属性值频繁发生变化的属性。

所述redo日志解决***故障的方法为：若宕机机器承担Coordinator角色：重启后***检查日志，对于状态为first done的事务进行redo操作，重新执行事务进行恢复；或者若宕机机器承担participant的角色，并且机器在宕机后迅速重启，集群还未全部关闭，Coordinator发现检测不到目标机器将不断重试，直到机器恢复。重试时Coordinator读取redo日志，将操作重新发送给participant并执行，完成未完成的任务。

采用转换协调者的两阶段提交，事务在第一阶段协调者为客户端，第二阶段为Coordinator，转换协调者得两阶段提交将更适合于时态图数据的存储，因为时态图数据写入频繁，此改进能够减少客户端等待时间.

本发明所要实现的技术效果在于：

通过对两阶段流程的改进与内存MVCC的设计，提升了在分布式环境中对时态图数据操作的速度，并与现有其他支持事务的分布式数据库TiDB相比有更好的性能，在时态图数据的存储上可以很好的提高读写的并发性能，同时缩小事务执行的时间。

附图说明

图1现有技术中TiDB事务流程图；

图2事务的执行流程；

图3事务的执行流程中的获取版本号和回滚步骤；

图4清除内存版本号流程；

图5多版本数据读取实例；

图6 100个更新事务总时延；

图7 100个更新事务平均时延；

图8不同并发情况下读事务TPS对比；

图9不同并发情况下写事务TPS对比；

具体实施方式

以下是本发明的优选实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于此实施例。

当前单机时态图数据库***所有数据都在一个服务器存储，故所有操作都是按照单机进行设计。而在分布式***中，数据分散存储在多个节点，一个事务的操作可能需要多个服务器协同完成，这是单机时态图数据库事务所不能胜任的，因此本事务的设计目标之一是使时态图数据库事务支持分布式操作，支持事务跨存储节点。

在单机环境中时态图数据库使用两阶段锁的形式进行并发控制，维护事务的ACID特性。但是在分布式环境中，两阶段锁的申请与释放将会消耗大量的时延，事务持有锁的时间大大增加，使得并发性能降低。故在分布式环境中保证ACID特性已不能再使用单机时态图数据库两阶段锁的方案，需要重新设计新的并发控制方案来维护时态图数据库分布式事务的AICD特性。

基于此，本发明提出一种时态图数据库分布式事务解决***。

由于单机时态图数据库事务仅针对数据单机存放，所有操作都在单机进行，不需要考虑数据分片存储情形。而在分布式环境中一个事务通常跨多个存储节点，不同的操作可能需要到不同的存储节点去执行，涉及到路由，通信等问题，这些都是单机时态图数据库不需要考虑的，单机时态图数据库也没有提供相关的功能，因而考虑时态图数据库事务分布式扩展。

分布式事务常见的扩展形式包括两阶段提交、三阶段提交、基于补偿事务、消息队列等。虽然在实现方式与细节上有所不同，但都可以认为是两阶段提交的变体。两阶段提交将分布式事务划分为两个阶段：客户端第一阶段询问各参与节点是否可以完成任务，收到所有节点响应后进入第二阶段，再由客户端通知全局提交或回滚。

两阶段提交最大的问题在于两阶段的提交使得客户端的等待时间很长。但分析两阶段提交的特点可以发现：客户端在第一阶段即可确定事务的是否可以提交，第二阶段主要是进行提交/回滚，主要由服务器完成，客户端等待只是确保提交操作的完成，防止意外的发生。

因而，本发明设计了基于改进两阶段提交扩展TGraph分布式事务方法。

时态图数据库分布式事务在用户接口层面提供与时态图数据库单机事务相同的时态图读写接口，通过网络通信将操作发送到对应的存储节点，并且在存储节点底层调用相同的时态图数据库存储模块接口执行操作，进而完成整个事务的操作。

时态图数据库分布式事务将服务器节点分为了三类：

1)Master：中心节点，维持心跳，提供全局唯一版本号。

2)Coordinator：协调者，主要指第二阶段选取的存储节点来指挥其他存储节点进行统一提交。

3)Participant：参与事务操作中，除了Coordinator外的其他存储节点。

时态图数据库分布式事务采用改进两阶段提交的方式对事务进行统一的提交或回滚。事务流程如图2、3所示，由客户端发起，在事务的第一阶段，发起事务的客户端先从master处获取开始版本号，随后将事务发送到各参与事务的存储节点，存储节点第一阶段完成一致性验证与写日志。当存储节点完成第一阶段后将操作结果同时返回给客户端与Coordinator。返回结果后，事务进入第二阶段，若所有节点都返回成功，则客户端返回事务成功，后续统一提交将由Coordinator统一指挥完成(提交时Coordinator先从master获取结束版本号，随后发送提交请求通知其他participant提交)。若有节点返回事务失败，则由Coordinator统一协调进行回滚。时态图数据库分布式事务要保证一旦所有的节点返回成功，那么事务一定能提交成功，这需要后面介绍的故障处理进行保证。

通过对协调者的转换，客户端仅需要等待一个阶段，大大减少客户端网络通信的次数，降低客户端的等待时间。

同时设计时态图数据库在分布式环境中的并发控制机制。

并发控制主要是为了维护事务的执行顺序，保障读写的正确进行，常见的并发控制实现方式有基于锁实现、基于时间戳实现、基于有效性检查实现和多版本并发控制等。此处结合时态图数据的特点对时态图数据库在分布式环境中的并发控制设计，使其能在分布式环境中维护事务的ACID特性。

单机时态图数据库：

在单机时态图数据库***中，事务采用两阶段锁的方式进行并发控制，事务开始时需要获取所有操作数据的锁，获取完整后才能进一步执行操作，当事务执行完，再统一的释放锁。在单机环境中，两阶段锁能很好的发挥作用。但是在分布式环境中，事务若采用两阶段锁的方式，事务持有锁的时间将大大的增加，后续想要操作相同数据的事务等待的时间随之增大，最后导致***的并发性能急剧下降。故在分布式环境中，不宜使用两阶段锁，需要结合时态图数据库的特点，对单机时态图数据库的并发控制进行改进，使其能够在分布式环境中也能很好的发挥作用。

多版本并发控制(MVCC)：

多版本并发控制在当前数据库***中非常常见，如InnoDB、TiDB等都是采用的此方式进行并发控制。使用MVCC进行并发控制时，数据库会维护一个数据的多个版本，每一个版本的数据会附带许多额外的版本信息，保持版本链。写入数据时直接***新版本数据即可，读请求依据自己的版本号决定需要读哪一个版本的数据。

MVCC并发控制时每个事务携带一个版本号，通过事务之间版本号进行并发协商。但随着版本号增大，小的版本号会逐渐退出并发控制，仅仅作为历史版本的被保存。故对于存储的多版本信息而言，若没有特殊需求，则不用保留太久就可以清理。而时态图数据库所面向的时态图数据通常仅包含一个版本，并且在存储时也未考虑多版本数据，故若其采用多版本并发控制，则可以定期清理多版本数据。除此之外，时态图数据图结构变化少，时态图属性写入频繁，因此可以设计不同的版本粒度以降低开销，加快速度。

内存MVCC机制：

内存MVCC的设计结合时态图数据存储的特点和MVCC并发控制的特点，只在内存中维护多个版本对象数据，磁盘中仅维护最大版本数据。内存定期清理无用多版本数据。多版本数据仅用于并发控制，故当***认为不可能再需要该版本数据进行控制时即可清除。

内存中维护的每一条数据的格式如下：

TGraph key信息

Start version

End version

Value

其中TGraph key信息包括节点(边)id，属性名称等。Start version、end version分别为事务开始和结束时从中心节点获取的版本号。Value才是真正的属性值。数据在内存中以这种方式维护多版本，而将最大版本号的数据会同步更新到磁盘进行存储，磁盘存储时将不包含start version与end version等版本信息。

对于内存中维护的多版本数据而言，若不需要其进行并发控制，则可以清理。当出现以下情形时即可认为不再需要其进行并发控制：

事务结束版本号加1低于master记录的正运行最小版本号，表示此事务已在其他事务开始前完成，故此事务不会再与后续的事务发生冲突，也就不需要其再进行并发控制。

超时，随着事务之间起始时间差距的增加，事务之间发生冲突的概率也会随之降低，故可以认为超过一定时间后，便不会再出现与其冲突的事务。

例：如图4所示的例子，当前***正运行的事务为7、8，故正运行的最小版本号为7。内存中包含的数据信息(部分)如图1右边所示，事务结束版本号加1小于7的数据为红色的三条数据，故可以将其进行清理。

针对时态图数据图结构变化少、时态图属性写入频繁的特点，本发明对图结构、时态属性采用不同的版本粒度。对于节点、边、静态属性而言，极少发生更新，故版本控制以节点、边为单位进行更新。而时态属性写入频繁，若采用相同的粒度将会产生非常多版本数据，大大降低事务性能，故对于时态属性而言，选择更细的粒度进行版本控制更加合适。在本发明中，时态属性的版本粒度细化到了节点时态属性在某一时间的值。对于不同的对象使用不同粒度的版本控制可以提高操作速度同时尽可能避免内存开销过大。

读写机制：

当多个用户同时对某个数据进行操作时，数据的一致性就很容易被破坏，内存MVCC则主要是用于解决读写并发的问题。事务操作主要分为读写两种，读写操作应当写入和读取到正确版本的数据。

写机制：

事务第一阶段开始时和第二阶段提交时各获取一次版本号作为事务起始版本号。对于写操作而言，数据在写入时进行判断，如果是最新版本数据，则将带版本号的数据写入内存，同时更新磁盘的数据。如果不是最新版本数据，则不需要更新磁盘。写操作之间互不干扰，故不会出现不一致情况。

读机制：

数据同时存储在内存和磁盘，所以读取分为两种情况：内存中有对应多版本数据(即可能有事务冲突)、数据只存储在磁盘(无事务冲突)。对于这两种情况，如果数据只存在于磁盘，读取磁盘数据即可。而如果内存中有多版本数据，则选择结束版本号小于当前事务操作版本号且开始版本号小于并最接近当前事务操作版本号的数据。

例：有一个节点的属性X在某一时间点的属性值被修改了五次，也就是有五个版本，分别如图5所示，假设当前读事务版本号为7，读取图2-5的数据(已省略key等信息)，对该操作而言，可见的属性值有A B C，但C的开始版本号最接近7，因此选择C返回。D的版本号为6虽然小于7，但是结束版本号大于7，为避免不一致读，故暂时对7不可见。

故障恢复机制设计：

事务最重要的一个功能是要在任何时候都能够保障数据的一致性，而服务器故障是难以避免的一个问题，因此在机器出现意外的时候都能保障数据的一致性也成了事务需要完成的一个重要任务。

通常把数据库正常运行中可能会遇到的故障分为：***故障与事务故障。***故障主要是因为硬件错误或者***漏洞从而使得***中止和崩溃，而事务故障的话则是由于发生死锁、错误输入等情况使得事务无法正常的执行下去。不论是***故障还是事务故障都会使得数据库的一致性收到破环，这里主要讨论***故障，事务故障主要是通过事务回滚保证。

本分布式事务采用中心日志的方式，由Coordinator集中存储整个事务的完整redo日志，当集群节点出现故障时，Coordinator可以协调指挥其进行恢复，通过Coordinator的中心日志可以确保当遇到***故障，出现机器崩溃时数据依旧保持一致。

Redo日志格式：

Transaction Id

Version

Status

Operation

其中Transaction Id为事务唯一标识ID；Version为事务对应的开始版本号；Status为事务当前的状态；Operation对应则是整个事务的操作集合。

为了简化事务恢复过程，事务状态被精简成三种：first done、success与rollback。事务在第一阶段完成时写入日志，故在Coordinator写入日志时默认写入状态为first done。完成第一阶段的事务随后进入第二阶段，进行统一的回滚或者提交。若收到所有机器反馈的成功，则提交事务，完成提交的时候Coordinator再次更新日志状态为success，若事务在第二阶段完成了回滚，则将日志状态更新为rollback。

中心节点master与集群维护有心跳，当机器短暂故障并重启时不会影响集群整体的运行，若故障超时未恢复，中心节点master将发出指令让所有机器停止运行。在宕机期间发起的与故障节点相关的事务将全部失败。对于正运行的事务因为机器故障被打断，则会在机器重启后进行恢复。事务主要通过redo日志解决***故障，主要有两种情况：

1)若宕机机器承担Coordinator角色：重启后***检查日志，对于状态为firstdone的事务进行redo操作，重新执行事务进行恢复。

2)若宕机机器承担participant的角色，并且机器在宕机后迅速重启，集群还未全部关闭，Coordinator发现检测不到目标机器将不断重试，直到机器恢复。重试时Coordinator读取redo日志，将操作重新发送给participant并执行，完成未完成的任务。

对于redo日志设置检查点，检查点对应事务版本号，事务每清理一次内存版本，则更新一次检查点，检查点之前的事务都是已完成的事务，***在重启时从检查点开始，依照版本号大小往后读取事务日志并恢复。

***的测试效果：

通过对两阶段流程的改进与内存MVCC的设计，本设计大大提升了在分布式环境中对时态图数据操作的速度。本文与同样支持事务的分布式数据库TiDB对比，进行读写时态图的时态属性测试。

测试配置如下：

1)windows 10企业版台式机，处理器配置为Inter(R)Core(TM)i5-6500 3.20Ghz，8G内存，希捷1TB 7200转SATA硬盘。

2)CentOS Linux release 7.8.2003,处理器配置为Inter(R)Core(TM)i5-45703.20Ghz，8G内存，希捷1TB 7200转SATA硬盘。

3)CentOS Linux release 7.8.2003,处理器配置为Inter(R)Core(TM)i5-45903.30Ghz，8G内存，希捷1TB 7200转SATA硬盘。

4)CentOS Linux release 7.8.2003,处理器配置为Inter(R)Core(TM)i5-45903.30Ghz，8G内存，希捷1TB 7200转SATA硬盘。

5)CentOS Linux release 7.8.2003,处理器配置为Inter(R)Core(TM)i5-45703.20Ghz，8G内存，希捷1TB 7200转SATA硬盘。

其中机器1为客户端发送请求，机器2为中心节点提供版本与路由(TiDB与本时态图事务都需要中心节点)，机器3、4、5为存储节点。

图6为在不同并发情况下，100个事务(每个事务更新5000个节点的时态属性)更新时态属性的总时延，可以看到本文所采取的方案(DTG)所消耗的总时延稳定在16秒左右，而TiDB总时延在530秒左右。图7是在该情况下，单个事务的平均时延，可以看到TiDB单个事务的时延随并发的增加而增加，并时延较大(大于5000ms)，而本文采取的方案则一直保持在一个相对稳定的较低水平(180ms)。

图8、9是在不同并发情况下读写时态属性的TPS，可以看到，不论是读事务还是写事务，在我们的方案下，TPS都能随着并发的增加，读事务DTG与TiDB的TPS相差不大，TiDB稳定在380左右，而DTG的TPS从308逐渐升到了700。对于写事务而言TiDB比DTG低了一个数量级，TiDB写事务TPS稳定在个位数，而DTG写事务TPS从333升到了709。

通过上述对比可以看到，本事务方案在时态图数据的存储上可以很好的提高读写的并发性能，同时缩小事务执行的时间。

Claims (6)

1.一种时态图数据库分布式事务解决***，其特征在于：***设置客户端、Coordinator、master、participant，所述master为中心节点，用于维持心跳并提供全局唯一版本号，所述Coordinator为第二阶段选取的存储节点来指挥其他存储节点进行统一提交，所述participant为其他存储节点，通过设计改进两阶段提交对时态图数据库分布式事务进行扩展，并设计时态图数据库在分布式环境中的并发控制机制以及故障恢复机制；

具体地，所述改进两阶段提交包括：***在用户接口层面提供时态图读写接口，通过网络通信将操作发送到对应的存储节点，并且在存储节点底层调用时态图数据库存储模块接口执行操作，***采用改进两阶段提交的方式对时态图数据库分布式事务进行统一的提交或回滚，由客户端发起，在事务的第一阶段，发起事务的客户端先从master处获取开始版本号，随后将事务发送到各参与事务的存储节点，存储节点第一阶段完成一致性验证与写日志，当存储节点完成第一阶段后将操作结果同时返回给客户端与Coordinator，返回结果后，事务进入第二阶段，若所有存储节点都返回成功，则客户端返回事务成功，后续统一提交将由Coordinator统一指挥完成，提交时C oordinator先从master获取结束版本号，随后发送提交请求通知其他participant提交，若有存储节点返回事务失败，则由Coordinator统一协调进行回滚；

所述并发控制机制包括多版本并发控制过程以及用于解决读写并发的内存MVCC机制；所述多版本并发控制过程进行并发控制时，数据库维护一个数据的多个版本，每一个版本的数据会附带许多额外的版本信息，保持版本链，同时每个事务携带一个版本号，通过事务之间版本号进行并发协商，随着版本号增大，小的版本号会逐渐退出并发控制，作为历史版本被保存，所述内存MVCC机制只在内存中维护多个版本对象数据，磁盘中仅维护最大版本数据，当***认为不需要该版本数据进行并发控制时内存即清理所述版本数据，所述内存中维护的数据的格式包括TGraph key信息、Start version、end version、Value字段，所述TGraph key信息包括存储节点的id和边的id，以及属性名称，Start version、end version字段分别为事务开始和结束时从中心节点获取的版本号，所述Value为属性值；所述内存MVCC机制分为写机制和读机制，所述写机制中，事务第一阶段开始时和第二阶段提交时各获取一次版本号作为事务起始版本号，数据在写入时进行判断，如果是最新版本数据，则将带版本号的数据写入内存，同时更新所述磁盘的数据，否则不需要更新所述磁盘，所述读机制中，如果数据只存在于所述磁盘，则读取所述磁盘数据，而如果内存中有多版本数据，则选择结束版本号小于当前事务操作版本号且开始版本号小于并最接近当前事务操作版本号的数据；

所述故障恢复机制采用中心日志的方式，由Coordinator集中存储整个事务的完整redo日志，当集群节点出现故障时，Coordinator协调指挥其进行恢复，通过Coordinator的中心日志保证故障时数据保持一致，所述redo日志包括：TransactionId、Version、Status、Operation四个字段，所述TransactionId为事务唯一标识ID、所述Version为事务对应的开始版本号、所述Status为事务当前的状态、所述Operation对应则是整个事务的操作集合，事务状态划分为first done、success与rollback，其中事务在第一阶段完成时写入日志，故在Coordinator写入日志时默认写入状态为first done，完成第一阶段的事务随后进入第二阶段，进行统一的回滚或者提交，若收到所有机器反馈的成功，则提交事务，完成提交的时候Coordinator再次更新日志状态为success，若事务在第二阶段完成了回滚，则将日志状态更新为rollback；所述master与集群维护有心跳，当机器短暂故障并重启时不会影响集群整体的运行，若故障超时未恢复，所述master将发出指令让所有机器停止运行，在宕机期间发起的与故障节点相关的事务全部失败，对于正运行的事务因为机器故障被打断，则会在机器重启后进行恢复，并通过redo日志解决***故障，进而对redo日志设置检查点，检查点对应事务版本号，事务每清理一次内存版本，则更新一次检查点，检查点之前的事务都是已完成的事务，***在重启时从检查点开始，依照版本号大小往后读取事务日志并恢复。

2.如权利要求1所述的一种时态图数据库分布式事务解决***，其特征在于：所述磁盘在存储时不包含start version与end version信息。

3.如权利要求2所述的一种时态图数据库分布式事务解决***，其特征在于：所述***认为不需要该版本数据进行并发控制的标志为：事务结束版本号加1低于master记录的正运行最小版本号或超时。

4.如权利要求3所述的一种时态图数据库分布式事务解决***，其特征在于：所述节点、边和静态属性的版本控制以节点、边为单位进行更新，时态属性进行版本控制的颗粒度小于所述节点、边和静态属性，所述静态属性为属性值极少发生变化的属性，所述时态属性为属性值频繁发生变化的属性。

5.如权利要求4所述的一种时态图数据库分布式事务解决***，其特征在于：所述redo日志解决***故障的方法为：若宕机机器承担Coordinator角色：重启后***检查日志，对于状态为first done的事务进行redo操作，重新执行事务进行恢复；或者若宕机机器承担participant的角色，并且机器在宕机后迅速重启，集群还未全部关闭，Coordinator发现检测不到目标机器将不断重试，直到机器恢复，重试时Coordinator读取redo日志，将操作重新发送给participant并执行，完成未完成的任务。

6.如权利要求5所述的一种时态图数据库分布式事务解决***，其特征在于：采用转换协调者的两阶段提交，事务在第一阶段协调者为客户端，第二阶段为Coordinator。

Images