CN113064921B - 一种前后台大容量业务数据查询方法 - Google Patents

Abstract

本发明公开了一种前后台大容量业务数据查询方法，可提高查询性能和并发量，节省计算资源和带宽资源。其技术方案为：本发明将交易数据全存储在后台，降低前台数据管理成本，后台提供分页查询接口，供前台查询特定页面的数据并进行展示。支持针对交易数据进行条件过滤，后台针对指定的过滤条件建立查询缓存。本发明支持轮询和主动通知两种类型的查询方式，轮询机制通过HTTP查询接口定时查询交易数据；主动通知机制在此基础上，增加了基于Websocket协议的动态通知，当有数据方式变化时主动通知前台，使用者可根据实际情况灵活选用查询方式。

Description

一种前后台大容量业务数据查询方法

技术领域

本发明涉及数据处理技术，具体涉及可应用于金融交易软件领域中的前后台金融大容量业务数据查询的技术。

背景技术

目前的金融交易软件通常使用C/S(客户端/服务端)或B/S(网页端/服务端)架构，通常将“服务端”称为“后台”，将“网页端”或“客户端”称为“前台”。其中，后台通常负责进行实时交易数据(如订单、成交等)的存储和更新，前台通常负责交易数据的实时展示。因此，前台需要实时向后台查询最新的交易数据。

目前的金融交易软件的应用中，存在以下的一些需求：

(1)后台存储交易数据，负责根据交易情况实时更新交易数据中的记录。

(2)前台进行交易数据展示，展示方式为分页展示，支持针对多个特定的列进行数据筛选，实时展示经过筛选后的数据的总记录条数，并对筛选后的数据进行分页，展示特定页码上的数据。

如：当前后台符合筛选条件的交易数据记录条数为200条，前台设定每页展示50条记录，那么这些数据可以被分为4页，其中第2页的数据为第51～100条记录。

(3)当后台交易数据有更新时，如果被更新的数据符合前台展示页面的筛选条件，那么前台需要对页面进行更新，以展示最新的交易数据。

(4)后台存储的交易数据量较大(如千万条记录级别)，需要针对大容量业务数据的查询进行优化设计，防止前后台查询操作的延时过大。

当且的金融交易软件对上述的几点的需求并没有足够的支持力度，因此，业界亟待开发一种技术来满足上述需求。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明提供了一种前后台大容量业务数据查询方法，可提高查询性能和并发量，节省计算资源和带宽资源。

本发明的技术方案为：本发明揭示了一种前后台大容量业务数据查询方法，方法基于定时查询机制实现，包括：

步骤1：前台根据查询条件向后台发送页面修改请求，该页面修改请求为Http请求，请求数据中包含以下字段：数据集名称、查询条件、上次查询ID；

步骤2：后台收到页面修改请求后，根据请求数据中的数据集名称的字段确定原始交易数据集，如果页面修改请求中填写了上次查询ID，则后台根据上次查询ID字段中的值查找对应的查询缓存数据集并加以删除；

步骤3：后台根据请求数据中的新的查询条件建立新的查询缓存数据集，将当前原始数据集中符合查询条件的记录的指针加入到该新的查询缓存数据集中，后台为该新的查询缓存数据集分配全局编号，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和新分配的全局编号通过HTTP应答返回给前台进行保存；

步骤4：后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增数据记录，则检查新增的数据是否符合各查询缓存数据集对应的查询条件，如符合则将该新增的数据记录的指针加入到该查询缓存数据集中；如果检测到原始交易数据集中更新或删除数据记录，则检查该数据记录更新后或删除后是否还符合各个查询缓存数据集对应的查询条件，如不符合则将该更新或删除的数据记录的指针从该查询缓存数据集中删除；

步骤5：前台收到HTTP应答后，保存当前的全局编号和总记录条数，开始进行定时查询；

步骤6：前台每次进行定时查询前，先检测页面上设定的查询条件是否发生变化，如果没发生变化则向后台发送查询请求，如果发生变化则通知后台重新建立查询缓存数据集，并向后台再次发送页面修改请求，页面修改请求中的查询条件字段填写新的内容，上次查询ID填写当前保存的全局编号，其中查询请求数据包含以下字段：数据集名称、查询ID、查询页码、每页记录数；

步骤7：后台收到查询请求后，取出请求数据中的数据集名称和查询ID对应的查询缓存数据集，根据该对应的查询缓存数据集中的记录总数以及请求数据中的每页记录数和查询页码字段，计算查询数据结果在该查询缓存数据集中的起始位置和结束位置，并将该起始位置和结束位置限定的范围内的数据取出，通过HTTP应答返回给前台；

步骤8：前台收到查询应答后，根据返回的记录内容进行数据展示，然后返回步骤6做新一轮的定时轮询。

根据权利要求1所述的前后台大容量业务数据查询方法，其特征在于，在步骤6中，如果前台当前展示的页码被用户重新设置，则直接发送查询请求以获取对应页码最新的数据。

根据本发明的前后台大容量业务数据查询方法的一实施例，查询缓存数据集是交易数据记录的集合，是原始交易数据集中的数据记录经过查询条件过滤后形成的子集。

本发明还揭示了一种前后台大容量业务数据查询方法，方法基于主动通知机制实现，包括：

步骤1：前台根据查询条件向后台发送页面修改请求，该页面修改请求为Http请求，请求数据中包含以下字段：数据集名称、查询条件、上次查询ID；

步骤2：后台收到页面修改请求后，根据页面修改请求数据中的数据集名称字段确定原始交易数据集，如果页面修改请求中填有上次查询ID字段，则后台根据该上次查询ID字段中的值查找对应的查询缓存数据集并进行删除；

步骤3：后台根据页面修改请求中的新的查询条件建立新的查询缓存数据集，将当前原始交易数据集中符合查询条件的记录的指针加入到该新的查询缓存数据集中，后台为该新的查询缓存数据集分配全局编号，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和全局编号通过HTTP应答返回给前台；

步骤4：前台收到应答后，保存当前的全局编号和总记录条数；

步骤5：前台与后台建立Websocket连接，连接成功后向后台发送订阅请求消息，其中订阅请求消息包含以下字段：数据集名称、查询ID；

步骤6：后台收到订阅请求消息后，根据订阅请求消息中的数据集名称和查询ID字段取出对应的查询缓存数据集，将该查询缓存数据集的状态标记为订阅中，建立订阅任务，之后后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增了数据记录，则检查新增的数据是否符合各个查询缓存数据集对应的查询条件，如符合则将该新增数据记录的指针加入到该查询缓存数据集中，如果检测到原始交易数据集中更新或删除了数据记录，则检查该数据记录更新后或删除后是否符合各个查询缓存数据集对应的查询条件，如不符合则将该数据记录的指针从该查询缓存数据集中删除，其中在后台持续维护已建立的查询缓存数据集的过程中，若查询缓存数据集的当前状态为订阅中，则后台会通过Websocket连接向前台发送页面通知消息，以通知前台数据集已发生改变，页面通知消息包含如下字段：数据集名称、查询ID；

步骤7：前台收到页面通知消息后，获知当前页面数据需要进行刷新，主动向后台发送查询请求，后台收到该查询请求后取出查询请求数据中的数据集名称和查询ID对应的查询缓存数据集，根据该对应的查询缓存数据集中的记录总数以及请求数据中的每页记录数和查询页码字段，计算查询数据结果在该查询缓存数据集中的起始位置和结束位置，并将该起始位置和结束位置限定的范围内的数据取出，通过HTTP应答返回给前台。

根据本发明的前后台大容量业务数据查询方法的一实施例，后台为每个查询缓存数据集维护一个订阅状态：未订阅状态或订阅中状态，在步骤3中的新建查询缓存数据集后，将该新建的查询缓存数据集的订阅状态置为未订阅状态。

根据本发明的前后台大容量业务数据查询方法的一实施例，查询缓存数据集是交易数据记录的集合，是原始交易数据集中的数据记录经过查询条件过滤后形成的子集。

根据本发明的前后台大容量业务数据查询方法的一实施例，如果前台检测到查询条件已经发生变化，则通知后台重新建立查询缓存数据集，前台向后台再次发送页面修改请求，页面修改请求中的查询条件字段填写新的内容，上次查询ID字段填写当前保存的全局编号。

根据本发明的前后台大容量业务数据查询方法的一实施例，如果前台当前展示的页码被用户重新设置，则直接发送查询请求以获取对应页码最新的数据。

本发明对比现有技术有如下的有益效果：本发明的方法中设计了以下几点特点：(1)交易数据全部存储在后台，降低前台数据管理成本，后台提供分页查询接口，供前台查询特定页面的数据并进行展示。(2)同时支持C/S和B/S架构，接口使用标准HTTP协议和Websocket协议，不限于特定的语言实现。(3)支持针对交易数据进行条件过滤，后台会针对指定的过滤条件建立查询缓存，以提高查询性能，提高并发量。(4)支持轮询和主动通知两种类型的查询方式，轮询机制通过HTTP查询接口定时查询交易数据；主动通知机制在此基础上，增加了基于Websocket协议的动态通知，当有数据方式变化时可以主动通知前台，使用者可根据实际情况灵活选用查询方式。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的前后台大容量业务数据查询方法的一实施例的流程图。

图2示出了本发明的前后台大容量业务数据查询方法的另一实施例的流程图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的前后台大容量业务数据查询方法的一实施例的流程。本实施例是基于定时查询机制实现的，其主要思路是：前台定时发送HTTP查询请求给后台，后台根据请求中的字段来进行数据筛选，并把符合要求的数据通过HTTP应答发回至前台，供前台展示。考虑到后台存储的交易数据量比较大，本实施例中可在查询过程中加入查询缓存机制。请参见图1，本实施例的业务数据查询方法的实施步骤详述如下。

步骤11：前台根据当前查询条件(当前页面上选定的查询条件)，向后台发送页面修改(modify_page)请求，该请求为HTTP请求。

请求数据中包含如下参数：

参数名	参数含义	作用
			table	数据集名称	指定查询哪个数据集
filter	查询条件	指定查询条件，即按照哪些字段进行过滤
			last_query_id	上一次查询ID	指定调用modify_page前，前台存储的查询ID

如果是初次查询，则last_query_id字段置空。

步骤12：后台收到页面修改(modify_page)请求后，根据请求数据中的table字段确定原始交易数据集。如果请求中填写了last_query_id字段，则后台根据last_query_id字段中的这个query_id值找到对应的查询缓存数据集，并删除这个查询缓存数据集。

步骤13：后台根据请求数据中的新的查询条件(filter)，建立新的查询缓存数据集，将当前原始数据集中符合查询条件的记录的指针加入到这个新的查询缓存数据集中。后台为新的查询缓存数据集分配一个全局编号query_id，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和新分配的query_id通过HTTP应答返回给前台进行保存。

步骤14：后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增数据记录，检查新增的数据是否符合各个查询缓存数据集对应的查询条件，如符合则将该数据记录的指针加入到该查询缓存数据集中；如果检测到原始交易数据集中更新或删除了数据记录，则检查该数据记录更新后或删除后是否还符合各个查询缓存数据集对应的查询条件，如不符合则将该更新或删除的数据记录的指针从该查询缓存数据集中删除。

对于后台来说，后台所维护的查询缓存数据集可能会有多个，每个查询缓存数据集都有自己的查询条件，因为前台可以同时发起多次查询，在每个查询流程中，后台都会针对该次查询的查询条件建立新的查询缓存数据集。因此，新增的数据若符合其中的一个查询缓存数据集的查询条件，则将指针加入的符合查询条件的这个查询缓存数据集中。而对于一个查询缓存数据集来说，如果当前数据记录已经不满足这个查询缓存数据集的查询条件，则需要将这条数据记录的指针从这个查询缓存数据集中删除。

步骤15：前台收到HTTP应答后，保存当前的全局编号query_id和总记录条数，之后开始进行定时查询。

步骤16：前台每次进行定时查询前，先检测页面上设定的查询条件是否发生变化。如果没发生变化，则向后台发送查询(query_page)请求，该请求为HTTP请求。

查询(query_page)请求数据中包含如下参数：

如果发生变化，则通知后台重新建立查询缓存数据集。此时向后台再次发送modify_page请求，modify_page请求中的filter字段填写新的查询条件，last_query_id字段填写当前保存的query_id。

此外，如果前台当前展示的页码被用户重新设置，也可以直接发送query_page请求以获取对应页码最新的数据。

步骤17：后台收到查询请求query_page后，取出请求数据中的table和query_id对应的查询缓存数据集。根据查询缓存数据集中的记录总数total_vol，以及请求数据中的page_vol和page_id字段，计算查询数据结果在查询缓存数据集中的起始位置和结束位置，并将该范围内的数据取出，通过HTTP应答返回给前台。

在定时查询机制中，由于加入了查询缓存数据集，查询缓存数据集是交易数据记录的集合，是原始交易数据集中的数据记录经过特定的查询条件过滤后形成的子集。如对于订单数据集来讲，如果将订单状态作为查询条件，查询订单状态为“状态A”的记录，那么会形成一个针对于该查询条件的查询缓存数据集，该查询缓存数据集内的数据记录均为订单记录且订单状态为“状态A”。

本实施例将一条交易数据称为交易数据记录，交易数据记录由多个字段组成，如一个订单就是一条交易记录，包含“订单编号、买卖方向、数量、价格、订单状态”等字段。同一类型的多条交易数据记录构成了数据集，如订单数据集、成交数据集等。数据集内的交易数据记录是有序的，排序规则根据业务规则制定，如订单数据集可以按照“订单编号”进行排序。后台负责管理各个数据集，前台可以针对不同的数据集进行展示，并可以指定按照特定的字段进行过滤，只展示符合过滤条件的交易数据记录。

前台每次发起查询请求时后台不需要再根据过滤条件进行筛选和查询，而是直接根据查询缓存数据集中的内容查找需要返回的记录，在原始交易数据集数据量较大的情况下，可以大大缩短每次查询所需要的时间，提升整体查询性能。

步骤18：前台收到查询应答后，根据返回的记录内容进行数据展示，然后返回步骤16做新一轮的定时轮询。

在上述图1所示的实施例中，是基于定时查询机制来实现的，需要前台定时向后台发起查询请求。如果原始交易数据集本身是不活跃的，即数据更新的频率很低，那么前台每次查询得到的结果经常是一致的，这样对前台、后台资源和带宽资源都会造成浪费。针对这种场景，本发明提出了主动通知机制，前台不需要定时进行查询，当后台检测到相关数据发生变化时会主动通知前台，前台再进行数据查询。这种处理的整体流程如图2所示的实施例来说明，请参见图2。

步骤21：前台根据当前页面上选定的查询条件，向后台发送modify_page请求，如果是初次查询，则last_query_id字段置空。

步骤22：后台收到modify_page请求后，根据table字段确定原始交易数据集。如果请求中填写了last_query_id字段，则后台根据last_query_id字段中的这个query_id找到对应的查询缓存数据集，并删除这个查询缓存数据集。

步骤23：后台根据modify_page请求中的新的查询条件filter，建立新的查询缓存数据集，将当前原始交易数据集中符合查询条件的记录的指针加入到这个查询缓存数据集中。后台为新的查询缓存数据集分配一个全局编号query_id，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和query_id通过HTTP应答返回给前台。

在此机制下，后台会为每个查询缓存数据集维护一个订阅状态，可取“未订阅”、“订阅中”两种状态，在本步骤内新建查询缓存数据集后，将这一新建的查询缓存数据集的订阅状态置为“未订阅”。

步骤24：前台收到应答后，保存当前的query_id和总记录条数。

步骤25：前台与后台建立Websocket连接，连接成功后向后台发送subscribe_page消息(订阅请求)，subscribe_page消息中包含如下字段：

参数名	参数含义
		table	数据集名称
query_id	查询ID

其中，消息中的query_id填写为当前保存的query_id。

步骤26：后台收到subscribe_page消息后，根据消息中的table和query_id字段取出对应的查询缓存数据集，将该查询缓存数据集的状态标记为“订阅中”，建立订阅任务。

之后，后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增了数据记录，检查新增的数据是否符合各个查询缓存数据集对应的查询条件，如符合则将该数据记录的指针加入到该查询缓存数据集中；如果检测到原始交易数据集中更新或删除了数据记录，则检查该数据记录更新后或删除后是否还符合各个查询缓存数据集对应的查询条件，如不符合则将该数据记录的指针从该查询缓存数据集中删除。

对于后台来说，后台所维护的查询缓存数据集可能会有多个，每个查询缓存数据集都有自己的查询条件，因为前台可以同时发起多次查询，在每个查询流程中，后台都会针对该次查询的查询条件建立新的查询缓存数据集。因此，新增的数据若符合其中的一个查询缓存数据集的查询条件，则将指针加入的符合查询条件的这个查询缓存数据集中。而对于一个查询缓存数据集来说，如果当前数据记录已经不满足这个查询缓存数据集的查询条件，则需要将这条数据记录的指针从这个查询缓存数据集中删除。

在上述后台持续维护已建立的查询缓存数据集的处理过程中，若查询缓存数据集的当前状态为“订阅中”，那么后台会通过Websocket连接向前台发送一个页面通知(page_notify)消息，通知前台数据集已发生改变，page_notify消息中包含如下字段：

参数名	参数含义
		table	数据集名称
query_id	查询ID

步骤27：前台收到page_notify消息后，得知当前页面数据需要进行刷新，之后主动向后台发送query_page请求。后台收到该query_page请求后取出对应的数据，将应答返回给前台进行展示。

这一步骤与“定时查询机制”中描述的步骤17一致。

在整个流程中，如果前台检测到查询条件已经发生变化(可能发生在整个流程中的任一位置，相当于中断本次流程并重启整个查询流程)，则需要通知后台重新建立查询缓存数据集。此时需要向后台再次发送modify_page请求，请求中的filter字段填写新的查询条件，last_query_id字段填写当前保存的query_id。此外，如果前台当前展示的页码被用户重新设置，也可以直接发送query_page请求以获取对应页码最新的数据。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体***的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (8)

1.一种前后台大容量业务数据查询方法，其特征在于，方法基于定时查询机制实现，包括：

步骤1：前台根据查询条件向后台发送页面修改请求，该页面修改请求为Http请求，请求数据中包含以下字段：数据集名称、查询条件、上次查询ID；

步骤2：后台收到页面修改请求后，根据请求数据中的数据集名称的字段确定原始交易数据集，如果页面修改请求中填写了上次查询ID，则后台根据上次查询ID字段中的值查找对应的查询缓存数据集并加以删除；

步骤3：后台根据请求数据中的新的查询条件建立新的查询缓存数据集，将当前原始数据集中符合查询条件的记录的指针加入到该新的查询缓存数据集中，后台为该新的查询缓存数据集分配全局编号，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和新分配的全局编号通过HTTP应答返回给前台进行保存；

步骤4：后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增数据记录，则检查新增的数据是否符合各查询缓存数据集对应的查询条件，如符合则将该新增的数据记录的指针加入到该查询缓存数据集中；如果检测到原始交易数据集中更新或删除数据记录，则检查该数据记录更新后或删除后是否还符合各个查询缓存数据集对应的查询条件，如不符合则将该更新或删除的数据记录的指针从该查询缓存数据集中删除；

步骤5：前台收到HTTP应答后，保存当前的全局编号和总记录条数，开始进行定时查询；

步骤6：前台每次进行定时查询前，先检测页面上设定的查询条件是否发生变化，如果没发生变化则向后台发送查询请求，如果发生变化则通知后台重新建立查询缓存数据集，并向后台再次发送页面修改请求，页面修改请求中的查询条件字段填写新的内容，上次查询ID填写当前保存的全局编号，其中查询请求数据包含以下字段：数据集名称、查询ID、查询页码、每页记录数；

步骤7：后台收到查询请求后，取出请求数据中的数据集名称和查询ID对应的查询缓存数据集，根据该对应的查询缓存数据集中的记录总数以及请求数据中的每页记录数和查询页码字段，计算查询数据结果在该查询缓存数据集中的起始位置和结束位置，并将该起始位置和结束位置限定的范围内的数据取出，通过HTTP应答返回给前台；

步骤8：前台收到查询应答后，根据返回的记录内容进行数据展示，然后返回步骤6做新一轮的定时轮询。

2.根据权利要求1所述的前后台大容量业务数据查询方法，其特征在于，在步骤6中，如果前台当前展示的页码被用户重新设置，则直接发送查询请求以获取对应页码最新的数据。

3.根据权利要求1所述的前后台大容量业务数据查询方法，其特征在于，查询缓存数据集是交易数据记录的集合，是原始交易数据集中的数据记录经过查询条件过滤后形成的子集。

4.一种前后台大容量业务数据查询方法，其特征在于，方法基于主动通知机制实现，包括：

步骤1：前台根据查询条件向后台发送页面修改请求，该页面修改请求为Http请求，请求数据中包含以下字段：数据集名称、查询条件、上次查询ID；

步骤2：后台收到页面修改请求后，根据页面修改请求数据中的数据集名称字段确定原始交易数据集，如果页面修改请求中填有上次查询ID字段，则后台根据该上次查询ID字段中的值查找对应的查询缓存数据集并进行删除；

步骤3：后台根据页面修改请求中的新的查询条件建立新的查询缓存数据集，将当前原始交易数据集中符合查询条件的记录的指针加入到该新的查询缓存数据集中，后台为该新的查询缓存数据集分配全局编号，记录对应的查询条件，最后将当前查询缓存数据集的总记录条数和全局编号通过HTTP应答返回给前台；

步骤4：前台收到应答后，保存当前的全局编号和总记录条数；

步骤5：前台与后台建立Websocket连接，连接成功后向后台发送订阅请求消息，其中订阅请求消息包含以下字段：数据集名称、查询ID；

步骤6：后台收到订阅请求消息后，根据订阅请求消息中的数据集名称和查询ID字段取出对应的查询缓存数据集，将该查询缓存数据集的状态标记为订阅中，建立订阅任务，之后后台持续维护已建立的查询缓存数据集，如果检测到原始交易数据集中新增了数据记录，则检查新增的数据是否符合各个查询缓存数据集对应的查询条件，如符合则将该新增数据记录的指针加入到该查询缓存数据集中，如果检测到原始交易数据集中更新或删除了数据记录，则检查该数据记录更新后或删除后是否符合各个查询缓存数据集对应的查询条件，如不符合则将该数据记录的指针从该查询缓存数据集中删除，其中在后台持续维护已建立的查询缓存数据集的过程中，若查询缓存数据集的当前状态为订阅中，则后台会通过Websocket连接向前台发送页面通知消息，以通知前台数据集已发生改变，页面通知消息包含如下字段：数据集名称、查询ID；

步骤7：前台收到页面通知消息后，获知当前页面数据需要进行刷新，主动向后台发送查询请求，后台收到该查询请求后取出查询请求数据中的数据集名称和查询ID对应的查询缓存数据集，根据该对应的查询缓存数据集中的记录总数以及请求数据中的每页记录数和查询页码字段，计算查询数据结果在该查询缓存数据集中的起始位置和结束位置，并将该起始位置和结束位置限定的范围内的数据取出，通过HTTP应答返回给前台。

5.根据权利要求4所述的前后台大容量业务数据查询方法，其特征在于，后台为每个查询缓存数据集维护一个订阅状态：未订阅状态或订阅中状态，在步骤3中的新建查询缓存数据集后，将该新建的查询缓存数据集的订阅状态置为未订阅状态。

6.根据权利要求4所述的前后台大容量业务数据查询方法，其特征在于，查询缓存数据集是交易数据记录的集合，是原始交易数据集中的数据记录经过查询条件过滤后形成的子集。

7.根据权利要求4所述的前后台大容量业务数据查询方法，其特征在于，如果前台检测到查询条件已经发生变化，则通知后台重新建立查询缓存数据集，前台向后台再次发送页面修改请求，页面修改请求中的查询条件字段填写新的内容，上次查询ID字段填写当前保存的全局编号。

8.根据权利要求7所述的前后台大容量业务数据查询方法，其特征在于，如果前台当前展示的页码被用户重新设置，则直接发送查询请求以获取对应页码最新的数据。