本申请涉及数据库
技术领域：
：，特别涉及一种事务处理方法、装置、计算机设备及存储介质。
背景技术：
：：随着数据库技术的发展，为了能够适应大数据、云计算等业务场景，分布式数据库系统逐渐变得普及。在分布式数据库系统中进行分布式事务处理时，可以采取去中心化的事务处理技术。去中心化的事务处理技术是指，在数据库系统中不存在某一节点设备集中对事务进行协调，而是在数据库系统中存在多个节点设备能够用于充当事务协调者的角色，由于涉及到多个协调节点设备共同处理分布式事务，因此需要保证分布式事务的正确性，通常是在多个协调节点设备之间进行通信，以同步全局事务信息，从而保证事务的全局正确性(也称为全局事务一致性)。然而在同步全局事务信息的过程中，需要依赖于一个全局逻辑时钟，容易造成数据库系统的单点瓶颈问题，导致数据库系统的可扩展性较差。技术实现要素：本申请实施例提供了一种事务处理方法、装置、计算机设备及存储介质，能够改善数据库系统的单点瓶颈问题，提升数据库系统的可扩展性。该技术方案如下：一方面，提供了一种事务处理方法，该方法包括：响应于目标事务的执行请求，获取所述目标事务的状态信息，所述状态信息用于表示所述目标事务当前所处的执行状态；校验基于所述状态信息确定的逻辑生命周期，所述逻辑生命周期用于表示所述目标事务在事务处理过程中的逻辑时间戳区间；响应于对所述逻辑生命周期校验通过，执行所述目标事务；响应于对所述目标事务的冲突验证通过，提交所述目标事务。在一种可能实施方式中，所述状态信息包括所述逻辑生命周期的时间戳下界和时间戳上界；所述校验基于所述状态信息确定的逻辑生命周期包括：响应于所述时间戳下界小于所述时间戳上界，确定对所述逻辑生命周期校验通过；响应于所述时间戳下界大于或等于所述时间戳上界，确定对所述逻辑生命周期校验不通过。在一种可能实施方式中，若所述目标事务涉及针对数据项的读取操作，所述执行所述目标事务包括：基于所述执行请求中的读取条件，确定所述读取条件所对应的至少一个数据项；从所述至少一个数据项中，确定相对于所述目标事务可见的目标数据项，将所述目标数据项存储到所述目标事务的读集中。在一种可能实施方式中，所述从所述至少一个数据项中，确定相对于所述目标事务可见的目标数据项包括：响应于当前数据库系统的一致性级别为严格可串行化，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的全局提交时间戳小于所述目标事务的全局开始时间戳，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述全局提交时间戳用于表示事务的全局提交时刻，所述全局开始时间戳用于表示事务的全局开始时刻。在一种可能实施方式中，所述从所述至少一个数据项中，确定相对于所述目标事务可见的目标数据项包括：响应于当前数据库系统的一致性级别为顺序可串行化、因果可串行化、因果可重复读或者因果读已提交中任一项，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的逻辑提交时间戳小于所述目标事务的逻辑生命周期的时间戳上界，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述逻辑提交时间戳用于表示事务的逻辑提交时刻，所述全局提交时间戳用于表示事务的全局提交时刻。在一种可能实施方式中，所述从所述至少一个数据项中，确定相对于所述目标事务可见的目标数据项包括：响应于当前数据库系统的一致性级别为因果快照隔离，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的逻辑提交时间戳小于所述目标事务当前所属会话的最大提交时间戳，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述全局提交时间戳用于表示事务的全局提交时刻，所述逻辑提交时间戳用于表示事务的逻辑提交时刻，所述目标事务当前所属会话的最大提交时间戳用于表示所述会话涉及读写操作的数据项中最大的逻辑提交时间戳。在一种可能实施方式中，所述确定相对于所述目标事务可见的目标数据项之后，所述方法还包括：基于所述目标数据项的逻辑提交时间戳，对所述目标事务的逻辑生命周期的时间戳下界进行调整，得到调整后的时间戳下界，所述调整后的时间戳下界大于所述目标数据项的逻辑提交时间戳。在一种可能实施方式中，所述基于所述目标数据项的逻辑提交时间戳，对所述目标事务的逻辑生命周期的时间戳下界进行调整，得到调整后的时间戳下界包括：响应于任一目标数据项的逻辑提交时间戳小于所述时间戳下界，将所述时间戳下界确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳等于所述时间戳下界，将所述目标数据项的最终提交时间戳加一所得的数值确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳大于所述时间戳下界，将所述目标数据项的最终提交时间戳确定为调整后的时间戳下界；其中，所述最终提交时间戳处于产生目标数据项的事务的逻辑生命周期中。在一种可能实施方式中，所述确定相对于所述目标事务可见的目标数据项之后，所述方法还包括：响应于所述目标数据项的待写事务不为空，将所述目标事务的逻辑生命周期的时间戳上界调整为所述时间戳上界与待写事务的时间戳下界中的最小值。在一种可能实施方式中，若所述目标事务涉及针对数据项的写入操作，所述执行所述目标事务包括：基于所述执行请求，生成待写入的数据项，将所述待写入的数据项存储到所述目标事务的写集中。在一种可能实施方式中，所述响应于对所述目标事务的冲突验证通过，提交所述目标事务之前，所述方法还包括：响应于所述目标事务的验证请求，更新所述目标事务的状态信息；或，响应于所述目标事务的验证请求，基于所述目标事务的写集，对所述目标事务的逻辑生命周期进行调整，得到目标生命周期，所述目标生命周期与所述写集中数据项的读事务不存在读写冲突。在一种可能实施方式中，所述基于所述目标事务的写集，对所述目标事务的逻辑生命周期进行调整，得到目标生命周期包括：获取所述写集中待写入的数据项的最大读事务时间戳，所述最大读事务时间戳用于表示读取过所述数据项的事务的逻辑提交时间戳中的最大值；确定各个待写入的数据项的最大读事务时间戳中的最大值；响应于所述逻辑生命周期的时间戳下界大于所述最大值，将所述逻辑生命周期的时间戳下界确定为所述目标生命周期的时间戳下界；响应于所述逻辑生命周期的时间戳下界等于所述最大值，将所述最大值加一所得的数值确定为所述目标生命周期的时间戳下界；响应于所述逻辑生命周期的时间戳下界小于所述最大值，将所述最大值确定为所述目标生命周期的时间戳下界。在一种可能实施方式中，所述基于所述目标事务的写集，对所述目标事务的逻辑生命周期进行调整，得到目标生命周期包括：获取所述写集中待写入的数据项所对应活跃事务列表中读事务的事务状态；对于事务状态为验证通过状态或提交完成状态的读事务，将所述读事务的时间戳上界以及所述逻辑生命周期的时间戳下界中的最大值确定为所述目标生命周期的时间戳下界；对于事务状态为正在运行状态的读事务，响应于所述读事务的时间戳下界等于所述逻辑生命周期的时间戳下界，将所述读事务的时间戳下界加一所得的数值确定为所述目标生命周期的时间戳下界；响应于所述读事务的时间戳下界大于所述逻辑生命周期的时间戳下界，将所述读事务的时间戳下界确定为所述目标生命周期的时间戳下界；将所述读事务的时间戳上界调整为所述读事务的时间戳上界与所述目标生命周期的时间戳下界中的最小值。在一种可能实施方式中，所述方法还包括：响应于所述目标事务涉及到读取任一数据项，获取所述数据项的活跃事务列表中读事务的事务状态；在所述数据项的活跃事务集合中删除事务状态为提交完成状态或回滚完成状态的读事务。在一种可能实施方式中，所述方法还包括：基于所述目标事务以及所述目标事务的写集中数据项所对应活跃事务列表中读事务的优先级或者回滚代价中至少一项，对所述目标事务的逻辑生命周期或者所述读事务的逻辑生命周期进行调整。在一种可能实施方式中，所述方法还包括：在对所述目标事务进行冲突验证的过程中，响应于所述目标事务所修改的数据项的字段与并发事务所修改的数据项的字段相同，确定所述目标事务与所述并发事务存在读写冲突；否则，确定所述目标事务与所述并发事务不存在读写冲突。一方面，提供了一种事务处理装置，该装置包括：获取模块，用于响应于目标事务的执行请求，获取所述目标事务的状态信息，所述状态信息用于表示所述目标事务当前所处的执行状态；校验模块，用于校验基于所述状态信息确定的逻辑生命周期，所述逻辑生命周期用于表示所述目标事务在事务处理过程中的逻辑时间戳区间；执行模块，用于响应于对所述逻辑生命周期校验通过，执行所述目标事务；提交模块，用于响应于对所述目标事务的冲突验证通过，提交所述目标事务。在一种可能实施方式中，所述状态信息包括所述逻辑生命周期的时间戳下界和时间戳上界；所述校验模块用于：响应于所述时间戳下界小于所述时间戳上界，确定对所述逻辑生命周期校验通过；响应于所述时间戳下界大于或等于所述时间戳上界，确定对所述逻辑生命周期校验不通过。在一种可能实施方式中，若所述目标事务涉及针对数据项的读取操作，所述执行模块包括：确定单元，用于基于所述执行请求中的读取条件，确定所述读取条件所对应的至少一个数据项；确定存储单元，用于从所述至少一个数据项中，确定相对于所述目标事务可见的目标数据项，将所述目标数据项存储到所述目标事务的读集中。在一种可能实施方式中，所述确定存储单元用于：响应于当前数据库系统的一致性级别为严格可串行化，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的全局提交时间戳小于所述目标事务的全局开始时间戳，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述全局提交时间戳用于表示事务的全局提交时刻，所述全局开始时间戳用于表示事务的全局开始时刻。在一种可能实施方式中，所述确定存储单元用于：响应于当前数据库系统的一致性级别为顺序可串行化、因果可串行化、因果可重复读或者因果读已提交中任一项，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的逻辑提交时间戳小于所述目标事务的逻辑生命周期的时间戳上界，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述逻辑提交时间戳用于表示事务的逻辑提交时刻，所述全局提交时间戳用于表示事务的全局提交时刻。在一种可能实施方式中，所述确定存储单元用于：响应于当前数据库系统的一致性级别为因果快照隔离，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的逻辑提交时间戳小于所述目标事务当前所属会话的最大提交时间戳，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，所述全局提交时间戳用于表示事务的全局提交时刻，所述逻辑提交时间戳用于表示事务的逻辑提交时刻，所述目标事务当前所属会话的最大提交时间戳用于表示所述会话涉及读写操作的数据项中最大的逻辑提交时间戳。在一种可能实施方式中，所述装置还包括：第一调整模块，用于基于所述目标数据项的逻辑提交时间戳，对所述目标事务的逻辑生命周期的时间戳下界进行调整，得到调整后的时间戳下界，所述调整后的时间戳下界大于所述目标数据项的逻辑提交时间戳。在一种可能实施方式中，所述第一调整模块用于：响应于任一目标数据项的逻辑提交时间戳小于所述时间戳下界，将所述时间戳下界确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳等于所述时间戳下界，将所述目标数据项的最终提交时间戳加一所得的数值确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳大于所述时间戳下界，将所述目标数据项的最终提交时间戳确定为调整后的时间戳下界；其中，所述最终提交时间戳处于产生目标数据项的事务的逻辑生命周期中。在一种可能实施方式中，所述装置还包括：第二调整模块，用于响应于所述目标数据项的待写事务不为空，将所述目标事务的逻辑生命周期的时间戳上界调整为所述时间戳上界与待写事务的时间戳下界中的最小值。在一种可能实施方式中，若所述目标事务涉及针对数据项的写入操作，所述执行模块用于：基于所述执行请求，生成待写入的数据项，将所述待写入的数据项存储到所述目标事务的写集中。在一种可能实施方式中，所述装置还包括：更新模块，用于响应于所述目标事务的验证请求，更新所述目标事务的状态信息；或，第三调整模块，用于响应于所述目标事务的验证请求，基于所述目标事务的写集，对所述目标事务的逻辑生命周期进行调整，得到目标生命周期，所述目标生命周期与所述写集中数据项的读事务不存在读写冲突。在一种可能实施方式中，所述第三调整模块用于：获取所述写集中待写入的数据项的最大读事务时间戳，所述最大读事务时间戳用于表示读取过所述数据项的事务的逻辑提交时间戳中的最大值；确定各个待写入的数据项的最大读事务时间戳中的最大值；响应于所述逻辑生命周期的时间戳下界大于所述最大值，将所述逻辑生命周期的时间戳下界确定为所述目标生命周期的时间戳下界；响应于所述逻辑生命周期的时间戳下界等于所述最大值，将所述最大值加一所得的数值确定为所述目标生命周期的时间戳下界；响应于所述逻辑生命周期的时间戳下界小于所述最大值，将所述最大值确定为所述目标生命周期的时间戳下界。在一种可能实施方式中，所述第三调整模块用于：获取所述写集中待写入的数据项所对应活跃事务列表中读事务的事务状态；对于事务状态为验证通过状态或提交完成状态的读事务，将所述读事务的时间戳上界以及所述逻辑生命周期的时间戳下界中的最大值确定为所述目标生命周期的时间戳下界；对于事务状态为正在运行状态的读事务，响应于所述读事务的时间戳下界等于所述逻辑生命周期的时间戳下界，将所述读事务的时间戳下界加一所得的数值确定为所述目标生命周期的时间戳下界；响应于所述读事务的时间戳下界大于所述逻辑生命周期的时间戳下界，将所述读事务的时间戳下界确定为所述目标生命周期的时间戳下界；将所述读事务的时间戳上界调整为所述读事务的时间戳上界与所述目标生命周期的时间戳下界中的最小值。在一种可能实施方式中，所述装置还包括：获取删除模块，用于响应于所述目标事务涉及到读取任一数据项，获取所述数据项的活跃事务列表中读事务的事务状态；在所述数据项的活跃事务集合中删除事务状态为提交完成状态或回滚完成状态的读事务。在一种可能实施方式中，所述装置还包括：第四调整模块，用于基于所述目标事务以及所述目标事务的写集中数据项所对应活跃事务列表中读事务的优先级或者回滚代价中至少一项，对所述目标事务的逻辑生命周期或者所述读事务的逻辑生命周期进行调整。在一种可能实施方式中，所述装置还包括：冲突验证模块，用于在对所述目标事务进行冲突验证的过程中，响应于所述目标事务所修改的数据项的字段与并发事务所修改的数据项的字段相同，确定所述目标事务与所述并发事务存在读写冲突；否则，确定所述目标事务与所述并发事务不存在读写冲突。一方面，提供了一种计算机设备，该计算机设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条程序代码，该至少一条程序代码由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法所执行的操作。一方面，提供了一种存储介质，该存储介质中存储有至少一条程序代码，该至少一条程序代码由处理器加载并执行以实现如上述任一种可能实现方式的事务处理方法所执行的操作。本申请实施例提供的技术方案带来的有益效果至少包括：通过响应于目标事务的执行请求，获取该目标事务的状态信息，校验基于该状态信息确定的逻辑生命周期，响应于对该逻辑生命周期校验通过，执行该目标事务，响应于对该目标事务的冲突验证通过，提交该目标事务，也即是说，在事务处理过程中并不依赖于某个全局逻辑时钟，而是依赖于针对逻辑生命周期的校验，逻辑生命周期在事务执行和验证过程中会依据冲突检测结果进行调整，通过对逻辑生命周期进行校验即可完成事务处理过程，也就改善了数据库系统的单点瓶颈问题，提升了数据库系统的可拓展性。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本申请实施例提供的一种事务处理方法的实施环境示意图；图2是本申请实施例提供的一种多级一致性关系的原理图；图3是本申请实施例提供的一种数据项结构的示意图；图4是本申请实施例提供的一种事务处理方法的交互流程图；图5是本申请实施例提供的一种事务处理方法的交互流程图；图6是本申请实施例提供的一种多级别一致性整体实现的原理图；图7是本申请实施例提供的一种事务处理装置的结构示意图；图8是本申请实施例提供的一种计算机设备的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。在介绍本申请实施例之前，需要引入一些云
技术领域：
：内的基本概念：云技术(cloudtechnology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成云
技术领域：
：的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，均能通过云计算来实现。云存储(cloudstorage)：是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。数据库(database)：简而言之可视为一种电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。数据的全态(fullstate)：对于数据库系统中的数据项，基于状态属性的不同，可以划分为三种状态：当前态、过渡态和历史态，该三种状态合称为“数据的全态”，简称全态数据，全态数据中的各个不同状态属性，可以用于标识数据在其生命周期轨迹中所处的状态。1、当前态(currentstate)：最新版本的数据项，是处于当前阶段的数据项。2、历史态(historicalstate)：数据项在历史上的一个状态，其值是旧值，不是当前值。多个历史态数据项可以对应于同一主键标识，反映了具有该主键标识的各个数据项的状态变迁的过程。处于历史态的数据项，只能被读取而不能被修改或删除。3、过渡态(transitionalstate)：不是当前态数据项也不是历史态数据项，处于从当前态向历史态转变的过程中，这种处于过渡态的数据也称为半衰数据。基于上述名词解释，不同的数据项可以具有相同的主键标识(primarykey，pk)，此时，具有相同主键标识的各个数据项可以构成一个全态数据集，该全态数据集内的各个数据项在本质上用于表示全态数据，也即是说，在对具有该主键标识的初始数据项进行多次修改(或删除)的过程中，由于修改(或删除)时刻不同而产生的多个不同的版本，即可构成一个全态数据集。在一个全态数据集中，有的数据项处于当前态，有的数据项处于过渡态，有的数据项处于历史态数据。这里的全态数据集是指一个抽象的、虚拟的集合概念，同一个全态数据集内的各个数据项可以分布式地存储在不同的物理机上。数据库系统在存储各个数据项时，可以采用指针将对应于同一主键标识的各个数据项按照时序链接起来，便于查询全态数据的生命周期轨迹。数据项的可见性：数据项的可见与否(数据项的可见性)是针对于事务而言的，某个数据项可能针对一些事务可见，针对一些事务不可见。在本申请实施例中，通过将数据库系统的事务隔离级别和分布式一致性级别进行统一，定义了统一的多级一致性，按照一致性级别的不同，分别采取不同的可见性判断算法来确定数据项的可见性，具体的多级一致性级别以及可见性判断算法将在后文进行详细说明，这里不做赘述。本申请实施例所涉及的数据库系统，可以是一种分布式的数据库系统，也可以是一种分布式的大数据处理系统，在分布式系统中可以包括至少一个节点设备，每个节点设备的数据库中可以存储有多个数据表，每个数据表可以用于存储一个或多个数据项(也称为元组)。其中，节点设备的数据库可以为任一类型的分布式数据库，可以包括关系型数据库或者非关系型数据库中至少一项，例如sql(structuredquerylanguage，结构化查询语言)数据库、nosql(non-relationalsql，泛指非关系型数据库)、newsql(泛指各种新式的可拓展/高性能数据库)等，在本申请实施例中对数据库的类型不作具体限定。从逻辑的角度出发，可以将分布式系统中节点设备划分为两种角色：协调节点设备(hostnode，也称为计算节点设备)和数据节点设备(resourcemanager，rm)，其中，协调节点设备主要负责生产、分发查询计划(也即分发事务的读取请求)，以及协调分布式事务，而数据节点设备则主要负责对数据进行分片存放，接收协调节点设备发来的查询计划，执行相应的事务并向协调节点设备返回事务涉及的数据项。在分布式数据库系统中，最小的操作执行单元为事务，依据事务是否需要对多个数据节点设备上的数据项进行操作，事务可以被划分为全局事务(又称分布式事务)和本地事务两种，针对这两种不同的事务，可以分别采取不同的执行流程，以尽量减少网络通信开销，提升事务处理效率。其中，全局事务表示事务需要跨多个数据节点设备执行读写操作，也即事务需要对多个数据节点设备上的数据项进行操作，例如，事务t需要操作数据节点设备rm1、rm2、rm3上的数据项，那么该事务t为一个全局事务；本地事务表示事务只需要对单个数据节点设备上的数据项进行操作，例如，事务t只需要操作rm1上的数据项，则该事务t为一个本地事务。在一些实施例中，本申请实施例还可以应用于一种基于区块链技术的数据库系统(以下简称为“区块链系统”)，上述区块链系统在本质上属于一种去中心化式的分布式数据库系统，采用共识算法保持区块链上不同节点设备所记载的账本数据一致，通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改，通过脚本系统来拓展账本功能，通过网络路由来进行不同节点设备之间的相互连接。在区块链系统中可以包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链系统中节点设备之间可以组成点对点(peertopeer，p2p)网络，p2p协议是一个运行在传输控制协议(transmissioncontrolprotocol，tcp)协议之上的应用层协议。在区块链系统中，任一节点设备可以具备如下功能：1)路由，节点设备具有的基本功能，用于支持节点设备之间的通信；2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成账本数据，在账本数据中携带数字签名以表示数据来源，将账本数据发送至区块链系统中的其他节点设备，供其他节点设备在验证账本数据来源以及完整性成功时，将账本数据添加至临时区块中，其中，应用实现的业务可以包括钱包、共享账本、智能合约等；3)区块链，包括一系列按照先后的时间顺序相互接续的区块，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点设备提交的账本数据。在一些实施例中，每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值，各区块通过哈希值连接形成区块链，另，区块中还可以包括有区块生成时的时间戳等信息，比如还可以包括本申请实施例提供的事务的状态信息。在分布式系统中，分布式事务处理是一项值得关注的焦点，可以划分为中心化的事务处理技术和去中心化的事务处理技术，下面进行介绍：中心化的事务处理技术：是指分布式数据库中存在某一节点设备为事务管理器，集中对事务进行并发控制，在该节点设备上维护全局事务状态、全局快照等信息，并对系统中所有事务进行统一管理。去中心化的事务处理技术：是指分布式数据库中不存在某一节点设备集中对事务进行协调，而是在分布式数据库中存在多个节点设备能够用于充当事务协调者的角色，由于涉及到多个协调节点设备共同处理分布式事务，因此需要重点保证分布式事务的正确性。目前的主流做法是在多个协调节点设备之间进行通信，并通过特定方法同步全局事务信息，从而保证事务的全局正确性(也称为全局事务一致性)。下面分别针对上述两种不同的分布式事务处理技术进行分析：对中心化的事务处理技术而言，由于事务并发访问控制本身的复杂性，需要耗费较多的系统资源，很容易称为分布式系统的性能瓶颈，而在中心化的事务处理技术中，使用了全局唯一的全局事务管理节点来对所有事务进行管理，那么很容易造成分布式系统中的单点瓶颈问题，使得分布式系统具备的可扩展能力较差，这里所涉及的可扩展性能较差是指：分布式系统的整体性能很容易因为单点的事务管理设计而无法随着机器数量的增加而线性增加，因此基于中心化的事务处理技术的分布式数据库产品，很难应用于大规模的交易场景中，对业务的局限性较大。对去中心化的事务处理技术而言，由于事务的并发控制普遍依赖于锁机制和时间戳排序机制，这两个机制在主流的互联网应用场景(指读操作较多且写操作较少)中会具有较差的性能，导致事务的吞吐量无法得到提升，进一步地，仍然需要多个协调节点设备之间进行相应的全局状态同步，比如需要依赖于一个全局逻辑时钟(这又称为了一个单点)，因此也很容易造成数据库系统的单点瓶颈问题，导致数据库系统的可扩展性较差，此外，如果不依赖于全局逻辑时钟，但为了确保事务一致性和分布式系统的一致性，那么整个分布式系统会存在较大的时延，因此基于去中心化的事务处理技术的分布式数据库产品的性能有待提升。有鉴于此，在本申请实施例中提供一种事务处理方法，是一种能够适用于分布式数据库系统的新型事务处理机制，首先，创新性的提出了分布式事务的多级一致性模型，以满足更多不同应用场景下对于系统一致性和系统效率的需求，将在下文进行详述，其次，提出了一套分布式事务处理解决方案，使得系统具备同时支持多级一致性的能力，并且还可以在不同的一致性级别之间进行切换，最后，提出了一系列的优化方法，能够提升分布式事务处理的吞吐量、减少回滚率。图1是本申请实施例提供的一种事务处理方法的实施环境示意图。参见图1，本实施例可以应用于分布式数据库系统，该系统中可以包括网关服务器101、全局时间戳生成集群102、分布式存储集群103以及分布式协调系统104(例如zookeeper)，在分布式存储集群103中可以包括数据节点设备和协调节点设备。其中，网关服务器101用于接收外部的读写请求，并将读写请求对应的读写事务分发至分布式存储集群103，比如，用户在登录终端上的应用客户端之后，触发应用客户端生成读写请求，调用分布式数据库系统提供的api(applicationprogramminginterface，应用程序编程接口)将该读写请求发送至网关服务器101，比如，该api可以是mysqlapi(一种关系型数据库系统提供的api)。在一些实施例中，该网关服务器101可以与分布式存储集群103中的任一个数据节点设备或任一协调节点设备合并在同一个物理机上，也即是，让某个数据节点设备或协调节点设备充当网关服务器101。全局时间戳生成集群102用于生成全局事务的全局提交时间戳(globaltimestamp，gts)，该全局事务可以是指涉及到多个数据节点设备的事务，例如全局读事务可以涉及到对多个数据节点设备上存储数据的读取，又例如，全局写事务可以涉及到对多个数据节点设备上的数据写入。全局时间戳生成集群102在逻辑上可以视为一个单点，但在一些实施例中可以通过一主三从的架构来提供具有更高可用性的服务，采用集群的形式来实现该全局提交时间戳的生成，可以防止单点故障，也就规避了单点瓶颈问题。可选地，全局提交时间戳是一个在分布式数据库系统中全局唯一且单调递增的时间戳标识，能够用于标志每个事务全局提交的顺序，以此来反映出事务之间在真实时间上的先后关系(事务的全序关系)，全局提交时间戳可以采用物理时钟、逻辑时钟或者混合物理时钟中至少一项，本申请实施例不对全局提交时间戳的类型进行具体限定。在一个示例性场景中，全局提交时间戳可以采用混合物理时钟的方式生成，全局提交时间戳可以由八字节组成，其中，前44位可以为物理时间戳的取值(也即unix时间戳，精确到毫秒)，这样共计可以表示244个无符号整数，因此理论上一共可以表示约为年的物理时间戳，其中，后20位可以为在某一毫秒内的单调递增计数，这样每毫秒有220个(约100万个)计数，基于上述数据结构，如果单机(任一数据节点设备)的事务吞吐量为10w/s，理论上可以支持包含1万个节点设备的分布式存储集群103，同时，全局提交时间戳的数量代表了系统理论上所能支持的总事务数，基于上述数据结构，理论上系统可以支持(244-1)*220个事务。这里仅仅是对一种全局提交时间戳的定义方法的示例性说明，根据业务需求的不同，可以对全局提交时间戳的位数进行扩展，以满足对更多的节点数、事务处理数的支持，本申请实施例不对全局提交时间戳的定义方法进行具体限定。在一些实施例中，该全局时间戳生成集群102可以是物理独立的，也可以和分布式协调系统104(例如zookeeper)合并到一起。其中，分布式存储集群103可以包括数据节点设备和协调节点设备，每个协调节点设备可以对应于至少一个数据节点设备，数据节点设备与协调节点设备的划分是针对不同事务而言的，以某一全局事务为例，全局事务的发起节点可以称为协调节点设备，全局事务所涉及的其他节点设备称为数据节点设备，数据节点设备或协调节点设备的数量可以是一个或多个，本申请实施例不对分布式存储集群103中数据节点设备或协调节点设备的数量进行具体限定。由于本实施例所提供的分布式数据库系统中缺乏全局事务管理器，因此在该系统中可以采用xa(extendedarchitecture，x/open组织分布式事务规范)/2pc(two-phasecommit，二阶段提交)技术来支持跨节点的事务(全局事务)，保证跨节点写操作时数据的原子性和一致性，此时，协调节点设备用于充当2pc算法中的协调者，而该协调节点设备所对应的各个数据节点设备用于充当2pc算法中的参与者。可选地，每个数据节点设备或协调节点设备可以是单机设备，也可以采用主备结构(也即是为一主多备集群)，如图1所示，以节点设备(数据节点设备或协调节点设备)为一主两备集群为例进行示意，每个节点设备中包括一个主机和两个备机，可选地，每个主机或备机都对应配置有代理(agent)设备，代理设备可以与主机或备机是物理独立的，当然，代理设备还可以作为主机或备机上的一个代理模块，以节点设备1为例，节点设备1包括一个主数据库及代理设备(主database+agent，简称主db+agent)，此外还包括两备数据库及代理设备(备database+agent，简称备db+agent)。在一个示例性场景中，每个节点设备所对应的主机或备机的数据库实例集合称为一个set(集合)，例如，假设某一节点设备为单机设备，那么该节点设备的set仅为该单机设备的数据库实例，假设某一节点设备为一主两备集群，那么该节点设备的set为主机数据库实例以及两个备机数据库实例的集合，此时可以基于云数据库的强同步技术来保证主机的数据与备机的副本数据之间的一致性，可选地，每个set可以进行线性扩容，以应付大数据场景下的业务处理需求，在一些金融业务场景下，全局事务通常是指跨set的转账。分布式协调系统104可以用于对网关服务器101、全局时间戳生成集群102或者分布式存储集群103中至少一项进行管理，可选地，技术人员可以通过终端上的调度器(scheduler)访问该分布式协调系统104，从而基于前端的调度器来控制后端的分布式协调系统104，实现对各个集群或服务器的管理。例如，技术人员可以通过调度器来控制zookeeper将某一个节点设备从分布式存储集群103中删除，也即是使得某一个节点设备失效。上述图1仅是提供了一种轻量级的全局事务处理的架构图，是一种类分布式数据库系统。整个分布式数据库系统可以看作是共同维护一个逻辑上的大表，这个大表中存储的数据通过主键被打散到分布式存储集群103中的各个节点设备中，每个节点设备上存储的数据是独立于其他节点设备的，从而实现了节点设备对逻辑大表的水平切分。由于在上述系统中能够将各个数据库中各个数据表水平切分后进行分布式地存储，因此，这种系统也可以形象地称为具有“分库分表”的架构。在上述分布式数据库系统中，已经基于xa/2pc算法实现了写操作时数据的原子性和一致性，而读操作的数据一致性问题，需要通过构造一个轻量的、去中心化的分布式事务处理机制来改善，从技术的角度来看，分布分表架构缺乏一个全局事务管理器，也就缺乏分布式事务处理能力，通过构造上述轻量的、去中心化的分布式事务处理机制，能够为分布式数据库系统提供水平扩展等能力，并且保证分布式数据库系统简单易推广、事务处理效率更高，必将对传统并发控制方式所设计的分布式数据库架构产生极大冲击，具体的分布式事务处理机制将在下个实施例中进行详述。在一些实施例中，上述网关服务器101、全局时间戳生成集群102、分布式存储集群103以及分布式协调系统104所构成的分布式数据库系统，可以视为一种向用户终端提供数据服务的服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。可选地，上述用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。在介绍本申请实施例之前，由于事务并发控制的正确程度可以通过一致性和隔离性来描述，下面对一致性和隔离性进行解释说明：一、隔离性事务隔离级别通过能否规避某种数据异常而进行定义，可能涉及到的数据异常包括：1)脏读，指一个事务读取到了另一事务尚未提交的数据项；2)不可重复读，指一个事务对同一数据项重复读取两次却得到了不同的结果；3)幻读，指事务在操作过程中进行两次范围查询，第二次查询的结果包含了第一次查询的结果中未出现的数据项或者缺少了第一次查询的结果中出现的数据项。基于能够解决上述三种数据异常，标准sql中定义了四种隔离级别，分别包括：1)读未提交：允许如上三种数据异常发生；2)读已提交：不允许脏读发生；3)可重复读：不允许脏读、不可重复读发生；4)可串行化：如上三种数据异常均不能发生。另外，还需要注意的一种数据异常称为丢失更新异常，是指两个并发事务同时进行更新，而后一个事务的更新覆盖了前一个事务的更新的情况，丢失更新异常是由于数据没有保证一致性而导致的。比如，存在数据项r1，r1中记录了属性值x＝100，t时刻下事务w1和w2同时对数据项r1进行更新，事务w1首先将x＝100修改为x＝120之后提交，随后事务w2又将x＝100修改为x＝130之后提交，导致在查询事务w1时，会发现刚才修改的内容没有被修改掉，就好像是“丢失了更新”，因此这种数据异常称为丢失更新异常，丢失更新异常在可重复读和可串行化的一致性级别下均不允许发生。二、一致性在分布式系统中，一致性用来描述事件之间的操作顺序是否符合某种约束，主要可以划分为：1)线性一致性，保证当前操作序列与一个保留了全部原有符合真实时间的先后关系＜h的顺序等效，即要求所有操作之间存在全序关系，并且需要保留全部的真实时间先后顺序，其中，先后关系＜h是指，假设存在操作a和操作b，如果操作a的结束时刻处于操作b的开始时刻之前，那么操作a和操作b之间的全序关系可以记为“a＜hb”。2)顺序一致性，保证当前操作序列的执行结果与某一顺序序列等价，即要求所有操作之间存在全序关系，而不用保留符合真实时间的先后关系＜h。3)因果一致性，保证当前历史中有因果关系的操作顺序被保留，即不需要全序关系，只需要关注偏序关系。因果关系主要可以被归纳为两个：同一进程内的事件之间存在因果关系；不同进程间，分别属于两个进程的读写操作同一个对象，这两个操作之间存在因果关系。基于上述解释说明，如果仅考虑事务隔离级别，则无法体现出分布式一致性的要求，如果仅考虑分布式一致性级别，则无法对事务中包含的多个操作进行约束，因此，在本申请实施例中将事务隔离级别和分布式一致性级别进行了统一，并定义了如下的统一的多级一致性：1、严格可串行化(strictserializability，sss)：并发事务之间保证可串行化，并且非并发事务之间如果存在符合真实时间的先后关系＜h，在等价的事务顺序执行序列中，＜h被保留，是多级一致性中的最高级别。2、顺序可串行化(sequentialserializability，ss)：并发事务之间保证可串行化，并且非并发事务之间存在全序关系，即与事务执行结果与某一确定的顺序执行序列等价。3、因果可串行化(casualserializability，cs)：并发事务之间保证可串行化，并且非并发事务之间保证因果偏序关系。4、因果快照隔离(casualsnapshotisolation，csi)：并发事务之间保证快照隔离，并且非并发事务之间保证因果偏序关系。5、因果可重复读(casualrepeatableread，crr)：并发事务之间保证可重复读，并且非并发事务之间保证因果偏序关系。6、因果读已提交(casualreadcommitted，crc)：并发事务之间保证读已提交，并且非并发事务之间保证因果偏序关系。图2是本申请实施例提供的一种多级一致性关系的原理图，请参考图2，并发事务之间保证读已提交且非并发事务之间保证因果偏序关系，那么其一致性级别为因果读已提交201，在因果读已提交201的基础上进一步保证并发事务之间可重复读，那么其一致性级别为因果可重复读202，在因果可重复读202的基础上进一步地保证并发之间快照隔离，那么其一致性级别为因果快照隔离203，在因果快照隔离203的基础上进一步保证并发之间可串行化，那么其一致性级别为因果可串行化204，在因果可串行化204的基础上进一步地保证非并发事务之间的逻辑全序，那么其一致性级别为顺序可串行化205，在顺序可串行化205的基础上进一步地保证非并发事务之间的真实事件全序，那么其一致性级别为严格可串行化206。上述分布式事务的多级一致性模型，为分布式事务处理的正确性提供了衡量标准，从而能够方便分布式事务在正确性和性能之间做出权衡，通过采用不同级别的一致性(隔离级别)，保证系统可以适用于对正确性和性能要求不同的业务负载。在提供了多级一致性模型的基础上，在此对本申请实施例所涉及的基本数据结构进行解释说明：一、数据项结构本申请实施例所涉及的数据项结构(也称为数据版本结构)可以适用于段页式存储的数据库系统或者键值式(key-value)存储的数据库系统中至少一项，由于段页式存储的数据结构可以基于键值式存储的数据结构获取，因此，在本申请实施例中以键值式存储的数据结构为例进行说明，数据项结构可以如图3所示，对任一数据项300(也称为元组、数据版本)来说，数据项的键301(key)可以为<user_key，wts，gts>，数据项的值302(value或者data)可以为其余属性值。其中，user_key是由用户定义的主键，在数据库系统中默认用户需要为数据表定义主键。其中，wts是指产生该数据项的事务的逻辑提交时间戳，也即是写入该数据版本的事务的逻辑提交时间戳，在事务提交之后赋值，这里涉及的逻辑提交时间戳用于表示事务的逻辑提交时刻。其中，gts是指产生该数据项的事务的全局提交时间戳，也即是写入该数据版本的事务的全局提交时间戳，在事务提交之后赋值，这里涉及的全局提交时间戳用于表示事务的全局提交时刻，可以由上述实施环境中的全局时间戳生成集群来进行分发。二、数据项页眉结构一个数据项集合(也即全态数据集)可以由多个数据版本和一个数据项页眉结构(header)构成，简而言之，针对具有相同主键标识(user_key)的各个数据项而言，可以维护同一个页眉结构，页眉结构中至少可以存储下述数值：1)user_key，用户定义主键，与各个数据版本的键中存储的user_key相同。2)rts，记录读取过该数据项的所有事务的逻辑提交时间戳中的最大值，也可以称为最大读事务时间戳。3)wt，表示该数据项所对应的待写事务，wt中可以记录要写入该数据项的事务的事务标识(tid)。4)rtlist，记录访问过该数据项集合中最新数据版本的活跃事务集合，也可以称为读事务列表，该活跃事务集合可以是数组的形式，也可以是列表、队列、堆栈等形式，本申请实施例不对活跃事务集合的形式进行具体限定，rtlist中每个元素可以是读取过上述最新数据版本的事务的事务标识(tid)。三、事务读集结构任一个事务的读集结构中记录了该事务所涉及读取的数据项，可以使用内存链表结构来维护事务的读集。需要说明的是，对一个全局读事务而言，其读集可以划分为本地读集和全局读集，本地读集存在于数据节点设备rm上，而全局读集存在于协调节点设备上，当然，协调节点设备可以定期将全局读集同步至各个数据节点设备上，使得数据节点设备上也能够维护事务的全局读集。在基于内存链表结构维护事务读集的基础上，每个链表节点可以对应于一个读取到的数据版本的key值，key值可以包括下述两个属性：1)size，取4字节，用于表示key所占字节数；2)key，在size之后的一个可以变长的字段，记录了读取到的数据版本的key值。四、事务写集结构任一个事务的写集结构中记录了该事务需要更新的数据项，与读集结构类似，同样可以使用内存链表结构来维护事务的写集。需要说明的是，对一个全局写事务而言，其写集可以划分为本地写集和全局写集，本地写集存在于数据节点设备rm上，而全局写集存在于协调节点设备上，当然，协调节点设备可以定期将全局写集同步至各个数据节点设备上，使得数据节点设备上也能够维护事务的全局写集。在基于内存链表结构维护事务写集的基础上，每个链表节点可以对应于一个写集中的数据项，所记录的数据项可以包括下述两个属性：1)size，取4字节，用于表示数据项的大小，也即表示version属性所占字节数；2)version，在size之后的一个可以变长的字段，用于表示数据项的key-value键值，记录了需要插入/更新的数据项(数据版本)。五、事务的状态信息对于任一个事务t，该事务的状态信息可以表示为一个{tid，lowts，uppts，sts，gts，status}形式的五元组，该五元组也可以称为事务t的全局事务状态，该状态信息可以同时存在于数据节点设备和协调节点设备上。其中，tid为事务标识，是一个全局唯一事务编号。在一个示例性场景中，tid可以由8字节组成，前14位用来记录处理该事务的协调节点设备的编号。14位共可以表示16384(214)个无符号整数，因此，可以和估算得到的全局提交时间戳gts所能支持的节点数相对应。后50位由该协调节点设备内的单调递增计数填充，上述单调递增计数用于区分协调节点设备中的不同事务(共250个)，该tid的数量级理论上可保证tid在全局提交时间戳gts所规定的总事务数范围内不会重复。其中，基于lowts和uppts可以确定事务的逻辑生命周期，将lowts确定为逻辑生命周期的时间戳下界，将uppts确定为逻辑生命周期的时间戳上界，那么该事务的逻辑生命周期可以表示为：[lowts，uppts)，对任一个事务而言，其初始生命周期可以为[0，+∞)，事务t的最终提交时间戳t.cts是从区间[lowts，uppts)中获得的，也即是说，事务t的最终提交时间戳处于事务t的逻辑生命周期中。事务的逻辑生命周期是相对的，在事务执行和验证过程中通常会对其生命周期进行调整，具体调整规则将在下述实施例中进行详述，这里不做赘述。其中，sts为事务的全局开始时间戳，该全局开始时间戳用于表示事务的全局开始时刻，在事务开始时可以从上述实施环境中的全局时间戳生成集群中获取当前的全局时间戳作为全局开始时间戳。其中，gts为事务的全局提交时间戳，该全局提交时间戳用于表示事务的全局提交时刻，在事务提交时可以从上述实施环境中的全局时间戳生成集群中获取当前的全局时间戳作为全局提交时间戳。其中，status用于描述事务状态，例如采用1字节大小，任一事务可以具有如下7种状态：正在运行状态(running)、正在验证状态(validating)、验证通过状态(validated)、正在提交状态(commiting)、提交完成状态(committed)、正在回滚状态(aborting)和回滚完成状态(aborted)。在提出上述多级一致性模型以及基本数据结构的基础上，本申请实施例提供一套分布式事务处理解决方案，使得分布式数据库系统可以具备同时支持多级一致性的能力，并且保证系统可以在不同一致性级别之间进行切换，下面对事务的整体执行流程(也即事务执行整体算法)进行详述。图4是本申请实施例提供的一种事务处理方法的交互流程图，参见图4，该实施例包括：401、协调节点设备与终端建立会话，该会话用于处理目标事务。终端可以是用户所对应的任一电子设备，包括但不限于：智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱或者智能手表中至少一项，本申请实施例不对终端的类型进行具体限定。可选地，在终端上可以安装有应用客户端，该应用客户端可以是能够提供数据服务的任一客户端，例如，该应用客户端可以是支付应用客户端、外卖应用客户端、打车应用客户端或者社交应用客户端中至少一项，本申请实施例不对应用客户端的类型进行具体限定。其中，目标事务可以是全局事务，也可以是局部事务，本申请实施例以目标事务为全局事务为例进行说明。在本申请实施例中，仅以协调节点设备(coordinator)为目标事务的发起节点、数据节点设备(participants，或cohort)为目标事务所涉及的参与节点为例进行说明，可选地，除了目标事务的发起节点之外，协调节点设备也可以是上述实施环境中的网关服务器，还可以是分布式存储集群中的任一个节点设备，该数据节点设备可以是目标事务所涉及读写操作的数据项所在的节点设备，还可以是分布式存储集群中的所有节点设备，本申请实施例不对协调节点设备与数据节点设备的数量和类型进行具体限定。需要说明的是，当协调节点设备为目标事务的发起节点时，由于不同的目标事务通常具有不同的发起节点，因此对不同的目标事务而言协调节点设备或者数据节点设备并非是固定不变的，也即是说，同一节点设备有可能对一些目标事务而言属于协调节点设备，对另一些目标事务而言属于数据节点设备。在一些实施例中，在会话(session)建立阶段，终端上的应用客户端可以通过下述方式与数据库系统中某一协调节点设备建立会话：应用客户端发出目标事务t的执行请求，元信息系统(比如上述实施环境中的网关服务器)检查当前客户端是否已经与某一协调节点设备建立会话，如果已建立会话，则复用当前已建立的会话；否则，系统随机选择某一协调节点设备与该应用客户端建立会话关系，该应用客户端之后发出的所有请求均由该协调节点设备负责执行。在一些实施例中，会话中可以缓存本会话读写操作过的数据项中最大的逻辑提交时间戳(wts)，记为session.lts，在会话首次建立时，将session.lts初始化为0。其中，session.lts也即是本会话的最大提交时间戳，用于表示该会话涉及读写操作的数据项中最大的逻辑提交时间戳。402、协调节点设备对目标事务进行初始化。在上述事务初始化阶段，协调节点设备可以执行下述三项初始化操作中的至少一项：1)协调节点设备为目标事务分配事务标识tid，也即是说，协调节点设备为事务分配全局唯一的事务编号。2)协调节点设备记录目标事务的状态信息，其中，由于状态信息可以表示为{tid，lowts，uppts，sts，gts，status}五元组，tid是由上述初始化操作1)中进行分配的，lowts可以初始化为本会话的最大提交时间戳session.lts，uppts可以初始化为+∞，也即是说，将目标事务的逻辑生命周期初始化为[session.lts，+∞)，status可以初始化为正在运行状态running。需要说明的是，如果当前数据库系统所设置的一致性级别为严格可串行化(sss)级别，那么协调节点设备需要与全局时间戳生成集群进行通信，获取当前的全局时间戳作为目标事务的全局开始时间戳，并将其赋值给sts，否则，如果当前的一致性级别并非是sss级别，那么将sts置为空即可，无需获取目标事务的全局开始时间戳。由于目标事务尚未提交，而gts是在事务提交之后赋值的，因此可以在初始化过程中可以将gts置为空。403、协调节点设备向数据节点设备发送目标事务的执行请求。在上述过程中，协调节点设备可以基于应用客户端发起的请求，优化sql并生成目标事务的物理执行计划，将执行计划进行分解，分别发送给目标事务所涉及的数据节点设备，数据节点设备的数量可以为一个或多个，在本申请实施例中不对数据节点设备的数量进行具体限定。404、数据节点设备响应于该执行请求，执行目标事务，向协调节点设备返回目标事务的执行结果。在上述过程中，数据节点设备根据协调节点设备的执行计划来进行实际的数据读写操作，并将执行结果返回给协调节点设备，具体数据节点设备如何执行目标事务以及在执行之前对逻辑生命周期的验证操作将在下个实施例中进行详述，此处不做赘述。405、协调节点设备汇总数据节点设备返回的执行结果，将汇总后的执行结果返回至终端。在上述过程中，由于数据节点设备可以会有一个或多个，因此协调节点设备需要对执行结果进行汇总，汇总完毕后返回至客户端。比如，客户端请求读取10个数据项，这10个数据项中有5个数据项存储在数据节点设备rm1上，其余的5个数据项存储在数据节点设备rm2上，rm1和rm2各自将5个数据项返回给协调节点设备，协调节点设备对数据项进行汇总得到10个数据项，并将这10个数据项返回至客户端。上述步骤403-405可以视为目标事务的事务执行阶段，在事务执行阶段结束后，可以进入下述步骤406中的事务验证阶段。406、协调节点设备向数据节点设备发送目标事务的验证请求。在一些实施例中，若目标事务为全局事务，由于全局事务涉及到跨节点的读写操作，协调节点设备需要向所有相关的数据节点设备发送验证请求。在一些实施例中，若目标事务为本地事务，由于本地事务仅涉及到单个数据节点设备的读写操作，因此协调节点设备仅需要向单个数据节点设备发送验证请求。407、数据节点设备响应于该验证请求，对目标事务进行冲突验证，向协调节点设备返回验证结果。在一些实施例中，若目标事务为全局事务，任一数据节点设备响应于验证请求，对目标事务进行冲突验证，若验证通过，数据节点设备向协调节点设备返回验证通过信息，否则，若验证失败，数据节点设备向协调节点设备返回验证失败信息，上述验证通过信息和验证失败信息统称为验证结果。在一些实施例中，若目标事务为本地事务，单个数据节点设备响应于验证请求，对目标事务进行冲突验证，若验证通过，由于不涉及到对其他的数据节点设备的验证结果进行汇总，因此直接进入目标事务的提交阶段，否则，若验证失败，向协调节点设备发送验证失败信息，上述验证通过信息和验证失败信息统称为验证结果。408、协调节点设备汇总数据节点设备的验证结果，确定目标事务的全局验证结果。在上述过程中，若目标事务是全局事务，协调节点设备汇总各个数据节点设备上报的验证结果之后，若各个验证结果均为验证通过信息，那么将全局验证结果确定为“验证通过”，否则，只要存在任一个验证结果为验证失败信息，那么将全局验证结果确定为“验证不通过”。409、协调节点设备响应于全局验证结果为验证通过，向数据节点设备发送目标事务的提交指令。在上述过程中，若目标事务是全局事务，响应于全局验证结果为验证通过，协调节点设备可以与全局时间戳生成集群进行通信，获取当前时刻的全局时间戳作为目标事务的全局提交时间戳gts，向所有相关的数据节点设备发送提交指令，由各个数据节点设备执行本地的提交操作。在一些实施例中，若目标事务是本地事务，由于直接由单个数据节点设备提交目标事务，因此无需执行上述步骤407-409中与协调节点设备的一轮通信，而是在单个数据节点设备对目标事务验证通过之后，直接由该数据节点设备与全局时间戳生成集群进行通信，获取当前时刻的全局时间戳作为目标事务的全局提交时间戳gts，再由该数据节点设备执行本地的提交操作。410、数据节点设备响应于该提交指令，提交目标事务。在上述过程中，数据节点设备需要将目标事务的本地写集中的数据落盘，还涉及到一系列基于多级一致性模型的处理操作，将在后文实施例中进行详述，这里不做展开说明。在上述步骤409-410中，提供了对目标事务全局验证通过时的事务提交流程，而在一些实施例中，协调节点设备响应于全局验证结果为验证失败，可以向数据节点设备发送目标事务的回滚指令，数据节点设备响应于该回滚指令，回滚目标事务，也即是在本地进行目标事务的回滚操作。本申请实施例中介绍了分布式数据库系统中事务的整体执行流程，分别按照目标事务为全局事务和本地事务进行了说明，整体执行流程可以划分为五个阶段，分别是步骤401中的会话建立阶段，步骤402中的事务初始化阶段，步骤403-405中的事务执行阶段，步骤406-408中的事务验证阶段，以及步骤409-410中的事务提交阶段。在各个不同的事务处理阶段中，通过不同系统模块的组合，可以在分布式数据库系统中实现不同的一致性级别，从而达到多级别一致性整体实现的技术方案，在后续实施例中，将对数据节点设备上的事务执行流程以及事务验证流程分别进行详细说明。图5是本申请实施例提供的一种事务处理方法的交互流程图，参见图5，本申请实施例中针对上述实施例中事务执行阶段的步骤404中如何执行目标事务来进行展开说明，此外，还针对上述实施例中事务验证阶段的步骤407中如何验证目标事务来进行展开说明，该实施例包括：501、数据节点设备响应于目标事务的执行请求，获取该目标事务的状态信息，该状态信息用于表示该目标事务当前所处的执行状态。在一些实施例中，该状态信息可以表示为一个{tid，lowts，uppts，sts，gts，status}形式的五元组。tid为事务标识，是一个全局唯一事务编号；lowts为目标事务的逻辑生命周期的时间戳下界；uppts为目标事务的逻辑生命周期的时间戳上界；sts为事务的全局开始时间戳，该全局开始时间戳用于表示事务的全局开始时刻；gts为事务的全局提交时间戳，该全局提交时间戳用于表示事务的全局提交时刻；status用于描述事务状态，任一事务可以具有如下7种状态：正在运行状态(running)、正在验证状态(validating)、验证通过状态(validated)、正在提交状态(commiting)、提交完成状态(committed)、正在回滚状态(aborting)和回滚完成状态(aborted)。上述执行请求中可以携带目标事务的状态参数，例如该状态参数包括上述tid、lowts、uppts、sts或者status＝running中至少一项。在一些实施例中，数据节点设备在接收到协调节点设备发送的目标事务的执行请求(req)之后，根据目标事务的事务标识，查询在本地数据库中是否存储目标事务的状态信息，若查询不到目标事务的状态信息，可以初始化该目标事务的状态信息，将该初始化的状态信息赋值为执行请求(req)所携带的状态参数；反之，若查询到了目标事务的状态信息，说明当前的目标事务已访问过本数据节点设备，那么可以更新当前的数据节点设备上目标事务的事务状态信息，具体地更新方法可以为：将目标事务的逻辑生命周期的时间戳下界t.lowts更新为查询到的时间戳下界t.lowts与执行请求中所携带状态参数中的时间戳下界req.lowts中的最大值，也即是说，令t.lowts＝max(t.lowts，req.lowts)，此外还将目标事务的逻辑生命周期的时间戳上界t.uppts更新为查询到的时间戳上界t.uppts与执行请求中所携带状态参数中的时间戳上界t.uppts中的最小值，也即是说，令t.uppts＝min(t.uppts，req.uppts)。可选地，数据节点设备可以在缓存中开辟一段空间来存储各个活跃事务的状态信息，在接收到目标事务的执行请求(req)之后，解析执行请求，得到目标事务的状态参数，该状态参数包括tid、lowts、uppts、sts或者status＝running中至少一项，数据节点设备可以以目标事务的事务标识tid为索引，在缓存中查询目标事务的状态信息，若该索引未能命中任一索引内容，说明查询不到目标事务的状态信息，此时将执行请求中的状态参数赋值为目标事务的状态信息，否则，若该索引能够命中任一索引内容，那么需要比较查询到的状态信息中的t.lowts与执行请求所携带的状态参数中的req.lowts，将两者中的最大值更新为最终的t.lowts，此外，比较查询到的状态信息中的t.uppts与执行请求所携带的状态参数中的req.uppts，将两者中的最小值更新为最终的t.uppts。502、数据节点设备校验基于该状态信息确定的逻辑生命周期，该逻辑生命周期用于表示该目标事务在事务处理过程中的逻辑时间戳区间。在上述过程中，由于该状态信息包括该逻辑生命周期的时间戳下界t.lowts和时间戳上界t.uppts，那么通过检测t.lowts是否小于t.uppts，从而判断出对逻辑生命周期是否校验通过，这一过程也可以称为针对逻辑时间戳区间的合法性检测过程。在一些实施例中，响应于该时间戳下界t.lowts小于该时间戳上界t.uppts，确定对该逻辑生命周期校验通过，执行下述步骤503；否则，响应于该时间戳下界t.lowts大于或等于该时间戳上界t.uppts，确定对该逻辑生命周期校验不通过，此时可以将本地状态信息中的事务状态status更新为正在回滚状态aborting，也即令t.status＝aborting。503、数据节点设备响应于对该逻辑生命周期校验通过，执行该目标事务。按照目标事务所涉及的读写操作的类型不同，其执行流程也不尽相同，以下将分别针对读操作和写操作进行分类讨论。一、写操作的执行流程若该目标事务涉及针对数据项的写入操作，数据节点设备可以基于该执行请求，生成待写入的数据项，将该待写入的数据项存储到该目标事务的本地写集中。也即是说，数据节点设备根据目标事务的执行计划，生成需要插入/更新的数据项，将该数据项放入目标事务的写集结构中，写集结构已在上述实施例之前进行说明，这里不做赘述。在一些实施例中，由于在一些写写冲突率较高的业务负载下，分布式系统通常存在事务回滚率较高的问题，为降低事务回滚率，可以通过意向写技术来进行系统优化。具体地，用户可以通过全局变量定义一个意向写阈值，当某一数据项上的并发写事务数目超过意向写阈值时，分布式数据库系统对该数据项启用意向写技术。在意向写技术中，需要在数据项集合的页眉(header)结构新增一个属性：写意向队列(iwlist)，写意向队列用于表示当前正在等待更新本数据项的事务集合。需要说明的是，写意向队列iwlist与待写事务wt之间的区别在于，写意向队列iwlist是一个列表，在列表中可以记录一个或多个事务标识tid，而待写事务wt中通常会记载单个事务标识tid。在读取阶段中，如果意向写队列技术被启用，当多个并发事务试图修改同一个数据项时，只有一个事务被允许修改该数据项，并对该数据项加排它锁，其他事务的事务标识tid将被添加到意向写队列中(该队列可以为一个先进先出队列)，然后进入等待状态。在上述事务提交/回滚完成后，该数据项上的排它锁释放，并唤醒位于意向写队列队尾的事务标识tid所对应的事务。当数据项上的并发写事务数目降至意向写阈值以下时，意向写技术对该数据项失效，当意向写队列中的所有事务都执行完成后，队列空间被释放。需要说明的是，意向写技术可能会出现死锁问题，假设数据项x和y分别位于不同数据节点设备rm1和rm2上，事务t1和t2并发同时更新数据项x和y，那么在rm1和rm2上基于意向写技术的操作如下：在rm1上，事务t1首先申请到数据项x的排它锁；随后，事务t2申请更新数据项x，因检测到有事务t1正在更新数据项x，所以事务t2被加入到数据项x的意向写队列中，等待事务t1提交后被唤起继续执行。在rm2上，事务t2首先申请到数据项y的排它锁；随后，事务t1申请更新数据项y，因检测到有事务t2正在更新数据项y，所以事务t1被加入到数据项y的意向写队列中，等待事务t2提交后被唤起继续执行。此时会出现事务t1和事务t2相互等待的问题，即产生了死锁。为避免死锁问题而导致分布式系统性能下降，可以设置一个超时等待机制，也即是说，如果事务t在意向写队列中的等待时长超过了系统锁的超时时长，则事务t会选择回滚自身，其中，该系统锁的超时时长由技术人员进行设定，可以是任一大于或等于0的数值，本申请实施例不对超时时长进行具体限定。二、读操作的执行流程若该目标事务涉及针对数据项的读取操作，数据节点设备可以基于该执行请求中的读取条件，确定该读取条件所对应的至少一个数据项；从该至少一个数据项中，确定相对于该目标事务可见的目标数据项，将该目标数据项存储到该目标事务的读集中。可选地，这里的读集可以是本地读集，也可以是全局读集，在本申请实施例中以该读集为本地读集为例进行说明，能够避免因同步全局读集而带来的通信开销。在上述过程中，由于分布式系统中涉及到多级一致性级别，那么对于涉及读操作的目标事务，其执行流程为：根据给定的查询条件(读取条件)，定位到待查询数据项，根据当前设置的一致性级别，执行对应级别的可见性判断算法，判断出待查询数据项中的可见数据(也即目标数据项)。下面，将分别针对不同一致性级别下的可见性判断算法进行介绍，为了描述方便，将目标事务表示为t。1、严格可串行化sss级别的可见性判断算法数据节点设备响应于当前数据库系统的一致性级别为严格可串行化sss，对该至少一个数据项中任一数据项，若产生该数据项的事务的全局提交时间戳v.gts小于该目标事务的全局开始时间戳t.sts，确定该数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项。其中，该全局提交时间戳用于表示事务的全局提交时刻，该全局开始时间戳用于表示事务的全局开始时刻。在一些实施例中，从数据版本的角度出发，数据节点设备可以根据用户给定的读取条件，定位到待判断可见性的数据项，由于属于同一个数据项集合的多个数据版本可以按照时间戳从新到旧的顺序进行存放，那么可以从最新版本开始遍历查找，对于任一数据版本v，数据节点设备可以判断数据版本v的全局提交时间戳v.gts是否小于目标事务开始时获取的全局开始时间戳t.sts，也即是判断v.gts<t.sts是否成立，若成立，确定该数据版本v可见，退出遍历循环，否则，跳转至下一个较老的数据版本，重复执行判断步骤。2、顺序可串行化ss级别、因果可串行化cs级别、因果可重复读crr级别以及因果读已提交crc级别的可见性判断算法数据节点设备响应于当前数据库系统的一致性级别为顺序可串行化ss、因果可串行化cs、因果可重复读crr或者因果读已提交crc中任一项，对该至少一个数据项中任一数据项，若产生该数据项的事务的逻辑提交时间戳v.wts小于该目标事务的逻辑生命周期的时间戳上界t.uppts，确定该数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项。其中，该逻辑提交时间戳用于表示事务的逻辑提交时刻，该全局提交时间戳用于表示事务的全局提交时刻。在一些实施例中，从数据版本的角度出发，数据节点设备可以根据用户给定的读取条件，定位到待判断可见性的数据项，由于属于同一个数据项集合的多个数据版本可以按照时间戳从新到旧的顺序进行存放，那么可以从最新版本开始遍历查找，对于任一数据版本v，数据节点设备可以判断数据版本v的逻辑提交时间戳v.wts是否小于目标事务的逻辑生命周期的时间戳上界t.uppts，也即是判断v.wts<t.uppts是否成立，若成立，确定该数据版本v可见，退出遍历循环，否则，跳转至下一个较老的数据版本，重复执行判断步骤。需要说明的是，上述因果可重复读crr级别和因果读已提交crc级别的可见性判断算法虽然是相同的，但差异在于，在crr级别下，作为读取快照的session.lts是在事务提交时进行更新的，而在crc级别下，作为读取快照的session.lts是在每次语句执行后进行更新的。3、因果快照隔离csi级别的可见性判断算法数据节点设备响应于当前数据库系统的一致性级别为因果快照隔离csi，对该至少一个数据项中任一数据项，若产生该数据项的事务的逻辑提交时间戳v.wts小于该目标事务当前所属会话的最大提交时间戳session.lts，确定该数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项。其中，该逻辑提交时间戳用于表示事务的逻辑提交时刻，该全局提交时间戳用于表示事务的全局提交时刻。其中，该全局提交时间戳用于表示事务的全局提交时刻，该逻辑提交时间戳用于表示事务的逻辑提交时刻，该目标事务当前所属会话的最大提交时间戳用于表示该会话涉及读写操作的数据项中最大的逻辑提交时间戳。在一些实施例中，从数据版本的角度出发，数据节点设备可以根据用户给定的读取条件，定位到待判断可见性的数据项，由于同一数据项集合的多个数据版本通常是按照从新到旧的顺序进行存放的，对于数据项集合的最新版本v，数据节点设备可以判断最新版本v的逻辑提交时间戳v.wts是否小于本会话的最大提交时间戳session.lts，也即是判断v.wts<session.lts条件是否成立，若成立，确定最新版本v可见，退出遍历循环，否则，跳转至下一个较老的数据版本，重复执行判断步骤。表1为多级一致性级别的实现机制总结表，请参考表1，将不同一致性级别下影响事务处理效率的因素进行了总结，可以看出，随着一致性级别的降低，一些系统开销可以被省去，因此事务处理性能也就会随之提高。表1从上述表格中可以看出，只有在最高的sss一致性级别中，才需要获取与全局时间戳生成集群进行交互以获取全局开始时间戳sts以及全局提交时间戳gts，在其余的一致性级别中无需获取全局gts，因此省去一轮与全局时间戳生成集群之间的通信，也就节约了获取全局gts的通信开销，并且，随着一致性级别的降低，可以省去验证开销、允许丢失更新异常现象的发生，从而优化分布式数据库系统的性能。需要说明的是，一致性级别越高时所允许发生的数据异常类型越少，那么数据库系统的容错率就越低，而随着一致性级别的降低，最低的crc一致性级别中将不能避免丢失更新异常现象的发生。如图6所示，示出了多级别一致性整体实现的技术方案，通过不同系统模块的组合，可以实现不同的一致性级别，可以看出，只有sss级别中需要从全局时间戳生成集群中获取全局时间戳gts，并且，在sss级别、ss级别以及cs级别中，需要对逻辑生命周期进行动态调整，而在基于mvcc(multi-versionconcurrencycontrol，多版本并发控制)的机制下，可以满足csi级别、crc级别、crr级别的一致性需求。在一些实施例中，数据节点设备在基于不同一致性级别的可见性判断算法确定出相对于目标事务可见的目标数据项之后，对任一个目标数据项，还可以执行如下子步骤5031-5033：5031、数据节点设备将目标事务的事务标识tid写入到读取的目标数据项对应的活跃事务集合rtlist中。其中，rtlist是目标数据项所属数据项集合的页眉(header)结构中一个属性值，rtlist中记录了访问过该数据项集合中最新数据版本的活跃事务集合，该活跃事务集合可以是数组的形式，也可以是列表、队列、堆栈等形式，本申请实施例不对活跃事务集合的形式进行具体限定，rtlist中每个元素可以是读取过上述最新数据版本的事务的事务标识(tid)。5032、数据节点设备基于目标数据项的逻辑提交时间戳，对该目标事务的逻辑生命周期的时间戳下界进行调整，得到调整后的时间戳下界，该调整后的时间戳下界大于该目标数据项的逻辑提交时间戳。在上述过程中，数据节点设备调整目标事务的逻辑生命周期的时间戳下界t.lowts，使得调整后的时间戳下界t.lowts大于所读取到的目标数据项上记录的逻辑提交时间戳wts，其中，由于在上述实施例之前介绍了本申请实施例中数据项的基本数据结构，在每个数据项的键中均记录了<user_key，wts，gts>，因此只需要调整t.lowts大于目标数据项的键中记载的wts即可。在一些实施例中，针对时间戳下界的调整方式可以包括下述至少一项：1、数据节点设备响应于任一目标数据项的逻辑提交时间戳小于该时间戳下界，将该时间戳下界确定为调整后的时间戳下界。也即是说，若t.lowts>v.wts，将t.lowts置为t.lowts不变。2、数据节点设备响应于任一目标数据项的逻辑提交时间戳等于该时间戳下界，将该目标数据项的最终提交时间戳加一所得的数值确定为调整后的时间戳下界。也即是说，若t.lowts＝v.wts，将t.lowts置为v.cts+1(令t.lowts＝v.cts+1)。其中，该最终提交时间戳v.cts处于产生目标数据项的事务的逻辑生命周期[lowts，uppts)中。3、数据节点设备响应于任一目标数据项的逻辑提交时间戳大于该时间戳下界，将该目标数据项的最终提交时间戳确定为调整后的时间戳下界。也即是说，若t.lowts<v.wts，将t.lowts置为v.cts(令t.lowts＝v.cts)。其中，该最终提交时间戳v.cts处于产生目标数据项的事务的逻辑生命周期[lowts，uppts)中。上述三种方式可以统一表示为下述公式：5033、数据节点设备响应于该目标数据项的待写事务不为空，将该目标事务的逻辑生命周期的时间戳上界调整为该时间戳上界与待写事务的时间戳下界中的最小值。在上述过程中，数据节点设备可以判断当前数据版本对应的数据项页眉结构中的wt字段是否为0，wt表示该数据项所对应的待写事务，wt中可以记录所有要写入该数据项的事务的事务标识(tid)。若wt字段不为0，那么需要调整目标事务的时间戳上界小于wt内记载事务的时间戳上界，也即是说，令t.uppts＝min(t.uppts,wt.lowts)。在一些实施例中，如果当前分布式数据库系统的一致性级别设置为因果读已提交crc级别，那么每次读取到某一相对于目标事务可见的目标数据项之后，都需要将session.lts更新为session.lts的当前值与目标数据项的逻辑提交时间戳wts之间的最大值。504、数据节点设备向协调节点设备返回目标事务的执行结果。在上述过程中，数据节点设备向协调节点设备发送执行结果(res，可视为一种返回消息)，同时还可以在执行结果中封装当前数据节点设备上目标事务的状态信息、当前读写操作的结果集(包括本地读集和本地写集)以及操作是否成功的返回值，本申请实施例不对执行结果中包含的内容进行具体限定。上述步骤504与上述步骤404类似，这里不做赘述。505、协调节点设备向数据节点设备发送目标事务的验证请求。在上述过程中，协调节点设备接收到执行结果之后，首先检查携带的状态信息中事务状态是否为正在回滚状态aborting，如果是，那么进入全局回滚阶段，否则，将协调节点设备上目标事务的事务状态(status)更新为正在验证状态validating，执行上述步骤505中发送验证请求的操作，其中，该验证请求中封装了status＝validating。在一些实施例中，如果数据节点设备检测出逻辑生命周期不合法，也即是检测到t.lowts≥t.uppts，那么也会进入到全局回滚阶段。上述步骤505与上述步骤406类似，这里不做赘述。从上述事务执行阶段可以看出，在执行目标事务的过程中，通信主要在目标事务的协调节点设备和相关数据节点设备之间发生，目标事务每成功读取一次数据需要两次通信：目标事务的协调节点设备发送请求信息到相关的数据节点设备上、相关的数据节点设备返回结果给协调节点设备。因此，在事务执行阶段，假设n为远程读取的次数，那么最多需要进行2n次通信，最大通信量可以表示为n×(请求消息大小+响应消息大小)。506、数据节点设备响应于该验证请求，对目标事务进行冲突验证。在传统的occ(optimisticconcurrencycontrol，乐观并发控制)冲突验证算法中，是将待验证事务的读集和已经完成事务的写集进行比较，这样会导致验证阶段产生大量的事务回滚。在本申请实施例中，采用了动态调整事务可串行化顺序的思想，来对事务验证阶段进行优化，具体地验证算法如下：5061、数据节点设备响应于目标事务的验证请求，更新该目标事务的状态信息中的事务状态status。也即是说，数据节点设备解析验证请求，将验证请求中携带的事务状态status的取值赋值给本地存储的事务状态status。5062、数据节点设备响应于该目标事务的验证请求，基于该目标事务的写集，对该目标事务的逻辑生命周期进行调整，得到目标生命周期，该目标生命周期与该写集中数据项的读事务不存在读写冲突。在一些实施例中，在事务验证阶段对目标事务的逻辑生命周期进行调整，是为了防止由于读写冲突而造成的回滚，遍历本地写集中的每个元素(也即每个数据项)，对目标事务的逻辑生命周期进行如下调整：1.1)数据节点设备获取该写集中待写入的数据项的最大读事务时间戳rts。上述写集可以是本地写集，也可以是全局写集，在本申请实施例中以该写集为本地写集为例进行说明，这样能够避免因同步全局写集而带来的通信开销。其中，该最大读事务时间戳rts用于表示读取过该数据项的事务的逻辑提交时间戳中的最大值，该最大读事务时间戳rts记录在每个数据项所对应的页面结构中。1.2)数据节点设备确定各个待写入的数据项的最大读事务时间戳中的最大值。1.3)数据节点设备响应于该逻辑生命周期的时间戳下界大于该最大值，将该逻辑生命周期的时间戳下界确定为该目标生命周期的时间戳下界。1.4)数据节点设备响应于该逻辑生命周期的时间戳下界等于该最大值，将该最大值加一所得的数值确定为该目标生命周期的时间戳下界。1.5)数据节点设备响应于该逻辑生命周期的时间戳下界小于该最大值，将该最大值确定为该目标生命周期的时间戳下界。上述步骤1.1)-1.5)中，逻辑生命周期的调整规则为，将时间戳下界调整至大于写集中所有待写入的数据项的最大读事务时间戳rts，上述调整规则可以表示如下公式：在一些实施例中，除了进行上述1.1)-1.5)中针对逻辑生命周期的调整之外，还可以进行如下调整：2.1)数据节点设备获取该写集中待写入的数据项所对应活跃事务列表中读事务tc的事务状态。其中，活跃事务列表中读事务tc的数量可以是一个或多个，本申请实施例不对读事务tc的数量进行具体限定。2.2)数据节点设备对于事务状态为验证通过状态validated或提交完成状态committed的读事务tc，将该读事务的时间戳上界tc.uppts以及该逻辑生命周期的时间戳下界t.lowts中的最大值确定为该目标生命周期的时间戳下界。也即是说，对于每个待写入数据项的活跃事务列表中的每个读事务tc，如果读事务tc处于验证通过状态validated或提交完成状态committed，那么将目标生命周期的时间戳下界调整为大于读事务tc的时间戳上界，也即是，令t.lowts＝max(tc.uppts，t.lowts)。2.3)对于事务状态为正在运行状态running的读事务tc，响应于该读事务的时间戳下界tc.lowts等于该逻辑生命周期的时间戳下界t.lowts，将该读事务的时间戳下界加一所得的数值(tc.lowts+1)确定为该目标生命周期的时间戳下界；响应于该读事务的时间戳下界tc.lowts大于该逻辑生命周期的时间戳下界t.lowts，将该读事务的时间戳下界tc.lowts确定为该目标生命周期的时间戳下界；将该读事务的时间戳上界tc.uppts调整为该读事务的时间戳上界与该目标生命周期的时间戳下界中的最小值。也即是说，对于每个待写入数据项的活跃事务列表中的每个读事务tc，如果读事务tc处于正在运行状态running，如果tc.lowts等于t.lowts，那么调整t.lowts＝tc.lowts+1；如果tc.lowts大于t.lowts，那么调整t.lowts＝tc.lowts。进一步地，将调整读事务tc的时间戳上界小于或等于目标事务的时间戳下界，也即是说，令tc.uppts＝min(tc.uppts，t.lowts)。在一些实施例中，在进行逻辑生命周期的调整过程中，还可以考虑基于优先级的调整机制或者机制回滚代价的调整机制。也即是说，数据节点设备可以基于该目标事务以及该目标事务的写集中数据项所对应活跃事务列表中读事务的优先级或者回滚代价中至少一项，对该目标事务的逻辑生命周期或者该读事务的逻辑生命周期进行调整。以下，将分别对基于优先级和基于回滚代价的调整机制进行分类讨论。a、基于优先级的调整机制基于优先级的调整机制能够降低分布式数据库系统中事务饿死现象的出现概率，事务饿死现象是指事务回滚后重启后又再次被回滚，且该过程被重复n(n≥1)次。本申请实施例可以通过为事务设置优先级的方法来解决事务饿死现象，基本思想为：如果事务回滚次数较多，会为其设置一个较高的优先级；当需要调整事务的逻辑生命周期时，优先选择压缩优先级较低事务的逻辑生命周期，从而使得较高优先级事务可以具有较高的被提交概率。在一些实施例中，可以在事务的状态信息中添加一个新的属性值priority(事务的优先级)，任一事务t的优先级越高时，当t与其他事务产生冲突时越不容易被回滚，事务的优先级可以用于表示事务的重启次数，从而使得重启次数(回滚次数)越多的事务具有越高的优先级。在上述基础上，事务的初始化阶段需要进行额外操作：设置事务t的事务优先级priority等于事务t重启的次数，即等于事务t回滚前的优先级加一所得的数值，也即是说，事务t每被回滚一次，那么优先级则增加一个数值。事务在第一次被初始化时优先级为0，如果事务在执行过程中被回滚了n(n≥1)次，则在第n+1次重启时会将其优先级设置为n。在增加了事务优先级属性之后，在事务验证阶段中，对于本事务t(目标事务)和写集中每个元素(也即是每个待写入数据项)的活跃事务列表rtlist中的读事务tc的逻辑生命周期调整策略需要修改为，如果读事务tc为正在运行状态running，则需要根据t或者tc的优先级确定调整策略，具体策略可以包括：3.1)如果目标事务t的优先级大于或等于读事务tc的优先级，调整读事务tc的时间戳上界小于或等于目标事务t的时间戳下界，也即是说：如果tc.lowts等于t.lowts，则要首先调整t.lowts＝tc.lowts+1；如果tc.lowts大于t.lowts，则要首先调整t.lowts＝tc.lowts；调整读事务tc的时间戳上界小于或等于目标事务t的时间戳下界，也即是说，令tc.uppts＝min(tc.uppts，t.lowts)。3.2)如果目标事务t的优先级小于读事务tc的优先级，调整目标事务t的时间戳下界大于或等于读事务tc的时间戳上界，也即是说：如果tc.lowts等于t.lowts，则要首先调整t.lowts＝tc.lowts+1；如果tc.lowts大于t.lowts，则要首先调整t.lowts＝tc.lowts；调整目标事务t的时间戳下界大于或等于读事务tc的时间戳上界，也即是说，令t.lowts＝max(tc.uppts，t.lowts)。b、基于回滚代价的调整机制在事务执行的验证阶段，待验证事务t会压缩与之有冲突的处于正在运行状态running的事务tc的逻辑生命周期，从而增大了事务tc的回滚率，如果事务tc是一个已经执行很久的事务，那么回滚事务tc的代价较高。因此，本申请实施例针对这一问题，定义了一个回滚代价模型，当并发事务之间产生冲突时，可以优先选择回滚代价小的事务进行回滚。基于代价的回滚策略包括：在本申请实施例中，事务的回滚代价(用符号c表示)通过事务的读写集合的大小来进行建模，回滚代价模型的计算公式为：c＝size(ws)+size(rs)，其中size(ws)表示全局写集的大小，size(rs)表示全局读集的大小。这是因为读写集合所包含的数据越多(尺寸越大)时，一旦事务回滚所带来的开销则是这些操作需要重新执行，因此，可以认为事务的读写集合大小与事务的回滚代价呈正相关。在引入基于代价的回滚策略后，事务验证阶段中，对于目标事务t和写集中每个元素(也即是每个待写入数据项)的活跃事务列表rtlist中读事务tc的逻辑生命周期调整策略需要修改为，如果tc为正在运行状态running，则需要根据t或者tc的回滚代价决定调整策略：4.1)如果目标事务t的回滚代价大于或等于读事务tc的回滚代价，调整读事务tc的时间戳上界小于或等于目标事务t的时间戳下界，具体的：如果tc.lowts等于t.lowts，则要首先调整t.lowts＝tc.lowts+1；如果tc.lowts大于t.lowts，则要首先调整t.lowts＝tc.lowts；调整读事务tc的时间戳上界小于或等于目标事务t的时间戳下界，也即是说，令tc.uppts＝min(tc.uppts，t.lowts)。4.2)如果目标事务t的回滚代价小于读事务tc的回滚代价，调整目标事务t的时间戳下界大于或等于读事务tc的时间戳上界，也即是说：如果tc.lowts等于t.lowts，则要首先调整t.lowts＝tc.lowts+1；如果tc.lowts大于t.lowts，则要首先调整t.lowts＝tc.lowts；调整目标事务t的时间戳下界大于或等于读事务tc的时间戳上界，也即是说，令t.lowts＝max(tc.uppts，t.lowts)。在一些实施例中，如果同时考虑了优先级和回滚代价，而基于回滚代价的调整策略与基于优先级的调整策略出现冲突时，用户可以通过设置一个全局参数，配置默认的调整策略，当选择默认为代价回滚策略时，以基于回滚代价的调整策略为准；否则，以基于优先级的调整策略为准。在一些实施例中，由于传统的读写、写读冲突的检测均是以数据项(元组)为单位进行的，这种元组粒度的冲突检测机制的粒度较粗。例如，存在如表2所示的student表(学生表)，其包含两个数据项tuple1和tuple2，每个数据项由id(学号)、name(姓名)、age(年龄)和group(组别)四个字段构成。存在事务t1和t2并发操作student表，如果事务t1先读取了tuple1的group字段，事务t2后修改了tuple1的age字段。事务t1和事务t2虽然操作了同一个元组，但是事务t2和事务t1修改不同的字段，可以认为没有读写冲突，在传统的冲突检测会认为事务t1和t2存在读写冲突，从而导致其中一个事务回滚，可见在元组粒度下的冲突检测机制会带来较高的事务回滚率，影响并发事务的吞吐量，在本申请实施例还提供一种细粒度的冲突检测机制，能够对验证阶段进行优化，以减少事务回滚率。表2学号id姓名name年龄age组别grouptuple10001alan18x组tuple20002tony16y组下面将对细粒度的冲突检测机制进行介绍，细粒度的冲突检测机制能够对事务验证阶段进行优化，减少分布式数据库系统中的事务回滚率，在细粒度下两个并发事务之间存在冲突的定义为：存在两个并发事务，对同一元组的相同字段进行写操作或者一读一写操作，则认为上述两个并发事务之间存在冲突。也即是说，在对目标事务进行冲突验证的过程中，响应于目标事务所修改的数据项的字段与并发事务所修改的数据项的字段相同，确定该目标事务与该并发事务存在读写冲突；否则，确定该目标事务与该并发事务不存在读写冲突。在上述定义的基础上，可以针对数据项集合的页面结构header中记录的活跃事务列表rtlist进行改进，也即是原本内存链表的每个节点扩充为一个二元组，在二元组中包括tid和fields两个元素，其中，tid用于表示读取过该数据项的事务的事务标识，fields用于表示上述读事务所读取的字段id，fields可以以数组的形式进行存储。同理，还可以针对数据项集合的页面结构header中记录的待写事务wt进行改进，也即是原本内存链表的每个节点扩充为一个二元组，在二元组中包括tid和fields两个元素，其中，tid用于表示正在更新该数据项的事务的事务标识，fields用于表示上述写事务所更新的字段id，fields可以以数组的形式进行存储。在细粒度的冲突检测机制下，在事务读取阶段中，为消除读写冲突，目标事务t在读取数据项x时会首先检查数据项x的待写事务wt是否为0，如果为0，即表明当前只有本事务在写数据项x，即不存在读写冲突；如果wt不为0，且wt对应的写事务记为tc，还需要通过如下机制来进行细粒度的冲突检测：如果目标事务t所读数据项x的fields字段和写事务tc所修改的字段fields1存在交集，认为目标事务t和写事务tc之间存在并发冲突，需要对目标事务的逻辑生命周期进行调整，其调整规则为t.uppts＝min(t.uppts，tc.lowts-1)。如果目标事务t所读数据项x的fields字段和写事务tc所修改的字段fileds1不存在交集，则根据细粒度冲突检测中冲突的定义，认为目标事务t和写事务tc之间不存在冲突，即不需要调整目标事务的逻辑生命周期。在事务验证阶段中，为消除读写冲突，目标事务t在更新数据项的若干字段fields时，会检查各个数据项的活跃事务列表rtlist中的每个读事务tc读取该数据项的字段集合fields2，如果fields和field2存在交集，则认为目标事务t和读事务tc之间存在冲突，需要对目标事务的逻辑生命周期进行调整；否则，认为目标事务t和读事务tc之间不存在冲突，即不需要调整目标事务的逻辑生命周期。在一些实施例中，数据节点设备还可以在目标数据项对应的待写事务wt中写入目标事务的事务标识tid。在上述过程中，可以使用无锁的cas(compareandswap，比较与交换，一种无锁算法)技术为wt进行赋值，以提高分布式数据库系统的性能；如果目标数据项的待写事务wt不为0，则将目标事务t事务状态status置为正在回滚状态aborting，并直接向协调节点设备返回验证失败信息。5063、数据节点设备对目标事务调整后的目标生命周期进行校验。在上述过程中，由于基于各种针对逻辑生命周期的调整策略，在验证阶段为避免读写冲突对目标事务的逻辑生命周期进行了修改，得到了目标生命周期，此时仍然需要对目标生命周期进行再次的合法性校验，也即是说，检测目标生命周期的时间戳下界是否仍小于目标生命周期的时间戳上界，响应于该时间戳下界小于该时间戳上界，确定对该目标生命周期校验通过，将本地状态信息中的事务状态status更新为验证通过状态validated，也即令t.status＝validated；否则，响应于该时间戳下界大于或等于该时间戳上界，确定对该目标生命周期校验不通过，此时可以将本地状态信息中的事务状态status更新为正在回滚状态aborting，也即令t.status＝aborting，并向协调节点设备返回验证失败信息。507、数据节点设备向协调节点设备返回目标事务的验证结果。在上述过程中，数据节点设备向协调节点设备返回本地的验证结果(res)，同时还可以在验证结果中封装本地的目标事务的状态信息，该状态信息中包括目标生命周期。上述步骤507与上述步骤407类似，这里不做赘述。从上述事务验证阶段可以看出，在验证目标事务的过程中，通信主要在目标事务的协调节点设备和相关数据节点设备之间发生，通信包括两类：目标事务的协调节点设备向每个相关的数据节点设备发送验证请求及本地写集、相关的数据节点设备反馈本地的验证结果给协调节点设备。因此，在事务验证阶段，假设m为与目标事务t相关的数据节点设备的数量，那么最多需要进行2m次通信，最大通信量可以表示为m×(验证请求消息大小+验证结果消息大小)+全局写集大小。508、协调节点设备汇总数据节点设备的验证结果，确定目标事务的全局验证结果。协调节点设备在接收到所有相关数据节点设备反馈的本地验证结果之后，需要判断目标事务t是进入提交阶段还是回滚阶段，判断方法可以如下：如果在所有的验证结果中，不存在事务状态status被置为正在回滚状态aborting的验证结果，那么将所有相关数据节点设备上的目标生命周期(携带在验证结果中)求交集，得到新的时间戳区间[t.lowts，t.uppts)，协调节点设备对上述时间戳区间进行校验，如果对上述时间戳区间校验通过，确定全局验证结果为验证通过，选取当前时间戳区间的t.lowts作为目标事务t的逻辑提交时间戳t.wts，将目标事务的全局事务状态记为提交完成状态committed，并向所有相关数据节点设备发送目标事务的提交指令；否则，如果对上述时间戳区间校验不通过，或者如果存在事务状态status被置为正在回滚状态aborting的验证结果，表明目标事务t没有通过验证，确定全局验证结果为验证不通过，则需要回滚目标事务t，此时协调节点设备将目标事务t的事务状态设置为回滚完成状态aborted，并向所有相关数据节点设备发送目标事务的回滚指令。在一些实施例中，只有严格可串行化sss的一致性级别下，所有事务都必须从全局时间戳生成集群中获取全局提交时间戳gts；其余的一致性级别(包括ss、cs、crr、crc)均不需要获取全局提交时间戳gts，只需要得到逻辑提交时间戳wts即可。因此，当用户不需要动态调整一致性级别时(即事务的隔离级别设定好后，对所有的事务生效，如果改动隔离级别，则需要重新启动数据库)，且设置为非sss级别时，事务整体执行流程中，均不需要与“全局gts生成集群”进行通信，不需要获取全局提交时间戳。在一些实施例中，为了支持不同一致性级别的动态调整(动态调整是指：不用重新启动数据库实例，即可设置不同事务的隔离级别)，在事务提交阶段，对于分布式数据库系统内的所有事务，协调节点设备都需要与全局时间戳生成集群进行通信，获取当前的全局时间戳，并赋值给全局提交时间戳t.gts。509、协调节点设备响应于全局验证结果为验证通过，向数据节点设备发送目标事务的提交指令。上述步骤509与上述步骤409类似，这里不做赘述。510、数据节点设备响应于对该目标事务的冲突验证通过，提交目标事务。在上述过程中，数据节点设备接收到协调节点设备的提交指令之后，可以执行下述几项操作中的至少一项：1)数据节点设备将目标事务的写集中的数据落盘，并在每个新写入的数据项的key中拼入协调节点设备传来的逻辑提交时间戳wts和全局提交时间戳gts。2)若当前系统的一致性级别为因果可重复读crr级别或者因果可串行化cs级别，数据节点设备将session.lts更新为session.lts的当前值与目标数据项的逻辑提交时间戳wts之间的最大值。3)数据节点设备清理目标事务的事务执行上下文信息。具体地，数据节点设备可以将每个读集中数据项对应的最大读事务时间戳rts修改为rts与逻辑提交时间戳wts两者中的最大值，从该数据项的活跃事务列表rtlist中将目标事务的事务标识tid删除。进一步地，数据节点设备还可以将每个写集中数据项原本的wts修改为目标事务的逻辑提交时间戳。进一步地，数据节点设备还可以将写集中数据项对应的wt(待写事务)字段重置为0。进一步地，数据节点设备还可以清空目标事务t的读集和写集。在一些实施例中，由于有可能协调节点设备对目标事务验证不通过，此时发送的是回滚指令，在数据节点设备接收到回滚指令之后，仍然需要对事务执行上下文信息进行清理：具体地，数据节点设备可以在每个读集中数据项的活跃事务列表rtlist中将目标事务的事务标识tid删除。进一步地，还可以将写集中数据项对应的wt(待写事务)字段重置为0。进一步地，还可以清空目标事务t的读集和写集。从上述情况可以看出，在目标事务t的提交/回滚阶段，通信主要在目标事务t的协调节点设备和相关数据节点设备之间发生，通信主要包含以下两类：目标事务t的协调节点设备向每个相关数据节点设备发送提交/回滚指令、每个相关数据节点设备向协调节点设备发送相应的提交/回滚完成消息。因此，提交/回滚阶段最多进行2m次通信，通信量的大小为m×(提交/回滚指令消息大小+提交/回滚完成消息大小)，其中m为目标事务t相关数据节点设备的个数。在一些实施例中，还可以提供一种懒惰删除(lazydeletion)策略，这是由于如果目标事务的读集较大，且系统内存有限，部分读集会被维护在外存中，那么事务提交/回滚阶段的清理工作将耗费大量的时间，增加了目标事务的执行时长。为了加快事务的执行速度，本申请实施例提供一种懒惰删除策略，能够由后续其他事务来完成部分清理操作，懒惰删除策略的具体执行流程包括：数据节点设备响应于该目标事务涉及到读取任一数据项，获取该数据项的活跃事务列表中读事务的事务状态；在该数据项的活跃事务集合中删除事务状态为提交完成状态或回滚完成状态的读事务。在一个示例中，当目标事务之后的某一事务读到某一数据项x时，检查数据项x的活跃事务列表rtlist中每个事务t的事务状态。如果事务t在数据节点设备上的事务状态为提交完成状态committed，则修改当前数据项的最大读事务时间戳rts，使其大于或等于事务t的逻辑提交时间戳t.cts，即令x.rts＝max(x.rts,t.cts)，并从数据项x的活跃事务列表rtlist中将事务t的事务标识tid删除；如果事务t的事务状态为回滚完成状态aborted，则可以将事务t的事务标识tid从数据项x的活跃事务列表rtlist中删除。在上述懒惰删除策略中，虽然事务t将对读集元素的清理工作交由其他事务t1来完成，增加了t1在读取阶段的执行时间，但是懒惰删除策略可以减少t和t1总的i/o(input/output，输入/输出)次数，从而减少分布式数据库系统的总i/o开销，以先后执行的两个事务t和t1为例进行说明：如果不使用懒惰删除策略，在读取阶段事务t通过两次i/o读取到数据项x的值，并在提交阶段再通过两次i/o来更新x的最大读事务时间戳rts；同理，t1的执行需要四次i/o，即t和t1共进行八次i/o。在使用懒惰删除策略的情况下，在读取阶段事务t通过一次i/o读取到数据项x的值，在提交阶段，无需更新数据项x的最大读事务时间戳rts；事务t1在读取阶段，通过一次i/o来读取数据项x，并替事务t更新数据项x的最大读事务时间戳rts，在提交阶段，同样因无需更新数据项x的最大读事务时间戳rts而不需要执行i/o操作，t和t1共进行了两次i/o，大大降低了分布式数据库系统的总i/o开销。上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。本申请实施例提供的事务处理方法，通过响应于目标事务的执行请求，获取该目标事务的状态信息，校验基于该状态信息确定的逻辑生命周期，响应于对该逻辑生命周期校验通过，执行该目标事务，响应于对该目标事务的冲突验证通过，提交该目标事务，也即是说，在事务处理过程中并不依赖于某个全局逻辑时钟，而是依赖于针对逻辑生命周期的校验，逻辑生命周期在事务执行和验证过程中会依据冲突检测结果进行调整，通过对逻辑生命周期进行校验即可完成事务处理过程，也就改善了数据库系统的单点瓶颈问题，提升了数据库系统的可拓展性。进一步地，本申请实施例提供的分布式事务多级一致性模型，能够为分布式事务(也即全局事务)处理的正确性提供一种衡量标准，从而方便分布式事务可以在正确性和性能之间做出权衡。通过采用不同级别的一致性，保证系统可以适用于对正确性和性能要求不同的业务负载。进一步地，本申请实施例提供的分布式事务处理解决方案，使得系统具备同时支持多级一致性的能力，并且保证系统可以在不同一致性级别之间进行切换。进一步地，本申请实施例提供的懒惰删除策略，能够减少事务执行时的额外i/o开销，本申请实施例提供的细粒度冲突检测方案，通过细化冲突识别粒度，减少事务回滚率，本申请实施例提供的基于优先级的事务调度技术，通过避免事务饿死现象，优化系统整体性能，本申请实施例提供的基于代价的回滚策略，监控回滚代价，降低事务回滚所带来的额外开销，本申请实施例提供的意向写技术，能够减少写写冲突带来的回滚开销，也即是说，上述一系列优化策略能够优化分布式事务的执行效率，减少事务回滚率和回滚开销，从而提升系统整体效率。图7是本申请实施例提供的一种事务处理装置的结构示意图，请参考图7，该装置包括：获取模块701，用于响应于目标事务的执行请求，获取该目标事务的状态信息，该状态信息用于表示该目标事务当前所处的执行状态；校验模块702，用于校验基于该状态信息确定的逻辑生命周期，该逻辑生命周期用于表示该目标事务在事务处理过程中的逻辑时间戳区间；执行模块703，用于响应于对该逻辑生命周期校验通过，执行该目标事务；提交模块704，用于响应于对该目标事务的冲突验证通过，提交该目标事务。本申请实施例提供的事务处理装置，通过响应于目标事务的执行请求，获取该目标事务的状态信息，校验基于该状态信息确定的逻辑生命周期，响应于对该逻辑生命周期校验通过，执行该目标事务，响应于对该目标事务的冲突验证通过，提交该目标事务，也即是说，在事务处理过程中并不依赖于某个全局逻辑时钟，而是依赖于针对逻辑生命周期的校验，逻辑生命周期在事务执行和验证过程中会依据冲突检测结果进行调整，通过对逻辑生命周期进行校验即可完成事务处理过程，也就改善了数据库系统的单点瓶颈问题，提升了数据库系统的可拓展性。在一种可能实施方式中，该状态信息包括该逻辑生命周期的时间戳下界和时间戳上界；该校验模块702用于：响应于该时间戳下界小于该时间戳上界，确定对该逻辑生命周期校验通过；响应于该时间戳下界大于或等于该时间戳上界，确定对该逻辑生命周期校验不通过。在一种可能实施方式中，若该目标事务涉及针对数据项的读取操作，基于图7的装置组成，该执行模块703包括：确定单元，用于基于该执行请求中的读取条件，确定该读取条件所对应的至少一个数据项；确定存储单元，用于从该至少一个数据项中，确定相对于该目标事务可见的目标数据项，将该目标数据项存储到该目标事务的读集中。在一种可能实施方式中，该确定存储单元用于：响应于当前数据库系统的一致性级别为严格可串行化，对该至少一个数据项中任一数据项，若产生该数据项的事务的全局提交时间戳小于该目标事务的全局开始时间戳，确定该数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，该全局提交时间戳用于表示事务的全局提交时刻，该全局开始时间戳用于表示事务的全局开始时刻。在一种可能实施方式中，该确定存储单元用于：响应于当前数据库系统的一致性级别为顺序可串行化、因果可串行化、因果可重复读或者因果读已提交中任一项，对该至少一个数据项中任一数据项，若产生该数据项的事务的逻辑提交时间戳小于该目标事务的逻辑生命周期的时间戳上界，确定该数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，该逻辑提交时间戳用于表示事务的逻辑提交时刻，该全局提交时间戳用于表示事务的全局提交时刻。在一种可能实施方式中，该确定存储单元用于：响应于当前数据库系统的一致性级别为因果快照隔离，对所述至少一个数据项中任一数据项，若产生所述数据项的事务的逻辑提交时间戳小于所述目标事务当前所属会话的最大提交时间戳，确定所述数据项为候选数据项；将具有相同主键标识的候选数据项中全局提交时间戳最大的候选数据项确定为目标数据项；其中，该全局提交时间戳用于表示事务的全局提交时刻，该逻辑提交时间戳用于表示事务的逻辑提交时刻，该目标事务当前所属会话的最大提交时间戳用于表示该会话涉及读写操作的数据项中最大的逻辑提交时间戳。在一种可能实施方式中，基于图7的装置组成，该装置还包括：第一调整模块，用于基于该目标数据项的逻辑提交时间戳，对该目标事务的逻辑生命周期的时间戳下界进行调整，得到调整后的时间戳下界，该调整后的时间戳下界大于该目标数据项的逻辑提交时间戳。在一种可能实施方式中，该第一调整模块用于：响应于任一目标数据项的逻辑提交时间戳小于该时间戳下界，将该时间戳下界确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳等于该时间戳下界，将该目标数据项的最终提交时间戳加一所得的数值确定为调整后的时间戳下界；或，响应于任一目标数据项的逻辑提交时间戳大于该时间戳下界，将该目标数据项的最终提交时间戳确定为调整后的时间戳下界；其中，该最终提交时间戳处于产生目标数据项的事务的逻辑生命周期中。在一种可能实施方式中，基于图7的装置组成，该装置还包括：第二调整模块，用于响应于该目标数据项的待写事务不为空，将该目标事务的逻辑生命周期的时间戳上界调整为该时间戳上界与待写事务的时间戳下界中的最小值。在一种可能实施方式中，若该目标事务涉及针对数据项的写入操作，该执行模块703用于：基于该执行请求，生成待写入的数据项，将该待写入的数据项存储到该目标事务的写集中。在一种可能实施方式中，基于图7的装置组成，该装置还包括：更新模块，用于响应于该目标事务的验证请求，更新该目标事务的状态信息；或，第三调整模块，用于响应于该目标事务的验证请求，基于该目标事务的写集，对该目标事务的逻辑生命周期进行调整，得到目标生命周期，该目标生命周期与该写集中数据项的读事务不存在读写冲突。在一种可能实施方式中，该第三调整模块用于：获取该写集中待写入的数据项的最大读事务时间戳，该最大读事务时间戳用于表示读取过该数据项的事务的逻辑提交时间戳中的最大值；确定各个待写入的数据项的最大读事务时间戳中的最大值；响应于该逻辑生命周期的时间戳下界大于该最大值，将该逻辑生命周期的时间戳下界确定为该目标生命周期的时间戳下界；响应于该逻辑生命周期的时间戳下界等于该最大值，将该最大值加一所得的数值确定为该目标生命周期的时间戳下界；响应于该逻辑生命周期的时间戳下界小于该最大值，将该最大值确定为该目标生命周期的时间戳下界。在一种可能实施方式中，该第三调整模块用于：获取该写集中待写入的数据项所对应活跃事务列表中读事务的事务状态；对于事务状态为验证通过状态或提交完成状态的读事务，将该读事务的时间戳上界以及该逻辑生命周期的时间戳下界中的最大值确定为该目标生命周期的时间戳下界；对于事务状态为正在运行状态的读事务，响应于该读事务的时间戳下界等于该逻辑生命周期的时间戳下界，将该读事务的时间戳下界加一所得的数值确定为该目标生命周期的时间戳下界；响应于该读事务的时间戳下界大于该逻辑生命周期的时间戳下界，将该读事务的时间戳下界确定为该目标生命周期的时间戳下界；将该读事务的时间戳上界调整为该读事务的时间戳上界与该目标生命周期的时间戳下界中的最小值。在一种可能实施方式中，基于图7的装置组成，该装置还包括：获取删除模块，用于响应于该目标事务涉及到读取任一数据项，获取该数据项的活跃事务列表中读事务的事务状态；在该数据项的活跃事务集合中删除事务状态为提交完成状态或回滚完成状态的读事务。在一种可能实施方式中，基于图7的装置组成，该装置还包括：第四调整模块，用于基于该目标事务以及该目标事务的写集中数据项所对应活跃事务列表中读事务的优先级或者回滚代价中至少一项，对该目标事务的逻辑生命周期或者该读事务的逻辑生命周期进行调整。在一种可能实施方式中，基于图7的装置组成，该装置还包括：冲突验证模块，用于在对该目标事务进行冲突验证的过程中，响应于该目标事务所修改的数据项的字段与并发事务所修改的数据项的字段相同，确定该目标事务与该并发事务存在读写冲突；否则，确定该目标事务与该并发事务不存在读写冲突。上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。需要说明的是：上述实施例提供的事务处理装置在处理事务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务处理装置与事务处理方法实施例属于同一构思，其具体实现过程详见事务处理方法实施例，这里不再赘述。图8是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)801和一个或一个以上的存储器802，其中，该存储器802中存储有至少一条程序代码，该至少一条程序代码由该处理器801加载并执行以实现上述各个实施例提供的事务处理方法。当然，该计算机设备800还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备800还可以包括其他用于实现设备功能的部件，在此不做赘述。在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条程序代码的存储器，上述至少一条程序代码可由终端中的处理器执行以完成上述实施例中事务处理方法。例如，该计算机可读存储介质可以是rom(read-onlymemory，只读存储器)、ram(random-accessmemory，随机存取存储器)、cd-rom(compactdiscread-onlymemory，只读光盘)、磁带、软盘和光数据存储设备等。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12当前第1页12