CN117271583A - 优化大数据查询的系统及方法 - Google Patents

Abstract

本发明公开了优化大数据查询的系统及方法，属于大数据查询技术领域，要解决的技术问题为如何提高大数据业务查询及处理速度。包括数据库服务器、应用服务器、数据统计分析模块、统计分析数据库以及分布式缓存集群，数据统计分析模块配置于应用服务器端执行；数据统计分析模块用于基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中；应用服务器用于执行如下：基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中未查询到对应的数据，从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

Description

优化大数据查询的系统及方法

技术领域

本发明涉及大数据查询技术领域，具体地说是优化大数据查询的系统及方法。

背景技术

大数据分析是指对规模巨大的数据进行分析。大数据可以概括为5个V，数据量大(Volume)、速度快(Velocity)、类型多(Variety)、价值(Value)、真实性(Veracity)。目前大数据是存储在关系型数据库中，如DB2数据库、Oracle数据库等。这些数据集中采集到大数据平台后的数据量庞大，常规的数据查询和处理速度慢、耗时长，难以满足软件功能需要。

提高数据查询速度可分为两类，一类是提高硬件资源配置，增加服务器、升级CUP、扩大物理内存、提高网速宽带等；另一类是从软件设计上进行优化，目前常规软件流程图如图1所示，程序直接从关系型数据库进行读取操作，获取需要的数据，当数据量达到亿级时，直接导致程序长时间运行没有响应，大量占据服务器资源，服务器负荷很高，程序宕机问题。

传统的程序主要由应用服务器和数据库服务器组成，应用服务器负责接收客户端发送的请求并进行处理，数据库负责大数据信息并处理来自应用服务器的请求。但是随着业务量的增多，传统的系统架构面临着巨大挑战，频繁的请求使得数据库服务器不堪重负，经常导致死锁现象发生，响应延迟，磁盘I/O读取速度成为了系统性能瓶颈，影响了整个网站的性能。

如何提高大数据业务查询及处理速度，是需要解决的技术问题。

发明内容

本发明的技术任务是针对以上不足，提供优化大数据查询的系统及方法，来解决如何提高大数据业务查询及处理速度的技术问题。

第一方面，本发明一种优化大数据查询的系统，其特征在于，包括数据库服务器、应用服务器、数据统计分析模块、统计分析数据库以及分布式缓存集群，数据统计分析模块配置于应用服务器端执行；

所述数据库服务器中存储有数据；

所述数据统计分析模块用于基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中；

所述应用服务器用于执行如下：接收客户端的申请，基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

作为优选，所述分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

作为优选，对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据并提供数据查询；

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

作为优选，哨兵集群包括哨兵节点和数据节点，哨兵节点至少一个且不存储数据，主缓存节点和从缓存节点均作为数据节点；

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

每个哨兵节点以预定的频率向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。

第二方面，本发明一种优化大数据查询的方法，通过如第一方面任一项所述的一种优化大数据查询的系统对大数据查询进行优化，所述方法包括如下步骤：

基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中

通过应用服务器接收客户端的申请；

基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

作为优选，所述分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

作为优选，对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据并提供数据查询；

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

作为优选，哨兵集群包括哨兵节点和数据节点，哨兵节点至少一个且不存储数据，主缓存节点和从缓存节点均作为数据节点；

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

每个哨兵节点以预定的频率向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。

本发明的优化大数据查询的系统及方法具有以下优点：

1、数据统计分析模块配置于应用服务器端执行，可减少网络通信量：由于在数据库服务器端执行，减少了网络通信和耗时，对于包含大量SQL语句的存储过程，性能比从客户端通过网络逐一调用SQL语句明显提高；

2、数据统计分析模块配置于应用服务器端执行，提高了执行速度：在创建存储过程的时候，数据库已经对其进行了一次解析和优化，存储过程一旦执行，在内存中就会保留这个存储过程，下次再执行同样的存储过程时，可以从内存中直接调用；

3、适应性更强；开发人员可以方便修攻存储过程，而不需要重新编译程序，即使数据库发生改动也不会对应用程序造成影响；

4、哨兵节点之间互相通信自动感知新增或移除缓存节点，当主缓存节点移除之后，能迅速选举产生新的主缓存节点，并重新计算分配迁移内容分块，让缓存集群内的缓存节点总是保存均衡负载，并能保持高可用，自动感知缓存节点并复制数据，让缓存集群保持易于水平扩展，高可用状态。

附图说明

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

下面结合附图对本发明进一步说明。

图1为传统数据查询流程框图；

图2为实施例1一种优化大数据查询的系统数据库响应的原理框图；

图3为实施例1一种优化大数据查询的系统中分布式集群主从模式框图；

图4为实施例1一种优化大数据查询的系统中哨兵集群结构框图；

图5为实施例1一种优化大数据查询的系统中哨兵模式工作原理框图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好地理解本发明并能予以实施，但所举实施例不作为对本发明的限定，在不冲突的情况下，本发明实施例以及实施例中的技术特征可以相互结合。

本发明实施例提供优化大数据查询的系统，用于解决如何提高大数据业务查询及处理速度的技术问题。

实施例1：

本发明一种优化大数据查询的系统，包括数据库服务器、应用服务器、数据统计分析模块、统计分析数据库以及分布式缓存集群，数据统计分析模块配置于应用服务器端执行。

数据库服务器中存储有数据。

数据统计分析模块用于基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中。

应用服务器用于执行如下：接收客户端的申请，基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

本实施例中，数据分析统计模块根据不同的统计维度，比如某地区、某渠道、某服务类型、某办理人等，定时从数据库服务器中查询数据，计算每天的数据量存入统计分析数据库中，客户端的请求到达应用服务器后，应用服务器去访问统计分析数据库数据，返回不同维度、不同时间段的业务数据。从而不用直接访问大数据原始表，减少数据库服务器的压力，更从容的处理高并发下的请求。

本实施例中分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据。

考虑到高并发的情况，缓存服务需要部署Redis集群。由于要保证各个缓存服务的数据共享，因此将架构做成主从架构，一主多从加哨兵模式。主缓存节点负责存储缓存数据，并将缓存数据复制到其它的从缓存节点，而从缓存节点负责读取缓存数据，当主缓存节点服务宕机时，从缓存节点会通过选举产生新的主缓存节点，从而保证服务的高可用性。只有读写分离的架构，才能很轻松实现水平扩容，支撑高并发的请求。

主从模式为：当主缓存节点宕机之后，从缓存节点是可以作为主缓存节点顶上来，继续提供服务的。但是有一个问题，主缓存节点的IP已经变动了，此时应用服务还是基于原主缓存节点的地址去访问，就会导致无法获取缓存数据，针对该问题，哨兵模式起到关键性作用，哨兵实现了自动化的故障恢复。

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

本实施例中哨兵负责监控Redis主缓存节点和从缓存节点进程是否正常工作，当某个节点宕机，哨兵负责发送消息通知给管理员，并自动转移到从缓存节点上。如果发生故障转移，主缓存节点地址变了，应用服务器是无感知的，也不用更改访问地址，因为哨兵才是和应用服务器做交互的。哨兵模式解决了故障转移，在高可用方面又上升了一个新台阶。优化后的请求流程如图2。

哨兵模式的实现流程包括定义主从模式、定义哨兵集群以及定义哨兵节点及主从缓存节点的交互关系三个流程。

对于定义主从模式，如图3所示，Master为主缓存节点，slave为从缓存节点。数据的复制是单向的，只能由主缓存节点到从缓存节点。一旦主缓存节点宕机，会有从缓存节点代替成为新的主缓存节点，并且缓存数据是一致的，丝毫不会影响客户端的访问。

对于定义哨兵集群，在复制的基础上，哨兵实现了自动化的故障恢复，如图4所示，哨兵集群由哨兵节点和数据节点两部分组成。

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。

数据节点：主缓存节点和从缓存节点都是数据节点。

访问redis集群的数据都是通过哨兵集群的，哨兵监控整个redis集群。

哨兵节点及主从缓存节点存在如下交互关系：

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

(1)每个哨兵节点以预定的频率(例如1秒)向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

(2)如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

(3)哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。

本实施例系统工作流程为：

(1)启动数据统计分析模块，计算当天各统计维度数据，储存在统计分析数据库中；

(2)对于应用服务器，应用程序接收到客户端请求后，先查询分布式缓存，如果分布式缓存中缓存有数据则直接返回至客户端，如果分布式缓存中没有对应数据，则从统计分析数据库中读取数据，将写入分布式缓存中主缓存节点，并从分布式缓存中读取数据返回客户端；

(3)主缓存节点把数据同步到从缓存节点，通过key-map方式储存。

(4)当遇到用户访问并发量过大时，从缓存节点自动识别新增缓存节点建立通讯连接；

(5)多个缓存节点提供缓存查询功能，达到所有从缓存节点负载均衡。

本实施例的方法减少了与数据库的I/O的通信次数，并且具备分布式缓存的能力，随着智能制造和大数据项目的推广应用，提高系统实时性、可靠性和可扩展性是智能项目的发展方向，实践证明利用数据缓存技术、服务端缓存技术可以有效提高大数据查询效率，在实际应用中可以同时使用几种方法，达到提高数据查询速度的目的，比如EST接口服务可以同时采用多种缓存技术，提高数据查询效率。

实施例2：

本发明一种优化大数据查询的方法，通过实施例1公开的方法对大数据查询进行优化，该方法包括如下步骤：

S100、基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中

S200、通过应用服务器接收客户端的申请；

S300、基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

本实施例中，根据不同的统计维度，比如某地区、某渠道、某服务类型、某办理人等，定时从数据库服务器中查询数据，计算每天的数据量存入统计分析数据库中，客户端的请求到达应用服务器后，应用服务器去访问统计分析数据库数据，返回不同维度、不同时间段的业务数据。从而不用直接访问大数据原始表，减少数据库服务器的压力，更从容的处理高并发下的请求。

本实施例中分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据。

考虑到高并发的情况，缓存服务需要部署Redis集群。由于要保证各个缓存服务的数据共享，因此将架构做成主从架构，一主多从加哨兵模式。主缓存节点负责存储缓存数据，并将缓存数据复制到其它的从缓存节点，而从缓存节点负责读取缓存数据，当主缓存节点服务宕机时，从缓存节点会通过选举产生新的主缓存节点，从而保证服务的高可用性。只有读写分离的架构，才能很轻松实现水平扩容，支撑高并发的请求。

主从模式为：当主缓存节点宕机之后，从缓存节点是可以作为主缓存节点顶上来，继续提供服务的。但是有一个问题，主缓存节点的IP已经变动了，此时应用服务还是基于原主缓存节点的地址去访问，就会导致无法获取缓存数据，针对该问题，哨兵模式起到关键性作用，哨兵实现了自动化的故障恢复。

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

本实施例中哨兵负责监控Redis主缓存节点和从缓存节点进程是否正常工作，当某个节点宕机，哨兵负责发送消息通知给管理员，并自动转移到从缓存节点上。如果发生故障转移，主缓存节点地址变了，应用服务器是无感知的，也不用更改访问地址，因为哨兵才是和应用服务器做交互的。哨兵模式解决了故障转移，在高可用方面又上升了一个新台阶。优化后的请求流程如图2。

哨兵模式的实现流程包括定义主从模式、定义哨兵集群以及定义哨兵节点及主从缓存节点的交互关系三个流程。

对于定义主从模式，如图3所示，Master为主缓存节点，slave为从缓存节点。数据的复制是单向的，只能由主缓存节点到从缓存节点。一旦主缓存节点宕机，会有从缓存节点代替成为新的主缓存节点，并且缓存数据是一致的，丝毫不会影响客户端的访问。

对于定义哨兵集群，在复制的基础上，哨兵实现了自动化的故障恢复，如图4所示，哨兵集群由哨兵节点和数据节点两部分组成。

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。

数据节点：主缓存节点和从缓存节点都是数据节点。

访问redis集群的数据都是通过哨兵集群的，哨兵监控整个redis集群。

哨兵节点及主从缓存节点存在如下交互关系：

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

(1)每个哨兵节点以预定的频率(例如1秒)向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

(2)如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

(3)哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。

上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。

Claims (8)

1.一种优化大数据查询的系统，其特征在于，包括数据库服务器、应用服务器、数据统计分析模块、统计分析数据库以及分布式缓存集群，数据统计分析模块配置于应用服务器端执行；

所述数据库服务器中存储有数据；

所述数据统计分析模块用于基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中；

所述应用服务器用于执行如下：接收客户端的申请，基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

2.根据权利要求1所述的优化大数据查询的系统，其特征在于，所述分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

3.根据权利要求2所述的优化大数据查询的系统，其特征在于，对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据并提供数据查询；

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

4.根据权利要求2或3所述的优化大数据查询的系统，其特征在于，哨兵集群包括哨兵节点和数据节点，哨兵节点至少一个且不存储数据，主缓存节点和从缓存节点均作为数据节点；

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

每个哨兵节点以预定的频率向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。

5.一种优化大数据查询的方法，其特征在于，通过如权利要求1-4任一项所述的一种优化大数据查询的系统对大数据查询进行优化，所述方法包括如下步骤：

基于采集周期定时从数据库服务器中查询数据，计算采集周期内数据量并将数据存储至统计分析数据库中

通过应用服务器接收客户端的申请；

基于申请、通过预配置的应用程序向分布式缓存集群中查询对应的数据，如果分布式缓存集群中缓存有对应的数据，读取数据并返回客户端，如果分布式缓存集群中未查询到对应的数据，通过应用程序从统计分析数据库中查询对应的数据作为缓存数据写入分布式缓存集群，并从分布式缓存集群中读取对应的数据返回客户端。

6.根据权利要求5所述的优化大数据查询的方法，其特征在于，所述分布式缓存集群为包括一个主缓存节点和多个从缓存节点的主从架构集群，且分布式集群配置有对应的哨兵集群，通过哨兵模式对主缓存节点和从缓存节点进行监控。

7.根据权利要求6所述的优化大数据查询的方法，其特征在于，对于分布式缓存集群，主缓存节点和从缓存节点之间为单向数据交互，主缓存节点用于存储缓存数据、并将缓存数据复制至其他每个从缓存节点，从缓存节点用于读取缓存数据并提供数据查询；

通过哨兵模式监控主缓存节点和从缓存节点的工作，当主缓存节点宕机时，从缓存节点通过选举的方式选出一个新的主缓存节点，并基于哨兵模式将新的主缓存节点的访问地址传递至应用服务器。

8.根据权利要求6或7所述的优化大数据查询的方法，其特征在于，哨兵集群包括哨兵节点和数据节点，哨兵节点至少一个且不存储数据，主缓存节点和从缓存节点均作为数据节点；

哨兵节点以及主缓存节点和从缓存节点之间存在交互关系：

每个哨兵节点以预定的频率向所有的主缓存节点、从缓存节点以及其他哨兵节点实例发送一个PING命令，如果一个哨兵节点实例距离最后一次有效回复PING命令的时间超过预定时间，所述哨兵节点实例被标记为主观下线；

如果一个主缓存节点被标记为主观下线，正在监视所述主缓存节点的所有哨兵节点执行如下：以预定的频率确认所述主缓存节点是否的确进入了主观下线状态，如果一个主缓存节点被标记为主观下线，并且有足够数量的其他哨兵节点在指定的时间范围内同意所述主缓存节点主观下线的判断，所述主缓存节点被标记为客观下线；当没有足够数量的其他哨兵节点同意主缓存节点下线时，主缓存节点的客观下线状态被移除，当主缓存节点重新向哨兵节点的PING命令返回有效回复时，主缓存节点的主观下线状态被移除；

哨兵节点和其他哨兵节点协商主缓存节点的状态，如果主缓存节点处于宕机状态，通过投票的方式在从缓存节点中选取新的主缓存节点，将剩余的从缓存节点指向新的主缓存节点进行缓存数据复制。