CN107301178A - 数据查询处理方法、装置及系统 - Google Patents

Abstract

本申请实施例提供了一种数据查询处理方法、装置及系统，该方法包括：第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；所述每个指定的第二服务器根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。本申请实施例可提高数据查询处理的效率。

Description

数据查询处理方法、装置及系统

技术领域

本申请涉及数据库数据处理技术领域，尤其是涉及一种数据查询处理方法、装置及系统。

背景技术

在一些系统中，往往存在大量定时处理任务，这些定时处理任务一般情况下是由单机(即单个服务器)来完成的。而随着业务量的不断增长，其中有些系统往往面临的是，大量的甚至是海量的定时数据查询任务，因此即使是高性能的单机，可能也无法及时消化这些定时数据查询任务，从而容易导致业务积压。因此，现有的基于单机的数据查询处理方式的处理效率较低，严重影响系统的正常运行。

发明内容

本申请实施例的目的在于提供一种数据查询处理方法、装置及系统，以提高数据查询处理的效率。

为达到上述目的，一方面，本申请实施例提供了一种数据查询处理方法，包括以下步骤：

第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

所述每个指定的第二服务器根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

另一方面，本申请实施例还提供一种数据查询处理方法，包括以下步骤：

第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

再一方面，本申请实施例还提供了一种数据查询处理方法，包括以下步骤：

第二服务器接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

所述第二服务器根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

再一方面，本申请实施例还提供了一种数据查询处理系统，包括：

第一服务器，用于在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

多个第二服务器，用于根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

再一方面，本申请实施例还提供了一种数据查询处理服务器，包括：

任务执行确认模块，用于在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

查询任务分配模块，用于当所述任务执行确认模块确认当前需要执行所述预设查询任务时，向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

再一方面，本申请实施例还提供了另一种数据查询处理服务器，包括：

任务消息接收模块，用于接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

查询结果获取模块，用于根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

与现有技术相比，本申请实施例基于消息驱动的方式驱动第一服务器，第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则该第一服务器向每个指定的第二服务器发送一个任务分配消息，其中，每个任务分配消息中携带有预设查询任务的任务参数，任务参数包括分库分表位分组标识；每个指定的第二服务器则根据任务参数并行查询相应的分库分表位，获得对应的查询结果，从实现了利用服务器集群的能力高效处理定时数据查询任务。

附图说明

此处所说明的附图用来提供对本申请实施例的进一步理解，构成本申请实施例的一部分，并不构成对本申请实施例的限定。在附图中：

图1为本申请一实施例的数据查询处理方法的流程图；

图2为本申请另一实施例的数据查询处理方法的流程图；

图3为本申请另一实施例的数据查询处理方法的流程图；

图4为本申请一实施例的数据查询处理方法中的查询步骤的详细流程图；

图5为本申请实施例的数据查询处理系统的结构示意图；

图6为本申请一实施例的数据查询处理服务器的结构框图；

图7为本申请另一实施例的数据查询处理服务器的结构框图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本申请实施例做进一步详细说明。在此，本申请实施例的示意性实施例及其说明用于解释本申请实施例，但并不作为对本申请实施例的限定。

下面结合附图，对本申请实施例的具体实施方式作进一步的详细说明。

参考图1所示，本申请实施例的数据查询处理方法包括以下步骤：

步骤S101、第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个。

在本申请实施例中，所述驱动消息用以定时触发第一服务器。此外，所述从指定的多个第一服务器预均设有相同的查询任务，且用于判断当前是否需要执行预设查询任务的预设规则也相同，所述任务调度中心每次需要发送驱动消息时，会从这些指定的多个第一服务器随机选取一个作为发送对象。需要说明的是，本申请实施例中的每个第一服务器并非专门用于实现本申请的，这些第一服务器在未收到驱动消息时，可以用于执行别的任务。

在本申请实施例中，设置有多个第一服务器的目的在于保障系统的稳定性，一旦发现被选中的那个宕机或故障，任务调度中心还可以重新从其他第一服务器中再随机选择一个。此外，每次发送时，任务调度中心从指定的多个第一服务器随机选取一个(而不是群发)作为发送对象的目的在于：防止多个第一服务器同时检测同一个查询任务的周期是否到来而出现冲突。

在本申请实施例中，所述预设查询任务可以为预先配置好的定时查询任务，在本申请一个实施例中，预先配置好的定时查询任务可以保存在第一服务器上，以方便第一服务器在需要时获取。

在本申请实施例中，预先配置好的定时查询可以为一个或多个，当多个时，每个定时查询任务的查询周期可以如表1所示：

表1

任务	A	B	C	D
					查询周期	1分钟	2分钟	3分钟	4分钟

当收到驱动消息后，第一服务器就会根据预设规则判断当前是否需要执行预设查询任务。比如所述第一服务器逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。如果检查时发现有预设查询任务的查询周期到来，则执行步骤S102。

此外，在逐一检查完每个预设查询任务的查询周期是否到来并根据判断结果执行了相应的动作(比如发送任务分配消息)后，第一服务器结束检查，待到下一个驱动消息到来时，会再次执行上述检查，因此，第一服务器每收到一个驱动消息就会执行一次上述检查，并根据判断结果执行相应的动作。

步骤S102、所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

在本申请实施例中，一般的，所述任务参数除包括分库分表位分组标识外，还包括任务类型、以及执行任务需要的其他一系列参数等。其中，所述分库分表位分组标识例如可以为分库分表位的分组标识UID(unit identifer)，见下表2的第一行。

在本申请实施例中，第一服务器可同时向每个指定的第二服务器一个任务分配消息，以利用服务器集群的处理能力并行处理一个查询任务，从而提高查询效率。其中，每个第二服务器被分配的可以是同一个查询任务的一个子任务。举例来说，一个查询任务需要查询00-899个分库分表位，而这些分库分表位可以预先根据第二服务器的数量(9个，rz01-rz09)被划分为9个组(001-009)，则每个组可由一个第二服务器负责查询，如下表2所示：

表2

由此，每个第二服务器对应查询哪些分库分表位是预定好的。因此，根据任务参数中携带的分库分表位分组标识的不同，任务分配消息可以被路由至不同的第二服务器。当然，在本申请另一实施例中，查询任务也可通过其他形式分配给多个第二服务器。

步骤S103、所述每个指定的第二服务器根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

在本申请一实施例中，每个第二服务器可以为单个服务器。如上文所述，每个第二服务器可操作处理哪些分库分表位是预先设置好的(见上表2所示)，比如标识为rz01的第二服务器可以查询00-99的分库分表位。而在本申请另一实施例中，每个第二服务器也可以为多个服务器组成的集群组。比如rz01是由2个服务器(服务器rz01a和服务器rz01b)组成的集群组，那么rz01还可以对查询00-99的分库分表位进行分工，比如由rz01a查询00-49分库分表位，rz01b查询50-99分库分表位。

需要说明的是，为了防止预设查询任务的周期到来时，第一服务器尚未收到驱动消息而导致预设查询任务无法执行，一般的，要求任务调度中心发送的驱动消息的周期要远小于预设查询任务的查询周期，比如预设查询任务的查询周期为1分钟，则驱动消息发送周期可以为1秒。此外，为了防止第二服务器在尚未处理完一个第一服务器下发的预设查询任务时，又收到了另一个第一服务器下发的同样的预设查询任务，从而引起冲突，因此，要求预设查询任务的查询周期要大于第二服务器处理完该预设查询任务所需的时间。比如第二服务器处理完一次A任务的查询需要耗时1分钟，则该A任务的查询周期应大于1分钟，具体实现时，可依据经验或通过测试方式来合理设置预设查询任务的查询周期。

与现有技术相比，本申请实施例基于消息驱动的方式驱动第一服务器，第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则该第一服务器向每个指定的第二服务器发送一个任务分配消息，其中，每个任务分配消息中携带有预设查询任务的任务参数，任务参数包括分库分表位分组标识；每个指定的第二服务器则根据任务参数并行查询相应的分库分表位，获得对应的查询结果，从实现了利用服务器集群的能力高效处理定时数据查询任务。

参考图2所示，本申请实施例的数据查询处理方法包括以下步骤：

步骤S201，第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个。

在本申请实施例中，所述驱动消息用以定时触发第一服务器。此外，所述从指定的多个第一服务器预均设有相同的查询任务，且用于判断当前是否需要执行预设查询任务的预设规则也相同，所述任务调度中心每次需要发送驱动消息时，会从这些指定的多个第一服务器随机选取一个作为发送对象。需要说明的是，本申请实施例中的每个第一服务器并非专门用于实现本申请的，这些第一服务器在未收到驱动消息时，可以用于执行别的任务。

在本申请实施例中，设置有多个第一服务器的目的在于保障系统的稳定性，一旦发现被选中的那个宕机或故障，任务调度中心还可以重新从其他第一服务器中再随机选择一个。此外，每次发送时，任务调度中心从指定的多个第一服务器随机选取一个(而不是群发)作为发送对象的目的在于：防止多个第一服务器同时检测同一个查询任务的周期是否到来而出现冲突。

在本申请实施例中，所述预设查询任务可以为预先配置好的定时查询任务，在本申请一个实施例中，预先配置好的定时查询任务可以保存在第一服务器上，在本申请另一实施例中，预先配置好的定时查询任务可以保存在第一服务器上，以方便第一服务器在需要时获取。

在本申请实施例中，预先配置好的定时查询可以为一个或多个，当多个时，每个定时查询任务的查询周期可以如下表3所示：

表3

任务	A	B	C	D
					查询周期	1分钟	2分钟	3分钟	4分钟

当收到驱动消息后，第一服务器就会根据预设规则判断当前是否需要执行预设查询任务。比如所述第一服务器逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。如果检查时发现有预设查询任务的查询周期到来，则执行步骤S202。

此外，在逐一检查完每个预设查询任务的查询周期是否到来并根据判断结果执行了相应的动作(比如发送任务分配消息)后，第一服务器结束检查，待到下一个驱动消息到来时，会再次执行上述检查，因此，第一服务器每收到一个驱动消息就会执行一次上述检查，并根据判断结果执行相应的动作。

步骤S202，如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

在本申请实施例中，一般的，所述任务参数除包括分库分表位分组标识外，还包括任务类型、以及执行任务需要的其他一系列参数等。其中，所述分库分表位分组标识例如可以为分库分表位的分组标识UID，见下表4的第一行。

在本申请实施例中，第一服务器可同时向每个指定的第二服务器一个任务分配消息，以利用服务器集群的处理能力并行处理一个查询任务，从而提高查询效率。其中，每个第二服务器被分配的可以是同一个查询任务的一个子任务。举例来说，一个查询任务需要查询00-899个分库分表位，而这些分库分表位可以预先根据第二服务器的数量(9个，rz01-rz09)被划分为9个组(001-009)，则每个组可由一个第二服务器负责查询，如下表4所示：

表4

由此，每个第二服务器对应查询哪些分库分表位是预定好的。因此，根据任务参数中携带的分库分表位分组标识的不同，任务分配消息可以被路由至不同的第二服务器。当然，在本申请另一实施例中，查询任务也可通过其他形式分配给多个第二服务器。

需要说明的是，为了防止预设查询任务的周期到来时，第一服务器尚未收到驱动消息而导致预设查询任务无法执行，一般的，要求任务调度中心发送的驱动消息的周期要远小于预设查询任务的查询周期，比如预设查询任务的查询周期为1分钟，则驱动消息发送周期可以为1秒。此外，为了防止第二服务器在尚未处理完一个第一服务器下发的预设查询任务时，又收到了另一个第一服务器下发的同样的预设查询任务，从而引起冲突，因此，要求预设查询任务的查询周期要大于第二服务器处理完该预设查询任务所需的时间。比如第二服务器处理完一次A任务的查询需要耗时1分钟，则该A任务的查询周期应大于1分钟，具体实现时，可依据经验或通过测试方式来合理设置预设查询任务的查询周期。

与现有技术相比，本申请实施例基于消息驱动的方式驱动第一服务器，第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则该第一服务器向每个指定的第二服务器发送一个任务分配消息，其中，每个任务分配消息中携带有预设查询任务的任务参数，任务参数包括分库分表位分组标识；每个指定的第二服务器则根据任务参数并行查询相应的分库分表位，获得对应的查询结果，从实现了利用服务器集群的能力高效处理定时数据查询任务。

参考图3所示，本申请实施例的数据查询处理方法包括以下步骤：

步骤S301，第二服务器接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

在本申请实施例中，一般的，所述任务参数除包括分库分表位分组标识外，还包括任务类型、以及执行任务需要的其他一系列参数等。其中，所述分库分表位分组标识例如可以为分库分表位的分组标识UID，见下表5的第一行。

步骤S302，所述第二服务器根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

在本申请实施例中，第一服务器可同时向每个指定的第二服务器一个任务分配消息，以利用服务器集群的处理能力并行处理一个查询任务，从而提高查询效率。其中，每个第二服务器被分配的可以是同一个查询任务的一个子任务。举例来说，一个查询任务需要查询00-899个分库分表位，而这些分库分表位可以预先根据第二服务器的数量(9个，rz01-rz09)被划分为9个组(001-009)，则每个组可由一个第二服务器负责查询，如下表5所示：

表5

由此，每个第二服务器对应查询哪些分库分表位是预定好的。因此，根据任务参数中携带的分库分表位分组标识的不同，任务分配消息可以被路由至不同的第二服务器。当然，在本申请另一实施例中，查询任务也可通过其他形式分配给多个第二服务器。

在本申请一实施例中，每个第二服务器可以为单个服务器。如上文所述，每个第二服务器可操作处理哪些分库分表位是预先设置好的(见上表5所示)，比如标识为rz01的第二服务器可以查询00-99的分库分表位。而在本申请另一实施例中，每个第二服务器也可以为多个服务器组成的集群组。比如rz01是由2个服务器(服务器rz01a和服务器rz01b)组成的集群组，那么rz01还可以对查询00-99的分库分表位进行分工，比如由rz01a查询00-49分库分表位，rz01b查询50-99分库分表位。

需要强调的是，对于每个第二服务器而言，为防止一次查询的数据量过大而导致内存溢出，可以根据任务参数并按照预设步进量分批次查询对应的分库分表位，所述预设步进量比如可以为一页数据，所述一页数据的数据量为定值。比如一个第二服务器当前要查询的分库分表位有50000条记录，如果一次将50000条记录全部捞出则很有可能导致内存溢出，而如果50000条记录拆分成100份(其中100份可以是100页(page))，每份500条，由于每次仅仅查询500条，从而避免了内存溢出的风险。当然有时候，第二服务器可能预先并不知道所要查询的数据量具体有多大，无法预设查询次数。但在分批次查询时，依然可根据经验值设置每批次的查询量(比如上述提到的每次查询500条)，直至将该分库分表内的所有纪录全部查询完为止，同样可以免内存溢出的风险。在本申请实例一个具体实施例中，当数据量由于业务原因突然加大时，原来的初始值不再满足业务处理需要，则可以通过drm(distributed resourcemanagement，分布式资源管理)平台动态调整系统初始值(比如所述步进量的初始值)。

在本申请另一实例中，所述预设查询任务可以为定时查询任务，所述第二服务器每次查询的起始时间为：上一次查询的终止时间基础上提前预设偏移时长所对应的时间，以保证查询结果的完整性。：上一次查询的终止时间基础上提前预设偏移时长所对应的时间，以保证查询结果的完整性。比如上一次查询的终止时间为12:00，预设偏移时长为1分钟，则本次查询的起始时间为11:59，即比上一次查询的终止时间提前一分钟。在本申请实例一个具体实施例中，当数据量由于业务原因突然加大时，原来的初始值不再满足业务处理需要，则可以通过drm平台动态调整系统初始值(比如所述预设偏移时长的初始值)。

在本申请的一个具体实施例中，上述分批次查询的具体过程可如图4所示，在一个场景下，sql(structured query language)的起始时间可以为上一次的执行截止时间，通过增加for循环逻辑，可以分批次的捞取，直至捞取完成后返回结果为空时终止循环。其中，count为查询批次，count＝perSelectNum；from为查询范围，from＝page*perSelectNum；now为当前时间，用于标记查询截止时间。

需要说明的是，以上实施例已经说明通过drm平台可动态调整系统初始值，其中，可调整的范围并不局限于上述的步进量、预设偏移时长，比如还可以是定时任务的间隔时长等等。

需要说明的是，为了防止第二服务器在尚未处理完一个第一服务器下发的预设查询任务时，又收到了另一个第一服务器下发的同样的预设查询任务，从而引起冲突，因此，要求预设查询任务的查询周期要大于第二服务器处理完该预设查询任务所需的时间。比如第二服务器处理完一次A任务的查询需要耗时1分钟，则该A任务的查询周期应大于1分钟，具体实现时，可依据经验或通过测试方式来合理设置预设查询任务的查询周期。

与现有技术相比，本申请实施例基于消息驱动的方式驱动第一服务器，第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则该第一服务器向每个指定的第二服务器发送一个任务分配消息，其中，每个任务分配消息中携带有预设查询任务的任务参数，任务参数包括分库分表位分组标识；每个指定的第二服务器则根据任务参数并行查询相应的分库分表位，获得对应的查询结果，从实现了利用服务器集群的能力高效处理定时数据查询任务。

虽然上文实施例描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

参考图5所示，本申请实施例的数据查询处理系统包括：

第一服务器，用于在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

多个第二服务器，用于根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

在本申请另一实施例中，数据查询处理系统还可以包括：

任务调度中心，用于定时向指定的第一服务器发送驱动消息，以定时驱动所述第一服务器。

结合图6所示，其中第一服务器包括：

任务执行确认模块61，用于在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

查询任务分配模块62，用于当所述任务执行确认模块61确认当前需要执行所述预设查询任务时，向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

上述第一服务器中各模块的具体细节，请参见对应方法实施例中的步骤S201-步骤S202，在此不再赘述。

结合图7所示，其中每个所述第二服务器包括：

任务消息接收模块71，用于接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

查询结果获取模块72，用于根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

上述第二服务器中各模块的具体细节，请参见对应方法实施例中的步骤S301-步骤S302，在此不再赘述。

与现有技术相比，本申请实施例基于消息驱动的方式驱动第一服务器，第一服务器在获取到任务调度中心定时发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则该第一服务器向每个指定的第二服务器发送一个任务分配消息，其中，每个任务分配消息中携带有预设查询任务的任务参数，任务参数包括分库分表位分组标识；每个指定的第二服务器则根据任务参数并行查询相应的分库分表位，获得对应的查询结果，从实现了利用服务器集群的能力高效处理定时数据查询任务。

本领域技术人员还可以了解到本申请实施例列出的各种说明性逻辑块、单元和步骤可以通过硬件、软件或两者的结合来实现。至于是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本申请实施例保护的范围。

本申请实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本申请实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施例，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请实施例的具体实施例而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (20)

1.一种数据查询处理方法，其特征在于，包括以下步骤：

第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

所述每个指定的第二服务器根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

2.根据权利要求1所述的数据查询处理方法，其特征在于，所述第一服务器根据预设规则判断是否需要执行预设查询任务，包括：

所述第一服务器逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。

3.一种数据查询处理方法，其特征在于，包括以下步骤：

第一服务器在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

如果需要，则所述第一服务器向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

4.根据权利要求3所述的数据查询处理方法，其特征在于，所述第一服务器根据预设规则判断是否需要执行预设查询任务，包括：

所述第一服务器逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。

5.一种数据查询处理方法，其特征在于，包括以下步骤：

第二服务器接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

所述第二服务器根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

6.根据权利要求5所述的数据查询处理方法，其特征在于，还包括：

所述预设查询任务为定时查询任务，所述第二服务器每次查询的起始时间为：上一次查询的终止时间基础上提前预设偏移时长所对应的时间，以保证查询结果的完整性。

7.根据权利要求6所述的数据查询处理方法，其特征在于，所述的预设偏移时长通过分布式资源管理drm平台动态调整。

8.根据权利要求5所述的数据查询处理方法，其特征在于，所述第二服务器根据所述任务参数查询相应的分库分表位，包括：

所述第二服务器根据所述任务参数并按照预设步进量分批次查询对应的分库分表位。

9.根据权利要求8所述的数据查询处理方法，其特征在于，所述预设步进量包括一页数据，所述一页数据的数据量为定值。

10.根据权利要求8或9所述的数据查询处理方法，其特征在于，所述步进量预先通过drm平台动态调整。

11.一种数据查询处理系统，其特征在于，包括：

第一服务器，用于在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；如果需要，则向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

多个第二服务器，用于根据所述任务参数并行查询相应的分库分表位，获得对应的查询结果。

12.根据权利要求11所述的数据查询处理系统，其特征在于，所述第一服务器根据预设规则判断是否需要执行预设查询任务，包括：

所述第一服务器逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。

13.一种数据查询处理服务器，其特征在于，包括：

任务执行确认模块，用于在获取到任务调度中心发送的驱动消息时，根据预设规则判断当前是否需要执行预设查询任务，所述第一服务器为所述任务调度中心从指定的多个第一服务器中选取的一个；

查询任务分配模块，用于当所述任务执行确认模块确认当前需要执行所述预设查询任务时，向每个指定的第二服务器发送一个任务分配消息，每个所述任务分配消息中携带有所述预设查询任务的任务参数，所述任务参数包括分库分表位分组标识。

14.根据权利要求13所述的数据查询处理服务器，其特征在于，所述任务执行确认模块根据预设规则判断是否需要执行预设查询任务，包括：

所述任务执行确认模块逐一检查每个预设查询任务的查询周期是否到来，以判断当前是否需要执行该预设查询任务。

15.一种数据查询处理服务器，其特征在于，包括：

任务消息接收模块，用于接收第一服务器发送的任务分配消息，所述任务分配消息中携带有预设查询任务的任务参数，所述任务参数包括分库分表位分组标识；

查询结果获取模块，用于根据所述任务参数查询相应的分库分表位，获得对应的查询结果。

16.根据权利要求15所述的数据查询处理服务器，其特征在于，还包括：

所述预设查询任务为定时查询任务，所述查询结果获取模块每次查询的起始时间为：上一次查询的终止时间基础上提前预设偏移时长所对应的时间，以保证查询结果的完整性。

17.根据权利要求16所述的数据查询处理服务器，其特征在于，所述的预设偏移时长通过drm平台动态调整。

18.根据权利要求15所述的数据查询处理服务器，其特征在于，所述查询结果获取模块根据所述任务参数查询相应的分库分表位，包括：

所述查询结果获取模块根据所述任务参数并按照预设步进量分批次查询对应的分库分表位。

19.根据权利要求18所述的数据查询处理服务器，其特征在于，所述预设步进量包括一页数据，所述一页数据的数据量为定值。

20.根据权利要求18或19所述的数据查询处理服务器，其特征在于，所述步进量预先通过drm平台动态调整。