数据撮合方法、数据查询方法及装置与流程

本申请涉及数据库技术，特别涉及一种数据撮合方法、数据查询方法及装置。

背景技术：

目前，在诸多场景中均存在将数据进行撮合的需求。一般地，上述数据撮合过程是：根据数据a的特征和数据集Q中每个数据b的特征，将上述数据a逐一与数据b进行匹配。在数据撮合的场景中，一般可以通过执行数据库查询语句的数据库查询动作来得到待处理数据，如：通过SQL(Structured Query Language，结构化查询语言)进行查询。现有技术中，应用于数据撮合场景中的数据库查询方式主要包括全量查询方式和分页查询方式。

全量查询方式一般通过执行一次SQL语句的查询动作，得到包含符合查询语句的所有待撮合数据的结果集，最终将结果集中的所有待撮合数据一次性写入到计算机内存中，并逐一将待撮合数据与目标数据进行撮合。然而，由于计算机的内存容量有限，上述全量查询方式一般容易导致计算机的内存溢出。

分页查询方式则可以避免计算机内存溢出的问题。在分页查询方式中，通过执行SQL语句的查询动作，将查询得到的结果集进行分页(即每页包含一定数量的待撮合数据)，这样，数据库端可以每次只将一页内的待撮合数据返回给应用服务器，并由应用服务器基于上述一页的待撮合数据，进行与目标数据的撮合，从而避免一次性返回过多数据而可能导致应用服务器的内存溢出的问题。在现有的分页查询方式中，在数据库端将查询得到的结果集中的第x页内(x≥1)的k(k≥1)条待撮合数据返回到应用服务器之后，数据库端与应用服务器间的连接便被释放了，此后，需要再次连接数据库端并执行相同的SQL语句的查询动作，并将查询到的结果集中的x+1页内的k条待撮合数据返回到应用服务器，直至将所有页的待撮合数据返回完毕。可见，现有的分页查询方式必须需要多次连接数据库并发送相应的SQL语句，并通过每次查询返回一页内的待撮合数据，才能避免数据查询过程中一次性返回过多待撮合数据，而可能导致的应用服务器的内存溢出问题。然而，多次连接数据库端并执行多次查询动作势必会增加数据库端的负荷。

技术实现要素：

本申请实施例的目的是提供一种数据撮合方法、数据查询方法及装置，以解决现有技术中存在的上述问题。

为解决上述技术问题，本申请各实施例提供的数据撮合方法、数据查询方法及装置是这样实现的：

一种数据撮合方法，包括：

应用服务器向数据库端发送携带查询语句和预设数值M的查询请求；

应用服务器基于数据库端返回的M条待撮合数据，逐一将所述待撮合数据与目标数据进行撮合；所述待撮合数据是数据库端根据所述查询语句查询到的；

若所述目标数据未撮合完毕，应用服务器基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合；1≤N≤M。

一种数据查询方法，包括：

数据库端接收应用服务器发送的携带查询语句和预设数值M的查询请求；

数据库端向应用服务器返回M条待撮合数据；所述待撮合数据是数据库端根据所述查询语句查询到的，所述待撮合数据用于逐一与目标数据进行撮合；

若所述目标数据未撮合完毕，数据库端在向应用服务器返回上述M条待撮合数据之后，向应用服务器返回的处于上述M条待撮合数据之后的N条待撮合数据；1≤N≤M。

一种数据撮合装置，包括：

发送单元，用于向数据库端发送携带查询语句和预设数值M的查询请求；

撮合单元，用于基于数据库端返回的M条待撮合数据，逐一将所述待撮合数据与目标数据进行撮合；所述待撮合数据是数据库端根据所述查询语句查询到的；

所述撮合单元还用于：

若所述目标数据未撮合完毕，基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合；1≤N≤M。

一种数据查询装置，包括：

接收单元，用于接收应用服务器发送的携带查询语句和预设数值M的查询请求；

返回单元，用于向应用服务器返回M条待撮合数据；所述待撮合数据是根据所述查询语句查询到的，所述待撮合数据用于逐一与目标数据进行撮合；

所述返回单元还用于：

若所述目标数据未撮合完毕，在向应用服务器返回上述M条待撮合数据之后，向应用服务器返回的处于上述M条待撮合数据之后的N条待撮合数据；1≤N≤M。

由以上本申请各实施例提供的技术方案可见，本申请实施例中，数据库端通过接收应用服务器发送的携带查询语句和预设数值M的查询请求，并根据该查询请求执行查询动作，得到待撮合数据。在查询得到待撮合数据之后，数据库端根据上述查询请求中的预设数据M，将M条待撮合数据返回到应用服务器并由应用服务器基于这M条待撮合数据进行撮合(待撮合数据与目标数据的撮合)，若上述M条待撮合数据的撮合动作结束之后，应用服务器针对上述目标数据的撮合还没有完毕，则应用服务器可以再基于数据库端在返回上述M条待撮合数据之后返回的N(1≤N≤M)条待撮合数据，逐一进行待撮合数据与目标数据的撮合动作。可以看出，相较于现有技术，首先在数据撮合的过程中，数据库端每次至多向应用服务器返回M条待撮合数据，一般该预设数值M可以根据应用服务器的内存来确定，以确保应用服务器的内存不会溢出。另外，相比于现有技术的分页查询中需要多次发送查询请求，本申请实施例在上述整个撮合过程中，由于应用服务器只向数据库端发送一次查询请求，并在数据查询过程中按照上述预设数值M及应用服务器端的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行返回，从而可以大大缓解数据库端的负荷。

附图说明

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

图1为本申请实施例提供的数据撮合、数据查询方法的流程图；

图2为本申请实施例提供的以应用服务器为主体的数据撮合方法的流程图；

图3为本申请实施例提供的以数据端为主体的数据查询方法的流程图；

图4为本申请实施例提供的数据撮合装置的模块示意图；

图5为本申请实施例提供的数据查询装置的模块示意图。

具体实施方式

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

本申请旨在提出一种应用于数据撮合的场景中的数据撮合方法和数据查询方法，以在避免应用服务器的内存溢出问题的情况下，缓解数据库端的负荷。

图1为本申请实施例提供的数据撮合、数据查询方法的流程，包括：

S101：应用服务器向数据库端发送携带查询语句和预设数值M的查询请求。

本文中的待撮合数据以条来统计，每条待撮合数据可以包含多个特征。

本申请实施例中，应用服务器用以执行将目标数据与一个或多个待撮合数据进行逐一撮合的任务，而数据库端预先存放有若干待撮合数据。其中，所述撮合是根据目标数据的特征与每个待撮合数据的特征，进行目标数据和待撮合数据的匹配。

一般地，在执行数据撮合的过程中，可以根据实际业务需求，从数据库端查询到由符合一定条件的待撮合数据组成的数据集合，并基于该数据集合中的待撮合数据进行撮合任务。则可以利用查询语句来查询得到上述符合一定条件的待撮合数据，所述查询语句可以是SQL语句。本申请实施例中，在应用服务器向数据库端发送查询请求之前，应用服务器可以建立与数据库端的连接(一般，建立连接的过程可以是在应用服务器与数据库端建立一条数据链路，以传递待撮合数据)。数据库端在接收到上述查询请求之后，可以解析该SQL语句并执行相应的数据查询动作。本申请实施例中，可以利用JDBC(Java Data Base CoNNectivity,java数据库连接)来实现数据库查询过程。值得一提的是，一般地，数据库端存储的待撮合数据可以随时间不断变化(如：删除、修改、增加等)。

本申请实施例中，在数据库端查询到的待撮合数据的条数大于上述预设数值M时，数据库端可以将查询到的待撮合数据分多次返回给应用服务器进行撮合。其中，预设数值M可以是数据库端每次至多返回给应用服务器的待撮合数据的条数。一般地，可以根据应用服务器的内存容量，来设定该预设数值M，以确保单次返回给应用服务器的待撮合数据，不会造成应用服务器的内存溢出。在本申请实施例中，可以根据每条待撮合数据平均占用的存储容量大小s，以及上述应用服务器的内存中用以存放待撮合数据的存储空间的总容量t，来确定上述预设数值M(M＝t/s)。

值得述及的是，本申请实施例中，上述待撮合数据可以存放于应用服务器的内存中开辟的I/O缓冲(I/O buffer)区中。应用服务器上用以进行数据撮合的进程可以从上述I/O缓冲区中提取待撮合数据(可以是分批提取)，并将提取的待撮合数据逐一与目标数据进行撮合。则上述预设数值M可以等于上述I/O缓冲区中至多能够存储的待撮合数据的条数(可以通过计算得出)。

S102：数据库端接收查询请求。

S103：数据库端根据查询请求中携带的查询语句，执行查询动作。

本申请实施例中，数据库端的数据查询过程可以为流式查询过程。所谓流式查询过程是：数据库端在查询数据的过程中伴随着将查询到的数据返回到查询请求端(应用服务器)的动作，也就是说，待撮合数据是边查询边返回的。相反地，非流式的查询方式中，数据库端是在查询过程结束后才将查询到的数据返回到查询请求端。例如：在分页查询方式中，当数据库查询过程结束后，才将查询到的结果集中的某一页的数据返回到查询请求端。

S104：数据库端在查询到的M条待撮合数据时，将M条待撮合数据返回至应用服务器，并记录当前已返回的待撮合数据的位置。

在数据库端根据上述查询语句查询待撮合数据的过程中，存在两种情况：①查询到的待撮合数据小于或等于M条；②查询到的待撮合数据大于M条。其中，对于上述情况①，只需要进行一次数据返回动作。而对于上述情况②，则为避免应用服务器的内存溢出，需进行至少两次数据返回动作。

针对上述情况②，由于数据库端需要至少分两次向应用服务器返回查询到的待撮合数据，在前一次返回一定数量(可以是M条)的待撮合数据之后，为确保数据库端在后一次返回数据时，能够确定上一次已返回到哪个数据，需要在每次返回一定数量的待撮合数据后，记录已经返回到应用服务器的待撮合数据的位置。本申请实施例中，可以将每次返回至应用服务器的一批待撮合数据中最后一个待撮合数据的序号进行记录，其中，所述序号可以是数据库端为查询得到的待撮合数据按照先后查询的次序进行排序得到的序号。举例来说，数据库端在前一次返回序号为00000-09999(10000条)的待撮合数据之后，可以记录当前已返回的待撮合数据的序号为：09999，这样，当数据库端需要向应用服务器再次返回待撮合数据时，则可以提取之前记录的序号：09999，并根据该序号确定本次应该从哪里开始返回待撮合数据，如果本次还是需要返回10000条待撮合数据，则应该返回序号为10000-19999的待撮合数据，返回之后再次记录已返回的待撮合数据的位置(如果后续仍然存在更多待撮合数据需要返回)，直至数据全部返回完毕。当然，在本申请其他实施例中，记录已返回的待撮合数据的方式并不限于上述实施例。甚至数据库端并不需对已返回的待撮合数据的位置进行记录，在其他可行的方案中，可以由应用服务器在接收上一次返回的待撮合数据之后，通过消息的方式通知数据库端应该从哪里开始返回下一批待撮合数据。其中，上述消息可以携带下一批应该返回的第一个待撮合数据的序号。

S105：应用服务器基于返回的M条待撮合数据，逐一与目标数据进行撮合。

如前所述，所述撮合是根据目标数据的特征及待撮合数据的特征，将待撮合数据和目标数据进行匹配，也就是说，当待撮合数据的特征与目标数据的特征相匹配时，则表明该待撮合数据可以与目标数据撮合成功。

S106：应用服务器判断所述目标数据的撮合是否完毕。若完毕，则进入步骤S109；若没有完毕，则进入步骤S107。

在本申请实施例中，上述目标数据一般需要与一定数量的待撮合数据分别撮合成功，才表明当前目标数据的撮合任务完毕，此时可以终止撮合动作。举例来说，对于某个目标数据，需要与100条待撮合数据分别撮合成功，该目标数据的撮合任务才算完毕，则若在基于上述M条待撮合数据进行撮合任务之后，发现该M条待撮合数据中有90条待撮合数据与目标数据分别撮合成功，则还缺少10条待撮合数据成功与目标数据撮合，这样，便需要数据库端在返回上述M条待撮合数据之后，继续向应用服务器返回一定数量的待撮合数据进行接下来的撮合任务，直至完成上述10条待撮合数据的成功撮合。

在应用服务器基于上述M条待撮合数据进行撮合的过程中，包含如下几种情况：

情况③：应用服务器在基于上述M条待撮合数据进行撮合结束后，当前目标数据的撮合还未完毕；

情况④：应用服务器在基于上述M条待撮合数据进行撮合的过程中，当前目标数据的撮合已经完毕。该情况④包括这样一种情况：应用服务器在撮合到上述M条待撮合数据中的第X(1＜X＜M)条待撮合数据时，当前目标数据的撮合已经完毕，则剩余的待撮合数据无需再进行撮合。

针对上述情况③，需要进入步骤S107；针对上述情况④，需要进入步骤S109。

本申请实施例中，存在这样一种情况：虽然当前目标数据还没有撮合完毕，但是数据库端查询到的待撮合数据已经全部被返回到应用服务器端进行撮合(没有更多的可以返回的待撮合数据)，则此时撮合任务应该终止。于是，应用服务器可以判断数据库端查询到的待撮合数据是否全部返回，若数据库端查询到的待撮合数据未全部返回且所述目标数据未撮合完毕，应用服务器基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合。在上述过程中，数据库端可以在每次返回一定数量的待撮合数据的同时，通过消息的方式通知应用服务器是否还有更多的待撮合数据可以返回。当然，在其他实施例中，应用服务器可以不判断数据库端是否还有更多的可以返回的待撮合数据，而是在撮合没有完毕并需要更多的待撮合数据来进行撮合时，通过向数据库发送请求返回更多数据的消息，以触发数据库端返回下一批待撮合数据的动作，其中，数据库端在接收到上述消息之后，若数据库端存在更多的待撮合数据则进行返回动作，若没有更多的待撮合数据在，则不返回数据并可以通知应用服务器本次撮合任务结束。

S107：数据库端在将上述M条待撮合数据返回至应用服务器之后，将处于上述M条待撮合数据之后的N条待撮合数据返回至应用服务器。其中，1≤N≤M。

S108：应用服务器对接收到的N条待撮合数据，逐一与上述目标数据进行撮合。

S109：应用服务器释放与数据库端的连接。

本申请实施例中，若所述目标数据撮合完毕，或数据库端查询到的待撮合数据全部返回，应用服务器可以释放与数据库端的连接，以结束数据库端的数据查询动作及应用服务器端的数据撮合动作。

在上述步骤S108之后，上述流程可以回到步骤S106，继续判断当前目标数据的撮合是否完毕，若没有完毕，则继续要求数据库端返回更多的待撮合数据(如果数据库端还有更多的数据)；若完毕，则进入步骤S109。

值得提及的是，在本申请一实施例中，应用服务器在基于数据库端发送的M条待撮合数据并逐一进行撮合之后，若发现当前目标数据的撮合任务还没有完毕，需要更多的待撮合数据进行撮合，则可以通过向数据库端发送一条请求返回下一批待撮合数据的请求消息，来触发数据库端返回下一批待撮合数据。在本申请另一实施例中，应用服务器可以无需通过发送上述请求消息的方式来触发数据库端返回更多数据。作为替代地，数据库端可以采取TCP的拥塞机制来返回待撮合数据，也就是说，数据库端在向应用服务器返回M条待撮合数据之后，可以不断地将查询得到的处于上述M条待撮合数据之后的n条待撮合数据返回到应用服务器(可以返回到应用服务器的I/O缓冲区中)。其中，根据拥塞机制，上述应用服务器的I/O缓冲区中的待撮合数据由于会不断地被提取进行撮合，上述I/O缓冲区可以不断从满额变化到存在空闲。一般地，数据库端可以逐条向上述I/O缓冲区发送待撮合数据，若上述I/O缓冲区满额，则应用服务器可以向数据库端返回当前待撮合数据接收失败的消息，反之，若上述I/O缓冲区存在空闲，则应用服务器可以向数据库端返回当前待撮合数据接收成功的消息。数据库端在接收到当前待撮合数据接收失败的消息之后，可以隔一段时长再次将该待撮合数据发送到上述应用服务器(存放于上述I/O缓冲区)，如此，直至当前待撮合数据被成功接收。总之，按照上述拥塞机制，数据库端可以在应用服务器端的I/O缓冲区存在空闲时，不断地向该I/O缓冲区中填充更多的待撮合数据，直至该I/O缓冲区满额(拥塞)。

本申请实施例提供的上述数据撮合方法中，数据库端通过接收应用服务器发送的携带查询语句和预设数值M的查询请求，并根据该查询请求执行查询动作，得到待撮合数据。在查询得到待撮合数据之后，数据库端根据上述查询请求中的预设数据M，将M条待撮合数据返回到应用服务器并由应用服务器基于这M条待撮合数据进行撮合(待撮合数据与目标数据的撮合)，若上述M条待撮合数据的撮合动作结束之后，应用服务器针对上述目标数据的撮合还没有完毕，则应用服务器可以再基于数据库端在返回上述M条待撮合数据之后返回的N(1≤N≤M)条待撮合数据，逐一进行待撮合数据与目标数据的撮合动作。可以看出，相较于现有技术，首先在数据撮合的过程中，数据库端每次至多向应用服务器返回M条待撮合数据，一般该预设数值M可以根据应用服务器的内存来确定，以确保应用服务器的内存不会溢出。另外，相比于现有技术的分页查询中需要多次发送查询请求，本申请实施例在上述整个撮合过程中，由于应用服务器只向数据库端发送一次查询请求，并在数据查询过程中按照上述预设数值M及应用服务器端的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行返回，从而可以大大缓解数据库端的负荷。

另外，现有的分页查询方式还存在如下问题：由于一般数据库端的待撮合数据是不断变化的，这样就可能导致查询得到的结果集中的每页中包含的待撮合数据并不是固定的，若每次向应用服务器返回一页待撮合数据，则可能会导致应用服务器接收到的待撮合数据不准确。举例而言，若前一次查询得到的结果集中的第1页的待撮合数据的序号是：“1-100”，第2页的待撮合数据的序号是：“101-200”，这样，数据库端可以先将上述第1页中的待撮合数据返回给应用服务器。假设在后一次查询动作开启之前，上述序号为“80”的待撮合数据从数据库端被删除了，则执行后一次的查询动作，得到的结果集中的第1页的待撮合数据的序号是：“1-79，81-101”，第2页的待撮合数据的序号是：“102-201”，这样，若本次将第2页中的待撮合数据返回给应用服务器，则序号为“101”的这条待撮合数据就被遗漏了。在本申请实施例中，数据库端只接收一次查询请求，并且在查询过程中每次至多返回M条数据并记录每次已返回的待撮合数据的位置，这样，可以避免分页查询过程中因每页待撮合数据不固定，而导致最终查询到的待撮合数据不准确的情况。另一方面，由于只一次查询请求，则表明整个数据查询过程是持续进行的，可以确保查询过程能够查找到较为实时的待撮合数据，从而进一步确保数据撮合过程的数据准确性。

图2为本申请一实施例提供的以应用服务器为主体的数据撮合方法的流程，可以包括：

S201：应用服务器向数据库端发送携带查询语句和预设数值M的查询请求。

该步骤S201可以参照上述步骤S101的内容。

S202：应用服务器基于数据库端返回的M条待撮合数据，逐一将所述待撮合数据与目标数据进行撮合；所述待撮合数据是数据库端根据所述查询语句查询到的。

该步骤S202可以参照上述步骤S105的内容。

S203：若所述目标数据未撮合完毕，应用服务器基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合；1≤N≤M。

该步骤S203可以参照上述步骤S108的内容。

通过本实施例提供的上述方法流程可以看出，应用服务器通过先接收数据库端返回的M条待撮合数据，并基于这M条待撮合数据进行撮合，若结束M条待撮合数据的撮合动作之后，上述目标数据的撮合还没有完毕，则再基于数据库端返回的N条待撮合数据进行撮合；其中，这N条待撮合数据可以是数据库端在返回上述M条待撮合数据之后进行返回的。本申请实施例在上述整个撮合过程中，由于应用服务器只向数据库端发送一次查询请求，并在数据查询过程中按照上述预设数值M及应用服务器端的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行分批返回，从而在确保应用服务器内存不会溢出的前提下，可以大大缓解数据库端的负荷。

以预约单(Appointment)和产品(Product)进行撮合的场景为例，上述数据撮合方法可以包括：

应用服务器向数据库端发送携带查询语句和预设数值M的查询请求。

应用服务器基于数据库端返回的M条预约单数据，逐一将所述预约单数据与预设产品数据进行撮合；所述预约单数据是数据库端根据所述查询语句查询到的，所述预约单数据包含与产品属性对应的条件信息，所述撮合是将所述预设产品数据的产品属性与所述条件信息进行匹配。

若所述预设产品数据未撮合完毕，应用服务器基于数据库端在返回上述M条预约单数据之后返回的N条预约单数据，逐一将所述预约单数据与所述预设产品数据进行撮合；1≤N≤M。

若上述产品为金融产品，则上述产品数据可以是：融资者在互联网平台发布的融资需求；上述预约单数据可以是：投资者在互联网平台上发布的投资需求(即与产品属性对应的条件信息)。具体地，每个金融产品数据可以包括多个产品属性，如：预期收益率、期限、产品类型、金额等，其中，每个产品属性对应于一个值或阈值。上述预约单数据包含的与产品属性对应的条件信息也可以是一个值或阈值。

举例而言，某个产品数据包括的各个产品属性的值分别是：

预期收益率：3.4％～5.4％、期限：1～5年、产品类型：基金、金额：1～50万。

某个预设单数据包含的与各个产品属性对应的条件信息的值分别是：

预期收益率：2％～8％、期限：3年、产品类型：基金、金额：10～20万。

则，该预设单数据的各个条件信息的值(特征)与上述产品数据的各个产品属性的值(特征)的相匹配，则该预设单数据与该产品数据可以撮合成功。反之，撮合失败。

以理财产品数据与预设单数据之间的撮合场景为例，在上述数据查询方法中，若目标数据为理财产品数据，则应用服务器需要从数据库端查询可能满足条件的预设单数据，设定的查询条件(查询语句)可以是某种业务类型的预设单数据。通过查询数据库，可以查询到一定数据的满足条件的预约单数据，但是，并不是查询到的预约单数据便可以与当前的理财产品数据进行匹配。例如，某个投资者的账户被冻结或余额不足等因素，这些情况都会导致该用户的预设单无法与当前产品进行撮合。所以，数据库端在通过流式查询得到一定数据的预约单数据之后，需要分批返回到应用服务器，通过应用服务器对预设单数据和产品数据进行撮合。其中，撮合完毕的标志是：当前产品卖光(比如：有1000万的产品，平均每条预设单的金额是1万，则需要撮合成功1000条预设单数据，本次撮合任务才算完毕)，当应用服务器发现当前产品被撮合完毕后，便可以释放当前应用服务器与数据库端的连接，数据库端即便有更多的预约单数据，也不再进行返回。

当然，在上述撮合场景中，目标数据还可以是预设单数据，则所需查询的数据可以是产品数据。这样，撮合任务的目的便是为当前预设单数据找到合适的产品数据并认购，其过程基本与上述目标数据为产品数据的场景一致，不再赘述。唯一区别之处在于，撮合任务完毕的标志是：为当前预设单数据匹配到符合条件的产品数据并认购。一般地，可以将较早被返回到应用服务器并且符合撮合要求的产品数据，一旦撮合成功便表明当前撮合任务已经完毕，释放数据库的连接。

值得一提的是，上述M可以根据实际业务需求进行调整。在上述撮合业务的场景中，该M可以是预估的业务撮合完毕至少需要的数据条数。例如，假设有金额为1000万的金融产品，数据库中的预约单的平均预约金额是1万，则将该金融产品撮合完毕至少需要1000个预约单，所以可以设定该M为1000，从而数据库端可以每次至多返回1000条数据给应用服务器进行撮合。本申请实施例中，上述M＝产品的库存/一个预约单的平均预约金额+buffer，其中，1≤buffer≤50，该buffer的设置可以与数据库端的数据有效性相关。比如：某用户的账户可能被冻结(概率是百万分之一)，那么假设用户数为100万，这个buffer可设置为1，依次类推，若有其他影响撮合数据有效性的因素，则可以相应地增加这个buffer的数值。

值得一提的是，本申请实施例的应用场景并不限于上述内容，还可以例如：将上述查询到的数据封装成消息体(如邮件或短消息等)进行发送，等等。

图3为本申请一实施例提供的以数据端为主体的数据查询方法的流程，包括：

S301：数据库端接收应用服务器发送的携带查询语句和预设数值M的查询请求。

S302：数据库端向应用服务器返回M条待撮合数据；所述待撮合数据是数据库端根据所述查询语句查询到的，所述待撮合数据用于逐一与目标数据进行撮合。

S303：若所述目标数据未撮合完毕，数据库端在向应用服务器返回上述M条待撮合数据之后，向应用服务器返回的处于上述M条待撮合数据之后的N条待撮合数据；1≤N≤M。

同理，由于数据库端只接收一次应用服务器发送的查询请求，并在数据查询过程中按照上述预设数值M及应用服务器端的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行分批返回，从而在确保应用服务器内存不会溢出的前提下，可以大大缓解数据库端的负荷。

与上述方法流程对应的，本申请的实施例还提供了一种数据撮合装置、及数据查询装置。该装置可以通过计算机软件程序、或计算机硬件、或软硬件的结合来实现。

图4为本申请一实施例提供的数据撮合装置的模块示意图。其中，该装置中各个单元的功能与上述方法中各个步骤的功能均类似，故可以参照上述方法实施例中的内容。本申请实施例中，所述数据撮合装置可以包括发送单元101和撮合单元102，其中：

发送单元101用于向数据库端发送携带查询语句和预设数值M的查询请求。

撮合单元102用于基于数据库端返回的M条待撮合数据，逐一将所述待撮合数据与目标数据进行撮合；所述待撮合数据是数据库端根据所述查询语句查询到的。

所述撮合单元102还用于：若所述目标数据未撮合完毕，基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合；1≤N≤M。

在上述数据撮合装置中，由于数据库端只接收一次发送单元101发送的查询请求，并在数据查询过程中，按照上述预设数值M及撮合单元102的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行分批返回，从而在确保数据撮合装置内存不会溢出的前提下，可以大大缓解数据库端的负荷。

本申请一实施例中，所述装置还包括：

判断单元，用于判断数据库端查询到的待撮合数据是否全部返回；

则所述撮合单元102具体用于：若数据库端查询到的待撮合数据未全部返回且所述目标数据未撮合完毕，基于数据库端在返回上述M条待撮合数据之后返回的N条待撮合数据，逐一将所述待撮合数据与所述目标数据进行撮合。

本申请一实施例中，所述装置还包括：

连接单元，用于建立与数据库端的连接；

则所述装置还用于：若所述目标数据撮合完毕或数据库端查询到的待撮合数据全部返回，释放与数据库端的连接。

本申请一实施例中，所述预设数值M等于所述应用服务器的内存中至多能够存放的待撮合数据的条数。

在预约单数据与产品数据进行撮合的场景中，上述数据撮合装置包括：

发送单元101，用于向数据库端发送携带查询语句和预设数值M的查询请求；

撮合单元102，用于基于数据库端返回的M条预约单数据，逐一将所述预约单数据与预设产品数据进行撮合；所述预约单数据是数据库端根据所述查询语句查询到的，所述预约单数据包含与产品属性对应的条件信息，所述撮合是将所述预设产品数据的产品属性与所述条件信息进行匹配；

所述撮合单元102还用于：若所述预设产品数据未撮合完毕，基于数据库端在返回上述M条预约单数据之后返回的N条预约单数据，逐一将所述预约单数据与所述预设产品数据进行撮合；1≤N≤M。

图5为本申请实施例提供的数据查询装置的模块示意图。其中，该装置中各个单元的功能与上述方法中各个步骤的功能均类似，故可以参照上述方法实施例中的内容。本申请实施例中，所述数据查询装置可以包括：

接收单元201，用于接收应用服务器发送的携带查询语句和预设数值M的查询请求；

返回单元202，用于向应用服务器返回M条待撮合数据；所述待撮合数据是根据所述查询语句查询到的，所述待撮合数据用于逐一与目标数据进行撮合；

所述返回单元202还用于：若所述目标数据未撮合完毕，在向应用服务器返回上述M条待撮合数据之后，向应用服务器返回的处于上述M条待撮合数据之后的N条待撮合数据；1≤N≤M。

在上述数据查询装置中，由于接收单元201只接收一次应用服务器发送的查询请求，并在数据查询过程中，返回单元202按照上述预设数值M及应用服务器的数据撮合情况(目标数据的撮合是否完毕)，来将查询得到的待撮合数据进行分批返回，从而在确保数据撮合装置内存不会溢出的前提下，可以大大缓解数据库端的负荷。

在预约单数据与产品数据进行撮合的场景中，上述数据查询方法可以包括：

接收单元201，用于接收应用服务器发送的携带查询语句和预设数值M的查询请求；

返回单元202，用于向应用服务器返回M条预约单数据；所述预约单数据是根据所述查询语句查询到的，所述预约单数据用于逐一与产品数据进行撮合；所述预约单数据包含与产品属性对应的条件信息，所述撮合是将所述预设产品数据的产品属性与所述条件信息进行匹配；

所述返回单元202还用于：若所述目标数据未撮合完毕，在向应用服务器返回上述M条预约单数据之后，向应用服务器返回的处于上述M条预约单数据之后的N条预约单数据；1≤N≤M。

值得一提的是，本申请提供的是一种流式的查询机制，相较于现有技术的分页查询方式，这种流式查询非常适合数据库中的待撮合数据处于不断变化的场景，其可以在查询过程中感测到数据库中的待撮合数据变化，从而可以查询到较为实时的、准确的待撮合数据并分批返回给应用服务器进行撮合，从而确保了数据撮合过程的准确性。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。