CN113672640A - 数据查询方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种数据查询方法、装置、计算机设备和存储介质。所述方法包括：接收查询请求；所述查询请求中携带用户标识信息；从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。采用本方法能够有效提高数据查询效率。

Description

数据查询方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种数据查询方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，互联网产品的用户数量激增，并发访问数很高，单一的服务器已不能同时服务巨大数量的用户，因而服务端可以采用搭建服务器集群的方式，来提升系统的吞吐量和保证服务的冗余。

然而，目前的数据查询方式中，通常采用主-从复制机制从主服务器同步数据到从服务器，从服务器可以代替主服务器为用户提供服务，但在高并发的大量用户终端的请求的情况下，依然会出现用户请求严重超时的问题，容易导致数据查询效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高数据查询效率的数据查询方法、装置、计算机设备和存储介质。

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

接收查询请求；所述查询请求中携带用户标识信息；

从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

在其中一个实施例中，在所述从更新服务器中查询与所述查询请求对应的数据之后，还包括：

若未查询到与所述查询请求对应的数据，则从基线服务集群中查询与所述查询请求对应的数据，将在所述基线服务集群中查询到的数据返回至与所述用户标识信息对应的用户终端。

在其中一个实施例中，所述接收查询请求，包括：

接收服务器集群中负载均衡服务器分发的查询请求。

在其中一个实施例中，所述更新服务器包括更新主服务器和更新从服务器；所述更新主服务器用于写数据；所述更新从服务器用于读数据；

所述从更新服务器中查询与所述查询请求对应的数据，包括：

从所述更新从服务器中查询与所述查询请求对应的数据。

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

接收模块，用于接收查询请求；所述查询请求中携带用户标识信息；

查询模块，用于从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

发送模块，用于若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

接收查询请求；所述查询请求中携带用户标识信息；

从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

接收查询请求；所述查询请求中携带用户标识信息；

从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

上述数据查询方法、装置、计算机设备和存储介质，通过接收查询请求，查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。若查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。由此使得，将增量数据分离到更新服务器中，查询时优先从更新服务器中读取数据，能够高效命中数据，快速查询到与查询请求对应的的数据，解决了大量数据情况下数据查询高延迟的问题，有效提高了数据查询效率。

一种数据同步方法，所述方法包括：

获取预设时间段内的增量数据；

将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

在其中一个实施例中，所述方法还包括：

检测所述基线服务集群的运行状态；

若所述基线服务集群处于空闲状态，则将所述增量数据写入至所述基线服务集群中的第一服务器上。

一种数据同步装置，所述装置包括：

获取模块，用于获取预设时间段内的增量数据；

写入模块，用于将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取预设时间段内的增量数据；

将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取预设时间段内的增量数据；

将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

上述数据同步方法、装置、计算机设备和存储介质，通过获取预设时间段内的增量数据，将增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步增量数据。其中，第一服务器用于写数据，第二服务器用于读数据。由此使得，按照预设时间段将更新服务器数据写入到基线服务集群，出现高延时的时间也控制在业务冷淡的时间，大大减少了对用户的影响。

附图说明

图1为一个实施例中数据查询方法的应用环境图；

图2为一个实施例中数据查询方法的流程示意图；

图3为一个实施例中数据同步方法的流程示意图；

图4A为另一个实施例中数据查询方法的流程示意图；

图4B为一个实施例中服务器集群对用户终端发送的查询请求进行处理的示意图；

图4C为一个实施例中数据查询处理的架构图；

图5为一个实施例中数据查询装置的结构框图；

图6为一个实施例中数据同步装置的结构框图；

图7为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的数据查询方法，可以应用于如图1所示的应用环境中。其中，用户终端102通过网络与服务器集群104通过网络进行通信，服务器集群104可以通过网络与更新服务器106通过网络进行通信。服务器集群104接收用户终端102发送的查询请求，查询请求中携带用户标识信息。服务器集群104从更新服务器106中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。若服务器集群104查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端102。其中，用户终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用多个服务器组成的服务器集群来实现，更新服务器106可以用独立部署的多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种数据查询方法，以该方法应用于图1中的服务器集群中的服务节点为例进行说明，包括以下步骤：

步骤202，接收查询请求，查询请求中携带用户标识信息。

Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。即Solr是一个高性能，采用Java开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，Solr组件提供的类似数据库聚合统计查询功能。Solr存储由多个Core(即索引库)组成，一个逻辑实例为一个Core，每个Core对应一个索引目录，类似于数据库中的表。一个索引包含多个Document(即文档对象)，类似于数据库的一条记录。一个Document有多个字段，每个字段对应多个Term(即分词)。

互联网产品用户数量庞大，并发访问数很高，单一的服务器不能同时服务如此巨大数量的用户，所以需要搭建一个服务器集群，以提升系统的吞吐量和保证服务的冗余。Solr Server提供了master-slave replication(主-从复制机制)机制以实现集群方案，其核心思想是采用读写分离来提供服务的冗余和性能扩展。即在集群的内部服务器之间通过HTTP复制，将A服务器中的增量数据复制到B服务器和更多的读服务器中，这样在B服务器中就有了与A服务器一致的数据备份。对于互联网读多写少的场景，A服务器专心于数据更新，做更少的事情不用应对大量的用户读请求。而B服务器代替A服务器为用户提供服务。A服务器仅做少量事情，宕机的可能性大大减小，而B服务器失败也有其它的机器代替它服务用户，这样用户几乎感觉不到服务的异常。

具体的，以服务器集群中的某个服务节点为例进行说明。在分布式服务、高并发请求量的环境下，服务器集群可以通过LBS(负载均衡服务器)对外提供服务，用户并没有感知到集群的存在，用户请求发送至统一的服务地址，LBS根据集群服务器的负载状况，将用户请求分发到其中一台机器上进行响应，即将用户请求分发到服务集群中的其中一个服务节点进行响应。服务器集群中的服务节点接收到分发的用户终端发送的查询请求，其中，查询请求是指用户根据不同需求在不同业务场景系统中发起的与业务功能对应的查询请求。用户可以通过在手机应用程序中或浏览器网页中输入用户名和密码的方式，登录特定场景的业务系统中，用户可以通过app(Application，应用程序)客户端或web客户端即web浏览器发起特定的查询请求，服务器集群中的服务节点可以接收到客户端通过网关发送的查询请求，查询请求中携带对应的用户标识信息，标识信息用于标识唯一的用户。例如，用户可以通过触发操作发起查询订单请求，并通过服务网关发送至服务器集群。服务器集群可以通过LBS(负载均衡服务器)对外提供服务，即LBS根据集群服务器的负载状况，将该用户终端发送的查询订单请求分发到其中一台机器上进行响应，即将查询订单请求分发到服务集群中的其中一个服务节点进行响应。当服务器集群接收到该用户终端发送的查询订单请求时，则服务器集群可以根据查询订单请求中的标识信息，从服务注册中心获取与标识信息对应的可用的服务清单，调用对应的服务节点进行处理。

步骤204，从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。

服务器集群中的服务节点接收查询请求之后，服务器集群中的服务节点可以根据查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。其中，更新服务器是指独立部署的专门用于记录预设时间段内的修改增量的服务器(集群)。以前的数据保持不变，以前的数据可以称为基线数据。每次进行查询时都需要把基线数据和增量数据整合后返回客户端，更新服务器中的增量数据可以按照预设时间定期写入到原来的服务集群(基线服务集群)中的写服务器上(例如，预设时间段可以设置为一天)，原来的服务集群(基线服务集群)中其它读服务器再通过原有的复制机制(即主-从复制机制)同步数据(一天)。这样从节点的复制次数从原来每分钟一次变为现在一天一次，出现高延时的时间也控制在业务冷淡的时间，大大减少了对用户的影响。此外，本申请中的更新服务器可以是独立部署的服务集群，不在基线服务集群中，即独立主从部署的服务集群。

步骤206，若查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。

服务器集群中的服务节点根据查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据，若服务节点查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。即服务器集群中的服务节点接收到用户终端发送的查询请求时，优先从独立部署的更新服务器中查询是否存在与该查询请求对应的数据，若服务节点从更新服务器中查询到与查询请求对应的数据，则直接将查询到的热点数据返回至与用户标识信息对应的用户终端。若服务节点从独立部署的更新服务器中未查询到与查询请求对应的数据，则从基线服务集群中查询与查询请求对应的数据，并将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。由于更新服务器用于记录预设时间段内的增量数据，即专门记录热点数据，用户发送的查询请求一般也需要查询近期的最新数据，因而针对热点数据进行区别对待，将增量数据与基线数据进行分离，即利用更新服务器记录预设时间段内的增量数据(热点数据)，能够解决数据量巨大产生的查询高时延问题。

传统的数据查询方式中，在使用Solr的主-从复制机制从主服务器同步数据到从服务器时，需要经历从节点拉取增量数据，合并数据到本地的索引，并执行删除旧数据缓存、加载新数据缓存、打开新查询器等过程，若从节点未完成主节点数据的复制，那么直接读取将会读取不到从节点上的数据，如果等待从节点同步完成才能读取到数据，则需要更长时间。若采用数据分片的方式，虽然通过分片方式降低文档数可以解决单分片查询耗时，但多片数据组装同样会耗用更多时间。由于分片过多，数据读取时，数据来源于多个分片，数据的汇总和组装将需要大量耗时，容易导致查询请求响应更慢，出现高延时的问题，影响查询的处理效率。

而本实施例中，通过接收查询请求，查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。若查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。由此使得，将增量数据分离到更新服务器中，查询时优先从更新服务器中读取数据，能够高效命中数据，快速查询到与查询请求对应的的数据，解决了大量数据情况下数据查询高延迟的问题，有效提高了数据查询效率。

在一个实施例中，在从更新服务器中查询与查询请求对应的数据之后，该方法还包括从基线服务集群中查询与查询请求对应的数据的步骤，具体包括：

若未查询到与查询请求对应的数据，则从基线服务集群中查询与查询请求对应的数据，将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。

服务器集群中的服务节点接收查询请求之后，服务器集群中的服务节点可以根据查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据。具体的，若服务器集群中的服务节点从更新服务器中未查询到与查询请求对应的数据，则从基线服务集群中查询与查询请求对应的数据，将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。即服务节点优先从更新服务器中查询数据，只有当从更新服务器中为查询到目标数据时，服务节点才从基线服务集群中查询与查询请求对应的数据。

例如，服务器集群中的服务节点接收到用户A查询请求1之后，服务器集群中的服务节点根据查询请求1中携带用户标识信息A，从更新服务器中查询与查询请求1对应的数据，若查询到对应的目标数据，则服务节点直接将在更新服务器中查询到的目标数据返回至与用户标识信息A对应的用户终端A。若未查询到对应的目标数据，则服务节点再从基线服务集群中查询与查询请求1对应的目标数据，并将在基线服务集群中查询到的目标数据返回至与用户标识信息A对应的用户终端A。由于大部分用户请求可以直接从更新服务器中查询到目标数据，因而只有部分用户请求会到达基线服务集群中查询，也能够有效降低基线服务集群的请求量，有效缓解大量的请求给基线服务集群带来的较高的服务压力。

在一个实施例中，接收查询请求的步骤，包括：

接收服务器集群中负载均衡服务器分发的查询请求。

服务器集群中的服务节点接收服务器集群中负载均衡服务器分发的查询请求。具体的，在分布式服务、高并发请求量的环境下，服务器集群可以通过LBS(负载均衡服务器)对外提供服务，用户并没有感知到集群的存在，用户请求发送至统一的服务地址，LBS根据集群服务器的负载状况，将用户请求分发到其中一台机器上进行响应，即将用户请求分发到服务集群中的其中一个服务节点进行响应。由于互联网产品用户数量庞大，并发访问数很高，单一的服务器不能同时服务如此数量的用户，同时7*24小时可用是互联网产品的基本要求，所以可以通过搭建服务器集群的方式，以提升系统的吞吐量和保证服务的冗余。

在一个实施例中，更新服务器包括更新主服务器和更新从服务器，更新主服务器用于写数据，更新从服务器用于读数据，从更新服务器中查询与查询请求对应的数据的步骤，包括：

从更新从服务器中查询与查询请求对应的数据。

服务器集群中的服务节点接收查询请求之后，服务器集群中的服务节点可以根据查询请求中携带用户标识信息，从更新服务器中查询与查询请求对应的数据。其中，更新服务器包括更新主服务器和更新从服务器，更新主服务器用于写数据，更新从服务器用于读数据。更新服务器可以是独立部署的服务集群，不在基线服务集群中，即独立主从部署的服务集群。更新服务器中可以只存储当天最新数据，查询时优先查询。即服务器集群中的服务节点可以根据查询请求中携带用户标识信息，从更新从服务器中查询与查询请求对应的数据。更新服务器可以按照预先设置的时间点，每天定时(比如深夜服务请求低峰时)通过应用程序将更新服务器中的最新数据写入到基线服务集群。例如，更新服务器(集群)中包括Update server主(更新主服务器)、Update server备(更新从服务器)，即为主从部署的更新服务，用于记录当天更新的数据，数据读取时优先从更新从服务器中读取，按照预设的固定时间将数据同步到基线服务集群。

集群服务的核心在于保证用户数据的一致性，基于Solr Server(基线服务集群)的主-从复制机制在复制的过程中，会出现用户请求严重超时的问题。传统方式中给出解决的方法是减小Core(即索引库)的文档数，并采用数据分片的方式创建多个逻辑Core。但是目前业务数据已经数以亿计且每个月至少以四千万的速度在增加，单片太小导致片数过多，也会给查询带来更大的延时。

而本实施例中，通过分析业务的数据量，发现数据量虽然非常庞大，但最近一段时间(例如一天)的修改量往往不多，通常为百万，相比数亿的数据，1％都不到。所以本实施例中可以采用独立部署更新服务器来记录最近一段时间的修改增量，而以前的基线数据保持不变，将增量数据按照预设时间定期写入到原来基线服务集群中的写服务器上，其它读服务器再通过原有的复制机制同步数据。这样从节点的复制次数从原来每分钟一次变为现在一天一次，出现高延时的时间也控制在业务冷淡的时间，大大减少了对用户的影响，有效提高了数据查询效率。

在一个实施例中，如图3所示，提供了一种数据同步方法，以该方法应用于图1中的更新服务器为例进行说明，包括以下步骤：

步骤302，获取预设时间段内的增量数据。

步骤304，将增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步增量数据；其中，第一服务器用于写数据，第二服务器用于读数据。

更新服务器获取预设时间段内的增量数据，并将增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步增量数据。其中，第一服务器用于写数据，第二服务器用于读数据。即更新服务器可以是独立部署的服务集群，不在基线服务集群中，即本实施中可以独立主从部署两套服务集群，一套为基线服务集群，一套为更新服务集群。基线服务集群中包括第一服务器和第二服务器，即主服务器用于写数据，从服务器用于通过主-从复制机制从主服务器中同步数据。更新服务集群中也包括Update server主(更新主服务器)、Update server备(更新从服务器)，即为主从部署的更新服务，用于记录当天更新的数据，数据读取时优先从更新从服务器中读取，并按照预设的时间将数据同步到基线服务集群中的写服务器上。由此使得，将增量数据(热数据)分离到更新服务，查询时可以高效命中数据，快速查询到需要的数据，有效提高了数据查询效率。此外，每天定时(如深夜服务请求低峰时)通过应用程序将更新服务器数据写入到基线服务集群，出现高延时的时间也控制在业务冷淡的时间，大大减少了对用户的影响。

在一个实施例中，该方法还包括检测基线服务集群的运行状态的步骤，具体包括：

检测基线服务集群的运行状态。

若基线服务集群处于空闲状态，则将增量数据写入至基线服务集群中的第一服务器上。

更新服务器可以实时检测基线服务集群的运行状态。若检测到基线服务集群处于空闲状态，则更新服务器可以将增量数据写入至基线服务集群中的第一服务器上。即在基线服务集群处于空闲状态或者服务请求量低峰时，更新服务器可以将增量数据写入至基线服务集群中的写服务器上，使得从节点的复制次数从原来每分钟一次变为现在在空闲状态或者服务请求量低峰时进行数据复制同步，出现高延时的时间也控制在业务冷淡的时间，大大减少了对用户的影响。

在一个实施例中，如图4A所示，提供了一种数据查询方法，以该方法应用于图1中的服务器集群中的服务节点为例进行说明，包括以下步骤：

步骤402，接收查询请求，查询请求中携带用户标识信息。

步骤404，从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。

步骤406，若查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。

步骤408，若未查询到与查询请求对应的数据，则从基线服务集群中查询与查询请求对应的数据，将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。

在分布式服务、高并发请求量的环境下，如图4B所示，为服务器集群对用户终端发送的查询请求进行处理的示意图。服务器集群可以通过LBS(负载均衡服务器)对外提供服务，用户请求发送至统一的服务地址，LBS根据集群服务器的负载状况，将用户请求分发到其中一台机器上进行响应，即将用户请求分发到服务集群中的其中一个服务节点进行响应。如图4C所示，为数据查询处理的架构图。服务器集群中的服务节点接收到分发的用户终端(客户端)发送的查询请求之后，服务器集群中的服务节点可以根据查询请求中携带用户标识信息，从更新服务集群的Update server备(更新从服务器)中查询与查询请求对应的数据，更新服务集群用于记录预设时间段内的增量数据。若服务节点从Update server备(更新从服务器)中查询到与查询请求对应的数据，则直接将查询到的热点数据返回至与用户标识信息对应的用户终端。若服务节点从独立部署的更新从服务器中未查询到与查询请求对应的数据，则从Solr Server(基线服务集群)中查询与查询请求对应的数据，并将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。由此使得，将增量数据分离到更新服务器中，查询时优先从更新服务器中读取数据，能够高效命中数据，快速查询到与查询请求对应的的数据，解决了大量数据情况下数据查询高延迟的问题，有效提高了数据查询效率。

应该理解的是，虽然图1-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-4中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图5所示，提供了一种数据查询装置，包括：接收模块502、查询模块504和发送模块506，其中：

接收模块502，用于接收查询请求，查询请求中携带用户标识信息。

查询模块504，用于从更新服务器中查询与查询请求对应的数据，更新服务器用于记录预设时间段内的增量数据。

发送模块506，用于若查询到与查询请求对应的数据，则将数据返回至与用户标识信息对应的用户终端。

在一个实施例中，查询模块还用于若未查询到与查询请求对应的数据，则从基线服务集群中查询与查询请求对应的数据，将在基线服务集群中查询到的数据返回至与用户标识信息对应的用户终端。

在一个实施例中，接收模块还用于接收服务器集群中负载均衡服务器分发的查询请求。

在一个实施例中，查询模块还用于从更新从服务器中查询与查询请求对应的数据。

在一个实施例中，如图6所示，提供了一种数据同步装置，包括：获取模块602和写入模块604，其中：

获取模块602，用于获取预设时间段内的增量数据。

写入模块604，用于将增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步增量数据；其中，第一服务器用于写数据，第二服务器用于读数据。

在一个实施例中，该装置还包括：检测模块。

检测模块用于检测基线服务集群的运行状态，若基线服务集群处于空闲状态，则将增量数据写入至基线服务集群中的第一服务器上。

关于数据查询装置的具体限定可以参见上文中对于数据查询方法的限定，在此不再赘述。上述数据查询装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

关于数据同步装置的具体限定可以参见上文中对于数据同步方法的限定，在此不再赘述。上述数据同步装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储数据查询数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种数据查询方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述各个方法实施例的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种数据查询方法，所述方法包括：

接收查询请求；所述查询请求中携带用户标识信息；

从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

2.根据权利要求1所述的方法，其特征在于，在所述从更新服务器中查询与所述查询请求对应的数据之后，还包括：

若未查询到与所述查询请求对应的数据，则从基线服务集群中查询与所述查询请求对应的数据，将在所述基线服务集群中查询到的数据返回至与所述用户标识信息对应的用户终端。

3.根据权利要求1所述的方法，其特征在于，所述接收查询请求，包括：

接收服务器集群中负载均衡服务器分发的查询请求。

4.根据权利要求1所述的方法，其特征在于，所述更新服务器包括更新主服务器和更新从服务器；所述更新主服务器用于写数据；所述更新从服务器用于读数据；

所述从更新服务器中查询与所述查询请求对应的数据，包括：

从所述更新从服务器中查询与所述查询请求对应的数据。

5.一种数据同步方法，所述方法包括：

获取预设时间段内的增量数据；

将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

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

检测所述基线服务集群的运行状态；

若所述基线服务集群处于空闲状态，则将所述增量数据写入至所述基线服务集群中的第一服务器上。

7.一种数据查询装置，其特征在于，所述装置包括：

接收模块，用于接收查询请求；所述查询请求中携带用户标识信息；

查询模块，用于从更新服务器中查询与所述查询请求对应的数据；所述更新服务器用于记录预设时间段内的增量数据；

发送模块，用于若查询到与所述查询请求对应的数据，则将所述数据返回至与所述用户标识信息对应的用户终端。

8.一种数据同步装置，其特征在于，所述装置包括：

获取模块，用于获取预设时间段内的增量数据；

写入模块，用于将所述增量数据按照预设时间段写入至基线服务集群中的第一服务器上，以指示第二服务器通过预设复制机制同步所述增量数据；其中，所述第一服务器用于写数据，所述第二服务器用于读数据。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。

Images