CN114138825A - 一种服务器及为应用程序提供数据查询服务的方法 - Google Patents

Abstract

本申请提供一种服务器及为应用程序提供数据查询服务的方法，当触发应用程序的扩容条件时，应用程序节点会优先与分布式缓存主节点连接，使得分布式缓存主节点为应用程序节点提供数据查询服务，当分布式缓存从节点与分布式缓存主节点的数据同步完成时，应用程序节点与分布式缓存主节点断开连接，并与分布式缓存从节点连接，使得分布式缓存从节点为应用程序节点提供数据查询服务。通过以上方式不仅解决服务器性能不足和带宽占用不足的问题，还可以在使用缓存提升应用程序性能的同时，尽最大可能降低应用程序扩容启动时对缓存的依赖，达到快速高效提供数据查询服务的目的。

Description

一种服务器及为应用程序提供数据查询服务的方法

技术领域

本申请涉及服务器技术领域，尤其涉及一种服务器及为应用程序提供数据查询服务的方法。

背景技术

分布式缓存是应用程序提升性能的通用处理手段，缓存数据存储在内存中。应用程序获取数据时，首先从缓存中查询，如果缓存中存在目标数据，将数据返回给应用程序。避免应用程序查询后端的数据库。由于缓存数据存储在内存中，数据库数据存储在硬盘中，内存速度远高于硬盘，因此应用缓存可以大大提升应用程序性能。

相关技术中业务通用的分布式缓存使用方案是：部署分布式缓存集群，应用程序连接到缓存集群，部署模式如下图1。但是该方案的存在以缺陷：当应用程序QPS(每秒的请求量)过大时，会不断增加分布式缓存集群服务器的负担，特别是每次访问缓存返回的数据信息较多的场景下，伴随着QPS的增加，对网络带宽的影响非常大，带宽的扩容通常较为复杂，且成本较高。

为了解决访问量增加带来的服务器性能不足、带宽不足的问题。部分厂家对该方案进行优化，每个应用程序服务器内部挂载一个分布式缓存的从节点，从节点数据是从主节点同步过来的，应用程序访问缓存时，无需访问远端分布式缓存服务器，访问本地缓存服务即可。这样优化后，每个应用程序访问独有的本地缓存服务，并且不需要网络开销，提升了访问性能，架构图如图2所示。该方案解决了访问性能问题，但是带来了以下缺陷：当前应用程序为面向终端用户的互联网服务时，应用程序的请求量非常大，因此必须有缓存层进行应对大流量的冲击。此时使用该方案，当应用程序因流量激增需要扩容时，就必须保证本地的分布式缓存从节点数据同步完成后再提供服务。此时有可能本地缓存从节点数据的同步速度低于扩容需要，造成系统故障。

发明内容

本申请提供了一种服务器及为应用程序提供数据查询服务的方法，使用缓存提升应用程序性能的同时，并尽最大可能降低应用程序扩容启动时对缓存的依赖，达到快速高效提供服务的目的。

第一方面，本申请提供了一种服务器，被配置为：

当触发应用程序的扩容条件时，扩容应用程序节点；

控制所述应用程序节点与分布式缓存主节点连接，以使所述分布式缓存主节点为所述应用程序节点提供数据查询服务，同时，将分布式缓存主节点的数据同步至分布式缓存从节点；

如果所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成，控制所述应用程序节点与所述分布式缓存主节点断开连接，并与所述分布式缓存从节点连接，以使所述分布式缓存从节点为所述应用程序节点提供数据查询服务。

在一种实现方式中，所述触发应用程序的扩容条件包括：

当前时间到达预设时间，或者

当前用户数据请求量超过预设值，或者

当前用户数据请求量超过当前全部应用程序节点所能处理最大用户数据请求量。

在一种实现方式中，所述服务器，被配置为：

根据当前用户数据请求量、当前全部应用程序节点所能处理最大用户数据请求量及单个应用程序节点所能处理最大用户数据请求量确定所述应用程序节点的扩容数量。

在一种实现方式中，所述服务器，被配置为：

定时检测所述分布式缓存从节点与所述分布式缓存主节点的数据是否同步完成。

在一种实现方式中，所述服务器，被配置为：

定时检测所述分布式缓存从节点的日志文件内是否有标志分布式缓存从节点与分布式缓存主节点的数据同步完成的日志信息；

如果所述日志文件内有所述数据同步完成的日志信息，确定所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成。

第二方面，本申请提供了一种为应用程序提供数据查询服务的方法，应用于服务器，所述方法包括：

当触发应用程序的扩容条件时，扩容应用程序节点；

控制所述应用程序节点与分布式缓存主节点连接，以使所述分布式缓存主节点为所述应用程序节点提供数据查询服务，同时，将分布式缓存主节点的数据同步至分布式缓存从节点；

如果所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成，控制所述应用程序节点与所述分布式缓存主节点断开连接，并与所述分布式缓存从节点连接，以使所述分布式缓存从节点为所述应用程序节点提供数据查询服务。

在一种实现方式中，所述触发应用程序的扩容条件包括：

当前时间到达预设时间，或者

当前用户数据请求量超过预设值，或者

当前用户数据请求量超过当前全部应用程序节点所能处理最大用户数据请求量。

在一种实现方式中，所述方法还包括：

根据当前用户数据请求量、当前全部应用程序节点所能处理最大用户数据请求量及单个应用程序节点所能处理最大用户数据请求量确定所述应用程序节点的扩容数量。

在一种实现方式中，所述方法还包括：

定时检测所述分布式缓存从节点与所述分布式缓存主节点的数据是否同步完成。

在一种实现方式中，所述方法还包括：

定时检测所述分布式缓存从节点的日志文件内是否有标志分布式缓存从节点与分布式缓存主节点的数据同步完成的日志信息；

如果所述日志文件内有所述数据同步完成的日志信息，确定所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成。

由以上技术方案可知，当触发应用程序的扩容条件时，应用程序节点会优先与分布式缓存主节点连接，使得分布式缓存主节点为应用程序节点提供数据查询服务，当分布式缓存从节点与分布式缓存主节点的数据同步完成时，应用程序节点与分布式缓存主节点断开连接，并与分布式缓存从节点连接，使得分布式缓存从节点为应用程序节点提供数据查询服务。通过以上方式不仅解决服务器性能不足和带宽占用不足的问题，还可以在使用缓存提升应用程序性能的同时，尽最大可能降低应用程序扩容启动时对缓存的依赖，达到快速高效提供数据查询服务的目的。

附图说明

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

图1为分布式缓存集群方案部署模式图；

图2为分布式缓存集群改进方案部署模式图；

图3为本申请实施例中为应用程序提供数据查询服务的方法流程图；

图4为本申请实施例中分布式缓存主节点和分布式缓存从节点缓存连接建立的示意图；

图5为本申请实施例中触发扩容条件后数据查询和数据同步的示意图；

图6为本申请实施例中触发扩容条件后应用程序节点连接方式的示意图；

图7为本申请实施例中分布式缓存主节点和分布式缓存从节点数据同步过程中数据查询和数据同步的示意图；

图8为本申请实施例中检测分布式缓存主节点和分布式缓存从节点数据是否同步完成的示意图；

图9为本申请实施例中分布式缓存主节点和分布式缓存从节点数据同步完成后的应用程序节点连接方式的示意图。

具体实施方式

为使本申请的目的和实施方式更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。

术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

图1中分布式缓存集群方案缺陷是当应用程序每秒请求量过大时，会不断增加分布式缓存集群服务器的负担，特别是每次访问缓存返回的数据信息较多的场景下，伴随着每秒请求量的增加，对网络带宽的影响非常大，带宽的扩容通常较为复杂，且成本较高。图2中分布式缓存集群改进方案缺陷是当应用程序因流量激增需要扩容时，就必须保证本地的分布式缓存从节点数据同步完成后再提供数据查询服务。此时有可能本地缓存从节点数据的同步速度低于扩容需要，造成系统故障。以上两种方案均不能同时解决流量激增带来得服务器缓存性能不足、带宽占用不足和扩容效率低的问题。

为了同时解决流量激增带来服务器缓存性能不足、带宽占用不足和扩容效率低的问题，本申请实施例采用如图3所示的方法，具体如下：

每个应用程序服务器内部部署一个本地的分布式缓存从节点，分布式缓存从节点用于与应用程序节点连接，以使分布式缓存从节点可以为应用程序提供数据查询服务。

应用程序创建两个缓存连接，分别是分布式缓存从节点的缓存连接和分布式缓存主节点的缓存连接。

在一些可行的实施例中，分布式缓存主节点与分布式缓存从节点通过特定的通信协议与应用程序节点通信并为应用程序提供数据查询服务。

在一些可行的实施例中，分页式缓存框架Redis使用的是RESP协议。其中，Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的应用程序接口。Redis的客户端和服务端之间在TCP(TransmissionControl Protocol，传输控制协议)的上层采用一种独立名为RESP(Redis SerializationProtocol)协议作为进行通讯的标准方式。

分页式缓存提供的数据查询服务需要通过通信协议使用，因此应用程序使用其提供数据查询服务时，需要连接该服务的IP/端口。在一些实施例中，如图4所示，分布式缓存主节点的IP/端口是：192.168.1.110:6380，分布式缓存从节点的IP/端口是：127.0.0.1:6380。(注：127.0.0.1是应用程序所在服务的本地IP)。此时，分布式缓存主节点和分布式缓存从节点有了明确的IP/端口。应用程序在扩容启动时，通过该指定IP/端口，应用程序节点可以与分布式缓存主节点和分布式缓存从节点分别建立连接。

步骤S301:当触发应用程序的扩容条件时，扩容应用程序节点；

在一些可行的实施例中，触发应用程序的扩容条件包括当前时间到达预设时间。例如：每天晚上8点-11点是某应用程序用户请求量的高峰时段，可以选择在晚8点之前将应用程序节点扩容完成，即可在每天晚上7点50分时触发应用程序的扩容指令，以使应用程序节点在每天时间到达晚上7点50分时开始扩容。该应用程序节点扩容数量可以是固定数值，也可以根据近一段时间内该时段用户平均请求量稍作更改。

在一些可行的实施例中，触发应用程序的扩容条件包括运维人员发出扩容指令。例如：某应用程序在某个时间点开展某些活动或在某个时间点播出某些节目，可能预见在该时间点用户数据请求量会急剧增大。运维人员可在该时间点前提前发出扩容指令，并在该时间点前将应用程序节点提前扩容到预设数量。该应用程序节点扩容数量可以是运维人员估算出的数量，也可以根据往期同活动的用户数据请求量设置。

在一些可行的实施例中，触发应用程序的扩容条件包括当前用户数据请求量超过预设值。例如：检测到应用程序在某一时刻用户数据请求量超过预设值，即可满足触发应用程序的扩容条件。

在一些可行的实施例中，如果应用程序当前用户数据请求量超过第一预设值且未超过第二预设值，满足触发应用程序的扩容条件，可扩容第一数量的应用程序节点；如果应用程序当前用户数据请求量超过第二预设值且未超过第三预设值，同样满足触发应用程序的扩容条件，此时，扩容第二数量的应用程序节点，以此类推，根据当前用户数据请求量确定应用程序节点的扩容数量。例如：如果应用程序在某一时刻用户数据请求量为960个，用户数据请求量960个未超过第一预设值1000个，不满足触发应用程序的扩容条件，即无需扩容应用程序节点；如果应用程序在某一时刻用户数据请求量为1560个，用户数据请求量1560个超过第一预设值1000个且未超过第二预设值2000个，可以开始扩容应用程序节点，该应用程序的节点扩容数量为第一数量20个；如果应用程序在某一时刻用户数据请求量为2479个，用户数据请求量2479个超过第二预设值2000个且未超过第三预设值3000个，可以开始扩容应用程序节点，该应用程序节点扩容数量为第二数量40个，以此类推，根据当前用户数据请求量确定应用程序节点的扩容数量。

在一些可行的实施例中，触发应用程序的扩容条件包括当前用户数据请求量超过当前全部应用程序节点所能处理最大用户数据请求量。

在一些可行的实施例中，获取当前应用程序节点的数量，以及，单个应用程序节点所能处理最大用户数据请求量；根据当前应用程序节点的数量，以及，每个应用程序节点处理最大用户数据请求量确定当前全部应用程序节点所能处理最大用户数据请求量；

判断当前用户数据实际请求量是否超过当前所有应用程序节点处理最大用户数据请求量；

如果当前用户数据实际请求量未超过当前所有应用程序节点处理最大用户数据请求量，则不满足应用程序的扩容条件，即当前应用程序节点无需扩容。

如果当前用户数据实际请求量超过当前所有应用程序节点处理最大用户数据请求量，则满足应用程序的扩容条件，即当前需要扩容应用程序节点，并根据当前用户数据实际请求量、当前全部应用程序节点所能处理最大用户数据请求量，以及，单个应用程序节点所能处理最大用户数据请求量，采用向上取整函数确定应用程序节点的扩容数量，具体如下：

应用程序节点的扩容数量＝Roundup[(当前用户数据实际请求量-当前所有应用程序节点所能处理最大用户数据请求量)/单个应用程序节点所能处理最大用户数据请求量，0]。

在一些可行的实施例中，用户数据实际请求量实时变化，而且扩容过程中应用程序节点的数量也在持续增长。因此，可以定时获取用户数据实际请求量及当前应用程序节点的数量，确定当前应用程序节点是否还需要继续扩容。如果仍需要继续扩容应用程序节点，根据当前用户数据实际请求量重新确定当前应用程序节点的扩容数量。

例如：当前应用程序节点的数量为20个，单个应用程序节点所能处理最大用户数据请求量为50个；根据当前应用程序节点的数量，以及，每个应用程序节点处理最大用户数据请求量确定当前所有应用程序节点所能处理最大用户数据请求量，即20×50＝1000个。

判断当前用户数据实际请求量是否超过当前所有应用程序节点处理最大用户数据请求量1000个；

如果当前用户数据实际请求量为900个，即当前用户数据实际请求量900个未超过当前所有应用程序节点处理最大用户数据请求量1000个，则不满足应用程序的扩容条件，即当前应用程序节点无需扩容。

如果当前用户数据实际请求量为1490个，即当前用户数据实际请求量1490个超过当前所有应用程序节点处理最大用户数据请求量1000个，则满足应用程序的扩容条件，即当前应用程序节点需要扩容，并根据当前用户数据实际请求量1490个、当前所有应用程序节点处理最大用户数据请求量1000个，以及，每个应用程序节点所能处理最大用户数据请求量50个，确定应用程序节点的扩容数量。

应用程序节点的扩容数量＝Roundup[(当前用户数据实际请求量-当前所有应用程序节点处理最大用户数据请求量)/每个应用程序节点所能处理最大用户数据请求量，0]＝Roundup[(1490-1000)/50，0]＝Roundup[9.8，0]＝10。

应用程序设定每2分钟获取一次用户数据实际请求量及当前应用程序节点的数量。2分钟后，再次获取到当前应用程序节点的数量为24个，用户数据实际请求量为1520个，则当前所有应用程序节点处理最大用户数据请求量，即24×50＝1200个。

当前用户数据实际请求量1520个超过当前所有应用程序节点所能处理最大用户数据请求量1200个，则满足应用程序的扩容条件，即当前应用程序节点需要扩容。

应用程序节点的扩容数量＝Roundup[(当前用户数据实际请求量-当前所有应用程序节点处理最大用户数据请求量)/每个应用程序节点所能处理最大用户数据请求量，0]＝Roundup[(1520-1200)/50，0]＝Roundup[6.4，0]＝7。

步骤S302:控制应用程序节点与分布式缓存主节点连接，以使所述分布式缓存主节点为所述应用程序节点提供数据查询服务，同时，将分布式缓存主节点的数据同步至分布式缓存从节点，如图5所示；

在一些可行的实施例中，在应用程序节点开始扩容时，应用程序节点与分布式缓存主节点默认连接，此时，当用户请求数据时，可通过分布式缓存主节点为应用程序节点提供数据查询服务，此时，应用程序的状态已是可用状态，可以为用户提供数据查询服务，如图6所示。

在一些可行的实施例中，在应用程序节点开始扩容时，将分布式缓存主节点与分布式缓存从节点的数据开始同步。分布式缓存从节点从分布式缓存主节点同步数据时，会将同步过程写到日志文件中。同步完成时，分布式缓存从节点的日志文件中会明确的写入一条标志同步完成的日志信息。

步骤S303:检测分布式缓存从节点与分布式缓存主节点的数据是否同步完成。

在一些可行的实施例中，在分布式缓存从节点从分布式缓存主节点同步数据的同时，应用程序后台启动一个线程，定时检验应用程序本地的分布式缓存从节点是否同步完成，如图7所示。

在一些可行的实施例中，应用程序定时检测分布式缓存从节点的日志文件，通过判断日志文件中是否存在标志分布式缓存从节点从分布式缓存主节点数据同步完成的日志信息来判断分布式缓存从节点与分布式缓存主节点的数据是否同步完成，如图8所示。

如果分布式缓存从节点与分布式缓存主节点的数据未同步完成，即分布式缓存从节点的日志文件不存在标志分布式缓存从节点从分布式缓存主节点数据同步完成的日志信息，不执行任何操作，等待下个时间点继续检测分布式缓存从节点与分布式缓存主节点的数据是否同步完成，即检测下个时间点分布式缓存从节点的日志文件是否存在标志分布式缓存从节点从分布式缓存主节点数据同步完成的日志信息。

如果分布式缓存从节点与分布式缓存主节点的数据同步完成，即分布式缓存从节点的日志文件存在标志分布式缓存从节点从分布式缓存主节点数据同步完成的日志信息，执行步骤S304。

步骤S304：控制应用程序节点与分布式缓存主节点断开连接，并与分布式缓存从节点连接，以使分布式缓存从节点为应用程序节点提供数据查询服务。

在一些可行的实施例中，分布式缓存从节点与分布式缓存主节点的数据同步完成后，将应用程序的缓存服务连接切换到应用程序本地的分布式缓存从节点，并关闭分布式缓存主节点的连接，如图2所示。即应用程序节点与分布式缓存从节点默认连接，此时，当用户请求数据时，可通过分布式缓存从节点为应用程序提供数据查询服务，此时应用程序的状态已是可用状态，可以为用户提供数据查询服务，如图9所示。

假设应用程序本地分布式缓存从节点与分布式缓存主节点数据同步需要5分钟，用户数据查询请求量激增时，需要在10分钟内扩容10个应用程序节点，每次同步并行扩容2个应用程序节点。使用图2所示的改进方案，5分钟扩容一个应用程序节点，2个应用程序节点一起扩容，10分钟内只能扩容4个应用程序节点，无法满足用户数据查询请求量激增需要扩容的应用程序节点数量。

而在本申请的实施例中，用户数据查询请求量激增时，面对同样需要在10分钟内扩容10个应用程序节点的需求，在每次同步并行扩容2个，应用程序扩容启动需要1分钟，应用程序分布式缓存从节点与分布式缓存主节点数据同步需要5分钟的条件下，采用本申请的方案10个应用程序节点只需5分钟即可扩容完成。由于应用程序扩容启动后默认使用的分布式缓存主节点提供数据查询服务，启动完成即可提供数据查询服务，无需等本地缓存从节点与分布式缓存主节点数据同步完成后才提供数据查询服务。此外，每次扩容两个应用程序节点，因此分布式缓存主节点只需要最多同时为两个应用程序节点提供数据查询服务，且扩容完成后会断开连接。对服务器缓存性能的要求、带宽的要求都是非线性增长的、可控的。

在一些实施例中，在步骤S304中分布式缓存从节点为应用程序提供数据查询服务之后，当分布式缓存主节点有大量数据需要与分布式缓存从节点同步，数据同步时间可能过长，导致分布式缓存从节点无法及时提供数据查询服务。如果分布式缓存主节点有数据需要与分布式缓存从节点同步，且预计数据同步的时间超过预设数值，可控制应用程序节点与分布式缓存从节点断开连接，并与分布式缓存主节点连接，以使分布式缓存主节点为应用程序提供数据查询服务。在分布式缓存从节点从分布式缓存主节点同步数据的同时，应用程序后台启动一个线程，定时检验应用程序本地的分布式缓存从节点是否同步完成。

如果分布式缓存从节点与分布式缓存主节点的数据未同步完成，不执行任何操作，等待下个时间点继续检测分布式缓存从节点与分布式缓存主节点的数据是否同步完成。

如果分布式缓存从节点与分布式缓存主节点的数据同步完成，控制应用程序节点与分布式缓存主节点断开连接，并与分布式缓存从节点连接，以使分布式缓存从节点为应用程序提供数据查询服务。

由于分布式缓存主节点与分布式缓存从节点数据同步时，使用的分布式缓存主节点提供数据查询服务，无需等待分布式缓存主节点与分布式缓存从节点数据同步完成即可提供数据查询服务。因此，在分布式缓存主节点有大量数据需要与分布式缓存从节点同步时仍可高效快速提供数据查询服务。当分布式缓存主节点与分布式缓存从节点数据同步完成时，继续由分布式缓存从节点为应用程序提供数据查询服务。

由以上技术方案可知，当触发应用程序的扩容条件时，应用程序节点会优先与分布式缓存主节点连接，使得分布式缓存主节点为应用程序节点提供数据查询服务，当分布式缓存从节点与分布式缓存主节点的数据同步完成时，应用程序节点与分布式缓存主节点断开连接，并与分布式缓存从节点连接，使得分布式缓存从节点为应用程序节点提供数据查询服务。通过以上方式不仅解决服务器性能不足和带宽占用不足的问题，还可以在使用缓存提升应用程序性能的同时，尽最大可能降低应用程序扩容启动时对缓存的依赖，达到快速高效提供数据查询服务的目的。

本申请提供的实施例之间的相似部分相互参见即可，以上提供的具体实施方式只是本申请总的构思下的几个示例，并不构成本申请保护范围的限定。对于本领域的技术人员而言，在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。

Claims (10)

1.一种服务器，其特征在于，被配置为：

当触发应用程序的扩容条件时，扩容应用程序节点；

控制所述应用程序节点与分布式缓存主节点连接，以使所述分布式缓存主节点为所述应用程序节点提供数据查询服务，同时，将所述分布式缓存主节点的数据同步至分布式缓存从节点；

如果所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成，控制所述应用程序节点与所述分布式缓存主节点断开连接，并与所述分布式缓存从节点连接，以使所述分布式缓存从节点为所述应用程序节点提供数据查询服务。

2.根据权利要求1所述的服务器，其特征在于，所述触发应用程序的扩容条件包括：

当前时间到达预设时间，或者

当前用户数据请求量超过预设值，或者

当前用户数据请求量超过当前全部应用程序节点所能处理最大用户数据请求量。

3.根据权利要求2所述的服务器，其特征在于，所述服务器被配置为：

根据当前用户数据请求量、当前全部应用程序节点所能处理最大用户数据请求量及单个应用程序节点所能处理最大用户数据请求量确定所述应用程序节点的扩容数量。

4.根据权利要求1所述的服务器，其特征在于，所述服务器被配置为：

定时检测所述分布式缓存从节点与所述分布式缓存主节点的数据是否同步完成。

5.根据权利要求1所述的服务器，其特征在于，所述服务器被配置为：

定时检测所述分布式缓存从节点的日志文件内是否有标志分布式缓存从节点与分布式缓存主节点的数据同步完成的日志信息；

如果所述日志文件内有所述数据同步完成的日志信息，确定所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成。

6.一种为应用程序提供数据查询服务的方法，其特征在于，应用于服务器，所述方法包括：

当触发应用程序的扩容条件时，扩容应用程序节点；

控制所述应用程序节点与分布式缓存主节点连接，以使所述分布式缓存主节点为所述应用程序节点提供数据查询服务，同时，将分布式缓存主节点的数据同步至分布式缓存从节点；

如果所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成，控制所述应用程序节点与所述分布式缓存主节点断开连接，并与所述分布式缓存从节点连接，以使所述分布式缓存从节点为所述应用程序节点提供数据查询服务。

7.根据权利要求6所述的方法，其特征在于，所述触发应用程序的扩容条件包括：

当前时间到达预设时间，或者

当前用户数据请求量超过预设值，或者

当前用户数据请求量超过当前全部应用程序节点所能处理最大用户数据请求量。

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

根据当前用户数据请求量、当前全部应用程序节点所能处理最大用户数据请求量及单个应用程序节点所能处理最大用户数据请求量确定所述应用程序节点的扩容数量。

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

定时检测所述分布式缓存从节点与所述分布式缓存主节点的数据是否同步完成。

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

定时检测所述分布式缓存从节点的日志文件内是否有标志分布式缓存从节点与分布式缓存主节点的数据同步完成的日志信息；

如果所述日志文件内有所述数据同步完成的日志信息，确定所述分布式缓存从节点与所述分布式缓存主节点的数据同步完成。

Images