CN106503020A - 日志数据处理方法及装置 - Google Patents

Abstract

本申请提供一种日志数据处理方法及装置。在方法中，多日志队列来存储事务日志，允许事务日志的并行写入，在读事务日志时，通过指定日志队列的读取顺序，结合事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志，用以保证事务日志在出队时的顺序性和确定性，满足数据库对事务日志的基本需求，同时解决了分布式数据库系统在事务日志管理方面面临的单机队列瓶颈，提高了分布式数据库系统在事务日志方面的扩展性和处理性能。

Description

日志数据处理方法及装置

【技术领域】

本申请涉及数据库技术领域，尤其涉及一种日志数据处理方法及装置。

【背景技术】

事务日志是数据库的重要部分之一，主要是记录与其对应数据库上的事务行为和对数据库修改的日志文件。数据库利用事务日志可以确保持久性(Durability)和事务回滚(Rollback)等特性。在现有技术中，为了保证事务能够按照提交顺序串行执行，采用单机队列对事务日志进行管理，以通过事务日志的先进先出来保证事务串行执行。

对于分布式数据库系统来说，由于单机队列不支持并行写入事务日志，因此各应用服务器需要排队等待事务日志的写入，在扩展性和处理性能上会受限制。但是，就目前技术来说，为了保证事务按照提交顺序串行执行，分布式数据库系统也不得不采用单机队列，面临单机队列瓶颈。

【发明内容】

本申请的多个方面提供一种日志数据处理方法及装置，用以解决分布式数据库系统在事务日志管理方面面临的单机队列瓶颈，提高分布式数据库系统在事务日志方面的扩展性和和性能。

本申请的一方面，提供一种日志数据处理方法，包括：

接收应用服务器的事务提交请求；

从至少两个日志队列中选择目标日志队列；

将所述事务提交请求对应的事务日志写入所述目标日志队列。

在本申请的一可选实施方式中，所述从至少两个日志队列中选择目标日志队列，包括：

随机从所述至少两个日志队列中选择一个日志队列作为所述目标日志队列。

在本申请的一可选实施方式中，所述事务日志在所述目标日志队列中的前一个对象为所述目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签，或者为在同一所述时间间隔内上一时刻写入的事务日志。

本申请的另一方面，提供一种日志数据处理方法，包括：

按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志；

根据所述事务日志，执行数据库操作。

在本申请的一可选实施方式中，所述按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志，包括：

按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志；每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

在本申请的一可选实施方式中，所述按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志，包括：

判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照所述日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照所述日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作。

本申请的又一方面，提供一种日志数据处理装置，包括：

接收模块，用于接收应用服务器的事务提交请求；

选择模块，用于从至少两个日志队列中选择目标日志队列；

写入模块，用于将所述事务提交请求对应的事务日志写入所述目标日志队列。

在本申请的一可选实施方式中，所述选择模块具体用于：

随机从所述至少两个日志队列中选择一个日志队列作为所述目标日志队列。

在本申请的一可选实施方式中，所述事务日志在所述目标日志队列中的前一个对象为所述目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签，或者为在同一所述时间间隔内上一时刻写入的事务日志。

本申请的又一方面，提供一种日志数据处理装置，包括：

读取模块，用于按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志；

执行模块，用于根据所述事务日志，执行数据库操作。

在本申请的一可选实施方式中，所述读取模块具体用于：

按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志；每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

在本申请的一可选实施方式中，所述读取模块具体用于：

判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照所述日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照所述日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作。

在本申请中，用多日志队列来存储事务日志，允许事务日志的并行写入，在读事务日志时，通过指定日志队列的读取顺序，结合事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志，用以保证事务日志在出队时的顺序性和确定性，满足数据库对事务日志的基本需求，同时解决了分布式数据库系统在事务日志管理方面面临的单机队列瓶颈，提高了分布式数据库系统在事务日志方面的扩展性和处理性能。

【附图说明】

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的日志数据处理方法的流程示意图；

图2为本申请一实施例提供的分布式数据库系统中应用服务器提交事务的示意图；

图3a为本申请一实施例提供的日志服务器集群的结构示意图；

图3b为本申请一实施例提供的日志服务器存储事务日志的状态示意图；

图4为本申请另一实施例提供的日志数据处理方法的流程示意图；

图5为本申请一实施例提供的日志数据处理装置的结构示意图；

图6为本申请另一实施例提供的日志数据处理装置的结构示意图。

【具体实施方式】

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，为了保证事务按照提交顺序串行执行，所以无论是单机数据库还是分布式数据库系统只能采用单机队列来管理事务日志，以通过事务日志的先进先出特性保证事务按照提交顺序串行执行。以单机队列来管理事务日志，由于不支持并行写入事务日志，因此成为分布式数据库系统的核心瓶颈，导致扩展性和处理性能下降。

针对上述问题，本申请发明人从不同于传统观念的角度重新对事务排队进行理解。具体的，发明人发现事务日志的提交顺序不一定是事务实际产生的先后顺序，例如由于网络等原因可能导致先产生的事务反而后提交而后产生的事务反而先提交。基于这种发现，发明人认为事务日志的入队操作实际上是一个乱序的写队列操作。如果从这个角度来看，意味着无需保证事务日志的入队顺序。但是，仍需保证事务出队的顺序性和确定性，以满足事务顺序执行的基本需求。

正是基于上述发现，本申请提出了以多队列对事务日志进行管理的方案，实现对单队列方案的扩展。在多队列方案中，无需保证事务日志的入队顺序，允许并行写入事务日志，而在事务日志出队列时采用一定方式可以保证其顺序性和确定性。多队列方案尤其适用于分布式数据库系统，在事务日志入队时，允许其并行写入，一定程度上可以解决应用服务器等待事务日志入队的问题，发挥并发处理的优势，而在事务日志出队列是又可以保证其顺序性和确定性，可以满足其对事务日志的基本需求，可以解决分布式数据库系统面临的单机队列瓶颈，提高分布式数据库系统的扩展性和处理性能。

本申请以下方法实施例将分别从事务日志入队列的角度和事务日志出队列的角度详细说明本申请技术方案的实施流程。

图1为本申请一实施例提供的日志数据处理方法的流程示意图。如图1所示，该方法包括：

101、接收应用服务器的事务提交请求。

102、从至少两个日志队列中选择目标日志队列。

103、将事务提交请求对应的事务日志写入目标日志队列。

本实施例提供的日志数据处理方法可由日志数据处理装置来执行，主要描述事务日志入队列的过程。本实施例的事务日志可以是WAL(Write-AheadLogging)日志，但不限于此。

具体的，应用服务器(或者俗称为事务端)需要以事务形式对数据库进行操作时，会产生事务日志，该事务日志主要记录与该事务日志对应数据库上的事务行为和对数据库的修改等信息。此时，应用服务器需要向日志数据处理装置发出事务提交请求。对日志数据处理装置来说，可以接收应用服务器发出的事务提交请求，根据该事务提交请求获知该应用服务器需要向日志队列中写入事务日志，于是从至少两个日志队列中选择目标日志队列，之后将事务提交请求对应的事务日志写入目标日志队列中。其中，事务提交请求会携带与应用服务器以及当前事务有关的信息，例如事务id、应用服务器id等。

在一可选实施方式中，日志数据处理装置可以随机从至少两个日志队列中选择一个日志队列作为目标日志队列，这种实现方式更加简单，效率更高。或者，也可以预先设定的日志队列使用策略，例如循环使用策略。基于此，日志数据处理装置可以按照预设的日志队列使用策略，选择相应的日志队列(例如被循环到的日志队列)作为目标日志队列。

对于分布式数据库系统来说，一般会有多个应用服务器。在同一时间，可能会有多个应用服务器同时发出事务提交请求。在本实施例中，由于采用至少两个日志队列，所以日志数据处理装置在接收到多个事务提交请求的情况下，可以将不同应用服务器的事务日志分配到至少两个日志队列中，而不用像现有技术中那样需要排队等待写入同一日志队列中。举例说明，假设一共有3个日志队列，同时有2个应用服务器发出事务提交请求，则可以直接将这2个应用服务器的事务日志写入其中任意2个日志队列中，这2个事务日志都不需要排队等待，可以同时并发写入2个事务日志。又例如，假设共有3个日志队列，同时有4个应用服务器发出事务提交请求，则可以将这4个应用服务器的事务日志分配到这3个日志队列中，其中有2个事务日志需要分配到相同日志队列中，则只有这2个分配到同一日志队列的事务日志中的一个需要等待另一个写入之后再行写入，另外2个事务日志不需要等待，可以同时并发写入3个事务日志。由此可见，本实施例通过采用多日志队列，可以并发写入多个事务日志，减少或避免事务日志写入日志队列过程中的等待时间，有利于提高在事务日志方面的扩展性和处理性能。

值得说明的是，在部署实现上，本实施例的至少两个日志队列可以分别部署于不同的服务器上实现，也就是说，一个日志队列单独部署于一台服务器上；或者，也可以是服务器的数量少于日志队列的数量，至少两个日志队列均分到这几台服务器上；或者，也可以是所有日志队列同时部署于一台服务器上。

在一可选实施方式中，为了给后续出队列操作提供便利条件，日志队列所在服务器可以按照指定时间间隔定期向日志队列中插入逻辑时间标签，可记为epoch。所有日志队列所在服务器均按照相同时间间隔定期向日志队列插入逻辑时间标签，这样所有日志队列中相同逻辑时间标签对应相同时间段。通过该逻辑时间标签可以标记各日志队列中同一时间段内插入的事务日志。

基于上述逻辑时间标签，则日志数据处理装置写入目标日志队列中的事务日志的前一个对象可以是在同一时间间隔内上一时刻写入的事务日志，或者是目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签。

下面结合具体应用场景说明向至少两个日志队列写入事务日志的过程。

如图2所示，假设分布式数据库系统包括4个应用服务器，分别是第一应用服务器、第二应用服务器、第三应用服务器和第四应用服务器；第一应用服务器产生2个事务，分别是事务0和事务1；第二应用服务器产生2个事务，分别是事务2和事务3；第三应用服务器产生2个事务，分别是事务4和事务5；第四应用服务器产生2个事务，分别是事务6和事务7。

如图3a所示，本实施例至少两个日志队列具体为3个，形成一日志队列集群，集群中的每个日志队列分别部署于第一日志服务器、第二日志服务器和第三日志服务器上。每台日志服务器会每隔n个ms向日志队列中插入一个逻辑时间标签，逻辑时间标签的序号从0开始自增。

日志数据处理装置接收图2中应用服务器发出的事务提交请求，根据请求将相应事务的事务日志随机写入图3a所示日志服务器中的日志队列中，最终结果如图3b所示。在事务日志写入日志队列的过程中，不需要保证写入顺序，通过多个日志队列实现并行写入，使得事务日志的写入操作更加灵活方便。

图4为本申请另一实施例提供的日志数据处理方法的流程示意图。如图4所示，该方法包括：

401、按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志。

402、根据上述事务日志，执行数据库操作。

本实施例提供的日志数据处理方法可由日志数据处理装置来执行，主要描述事务日志出队列的过程。本实施例的事务日志可以是WAL日志，但不限于此。

日志数据处理装置需要从日志队列中读取事务日志，根据所读取的事务日志执行相应的数据库操作。所述相应的数据库操作可以是插入操作、删除操作、修改操作或查询操作等。其中，根据事务日志执行数据库操作属于现有流程，故本实施例不做详细描述。本实施例重点描述如何在保证顺序性和确定性的情况下从至少两个日志队列中读取事务日志。

具体的，考虑到本实施例具有至少两个日志队列，因此预先指定日志队列的读取顺序，从而从日志队列的维度保证读取的顺序性和确定性。另外，考虑到事务日志存入日志队列的时间有先后，因此还需要从时间维度保证读取的顺序性和确定性。本实施例按照事务日志的存入时间由先到后的顺序，依次读取各时间段内存入的事务日志，从而保证时间维度读取的顺序性和确定性。于是，日志数据处理装置按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志。

在一可选实施方式中，上述时间段可以通过日志队列所在日志服务器按照指定时间间隔定期插入日志队列中的逻辑时间标签来区分，一个逻辑时间标签代表一个时间段。其中，每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

基于上述，日志数据处理装置具体可以按照日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，例如一般是由先到后的顺序，依次从至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志。

结合上述图3b所示场景，假设日志队列的读取顺序为从左到右，即依次是第一日志服务器上的日志队列、第二日志服务器上的日志队列、第三日志服务器上的日志队列；逻辑时间标签的读取顺序依次是epoch0、epoch1。将两个维度的读取顺序进行组合，则可以唯一确定事务日志的读取顺序为：第一日志服务器上的日志队列中epoch0对应的事务日志，第二日志服务器上的日志队列中epoch0对应的事务日志，第三日志服务器上的日志队列中epoch0对应的事务日志，第一日志服务器上的日志队列中epoch1对应的事务日志，第二日志服务器上的日志队列中epoch1对应的事务日志，第三日志服务器上的日志队列中epoch1对应的事务日志。基于该唯一确定的读取顺序所读取的事务日志依次为：事务日志4，事务日志7，事务日志3，事务日志5，事务日志6，事务日志0，事务日志2，事务日志1。

其中，上述按照日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志的过程具体可以是：

判断当前读取的日志队列是否是按照日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照所述日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照日志队列读取顺序应该读取的最后一个日志队列的操作。

例如，假设当前读取到第三日志服务器上的日志队列，第三日志服务器上的日志队列是最后一个日志队列，于是将当前读取的逻辑时间标签epoch0之后的epoch1重新作为当前逻辑时间标签；之后，重新读取第一日志服务器上日志队列中对应于epoch1的事务日志，即事务日志0，事务日志2；然后，判断第一日志服务器上的日志队列是否是最后一个应该读取到的日志队列，判断结果为否，则按照日志队列读取顺序，继续读取第二日志服务器上的日志队列中对应于epoch1的事务日志，即事务日志2；然后，判断第二日志服务器上的日志队列是否是最后一个应该读取到的日志队列，判断结果为否，则按照日志队列读取顺序，继续读取第三日志服务器上的日志队列中对应于epoch1的事务日志，依次执行下去。

虽然上述从日志队列中读取事务日志的顺序与应用服务器提交的事务编号不同，但因为提交事务过程中有网络延迟等不确定因素，所以到达日志队列的顺序本身就是不确定的，而数据库真正需要的是在处理事务日志时要求处理顺序的确定性，所以本实施例提供的方法保证了读取事务日志的顺序性和确定性，满足了数据库对事务日志的基本需求。

基于本申请提供的多日志队列方案，可以随意的增加新的事务日志，从而实现了日志系统的水平扩展能力。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

图5为本申请一实施例提供的日志数据处理装置的结构示意图。如图5所示，该装置包括：接收模块51、选择模块52和写入模块53。

接收模块51，用于接收应用服务器的事务提交请求。

选择模块52，用于从至少两个日志队列中选择目标日志队列。

写入模块53，用于将事务提交请求对应的事务日志写入目标日志队列。

本实施例的事务日志可以是WAL日志，但不限于此。

在一可选实施方式中，选择模块52具体可用于：随机从上述至少两个日志队列中选择一个日志队列作为目标日志队列。

在一可选实施方式中，上述事务日志在目标日志队列中的前一个对象为目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签，或者为在同一时间间隔内上一时刻写入的事务日志。

本实施例提供的日志数据处理装置，通过采用多日志队列，在事务日志写入日志队列的过程中，不需要保证写入顺序，通过多个日志队列实现并行写入，使得事务日志的写入操作更加灵活方便，减少或避免事务日志写入日志队列过程中的等待时间，有利于提高在事务日志方面的扩展性和处理性能。

图6为本申请另一实施例提供的日志数据处理装置的结构示意图。如图6所示，该装置包括：读取模块61和执行模块62。

读取模块61，用于按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志。

执行模块62，用于根据读取模块61读取的事务日志，执行数据库操作。

本实施例的事务日志可以是WAL日志，但不限于此。

在一可选实施方式中，读取模块61具体用于：

按照日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志；每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

在一可选实施方式中，读取模块61具体用于：

判断当前读取的日志队列是否是按照日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作。

本实施例提供的日志数据处理装置，与上述实施例提供的日志数据处理装置相配合，在读事务日志时，通过指定日志队列的读取顺序，结合事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志，用以保证事务日志在出队时的顺序性和确定性，满足数据库对事务日志的基本需求，同时解决了分布式数据库系统在事务日志管理方面面临的单机队列瓶颈，提高了分布式数据库系统在事务日志方面的扩展性和处理性能。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种日志数据处理方法，其特征在于，包括：

接收应用服务器的事务提交请求；

从至少两个日志队列中选择目标日志队列；

将所述事务提交请求对应的事务日志写入所述目标日志队列。

2.根据权利要求1所述的方法，其特征在于，所述从至少两个日志队列中选择目标日志队列，包括：

随机从所述至少两个日志队列中选择一个日志队列作为所述目标日志队列。

3.根据权利要求1或2所述的方法，其特征在于，所述事务日志在所述目标日志队列中的前一个对象为所述目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签，或者为同一所述时间间隔内上一时刻写入的事务日志。

4.一种日志数据处理方法，其特征在于，包括：

按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志；

根据所述事务日志，执行数据库操作。

5.根据权利要求4所述的方法，其特征在于，所述按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志，包括：

按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志；每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

6.根据权利要求5所述的方法，其特征在于，所述按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志，包括：

判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照所述日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照所述日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作。

7.一种日志数据处理装置，其特征在于，包括：

接收模块，用于接收应用服务器的事务提交请求；

选择模块，用于从至少两个日志队列中选择目标日志队列；

写入模块，用于将所述事务提交请求对应的事务日志写入所述目标日志队列。

8.根据权利要求7所述的装置，其特征在于，所述选择模块具体用于：

随机从所述至少两个日志队列中选择一个日志队列作为所述目标日志队列。

9.根据权利要求7或8所述的装置，其特征在于，所述事务日志在所述目标日志队列中的前一个对象为所述目标日志队列所在日志服务器按照指定时间间隔定期插入的逻辑时间标签，或者为在同一所述时间间隔内上一时刻写入的事务日志。

10.一种日志数据处理装置，其特征在于，包括：

读取模块，用于按照指定的日志队列读取顺序和事务日志的存入时间，依次读取在每个时间段内存入至少两个日志队列中每个日志队列中的事务日志；

执行模块，用于根据所述事务日志，执行数据库操作。

11.根据权利要求10所述的装置，其特征在于，所述读取模块具体用于：

按照所述日志队列读取顺序和日志队列中逻辑时间标签的插入顺序，依次从所述至少两个日志队列中每个日志队列中读取对应于同一逻辑时间标签的事务日志；每个日志队列中的逻辑时间标签是每个日志队列所在日志服务器按照相同时间间隔定期插入每个日志队列中的。

12.根据权利要求11所述的装置，其特征在于，所述读取模块具体用于：

判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列；

若判断结果为是，将在当前逻辑时间标签之后第一个插入的逻辑时间标签重新确定为当前逻辑时间标签，并按照所述日志队列读取顺序，读取第一个日志队列中对应于所述重新确定的当前逻辑时间标签的事务日志，并继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作；

若判断结果为否，按照所述日志队列读取顺序继续读取下一个日志队列中对应于当前逻辑时间标签的事务日志，并返回继续执行判断当前读取的日志队列是否是按照所述日志队列读取顺序应该读取的最后一个日志队列的操作。