一种Druid数据库数据查询方法、装置和计算机设备

摘要

本文提供了一种Druid数据库数据查询方法、装置和计算机设备，其中方法包括：接收用户的数据查询请求；根据所述数据查询请求，获取多个数据库的健康状态，多个所述数据库分别部署在不同园区；根据各所述数据库的健康状态，生成查询优先顺序；根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果；将查询结果反馈给用户。本文提供的方法能够根据用户的数据查询请求获得各个园区的Druid数据库的健康状态，以将数据查询业务下发至健康状态最佳的数据库进行处理，从而极大地避免查询失败的情况，提高查询质量。

说明书

技术领域

本发明涉及数据库技术领域，尤其是一种Druid数据库数据查询方法、装置和计算机设备。

背景技术

德鲁伊数据库(Druid)是一种分布式数据库，由于其能够提供超大数据规模、毫秒级时延的数据查询服务，以及在实时性要求较高的数据查询方面性能优良而得以泛应用。

Druid通常采用单园区(也称为数据中心)部署的方式，然而跨园区部署能够大幅度提高Druid的高可用能力，因此，跨园区Druid部署也逐渐得到人们的关注。现有技术中，跨园区Druid部署通常采用如下方式：1、将Druid所有节点分布部署于多个园区；2、在两个园区分别部署有Druid集群，再通过代理设备代理两个Druid集群。然而，这两种部署方式均存在一些缺陷，具体而言，方式1，在数据摄取阶段时，Druid分多个节点工作，写入深度存储前需进行合并操作，严重浪费跨园区网络带宽，耗时变长，进一步提高管理节点压力，容易造成恶性循环导致整个集群宕机；且Druid的依赖模块，诸如HDFS(Hadoop DistributedFile System，Hadoop分布式文件系统)等不支持跨园区部署，这些模块若宕机会导致整个Druid集群宕机，使得Druid高可用能力不足。而方式2中，由于代理设备只能探寻到Druid集群是否处于宕机状态，对于其中部分节点下线的情况，依然会默认Druid能正常工作，然后对Druid集群轮询以完成数据查询业务。此时Druid集群虽未宕机，但可能出现数据时有时无的情况，使得查询结果质量差。

针对现有技术存在的上述缺陷，本文旨在提供一种Druid数据库数据查询方法、装置和计算机存储设置，能够有效提高数据查询准确性和数据查询成功率。

发明内容

针对现有技术的上述问题，本文的目的在于，提供一种Druid数据库数据查询方法、装置和计算机设备，以解决现有技术中数据查询结果失败率高、质量差的缺陷。

为了解决上述技术问题，本文的具体技术方案如下：

一方面，本文提供一种Druid数据库数据查询方法，包括：

接收用户的数据查询请求；

根据所述数据查询请求，获取多个数据库的健康状态，所述数据库分别部署在不同园区；

根据各所述数据库的健康状态，生成查询优先顺序；

根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果；

将查询结果反馈给用户。

具体地，所述根据所述查询需求信息，获取多个数据库的健康状态，包括：

解析所述数据查询请求，获得所述数据查询请求所需的第一数据存储单元；

统计各数据库对应的所述第一数据存储单元的第一维度基数信息；

根据各数据库的所述第一维度基数信息，得到各所述数据库的数据健康状态。

优选地，所述获取多个数据库的健康状态，还包括：

以预设的筛选规则，获取各所述数据库的第二数据存储单元；

统计各数据库对应的所述第二数据存储单元的第二维度基数信息；

根据各数据库的所述第二维度基数信息，得到各所述数据库的数据健康状态。

具体地，所述根据所述数据查询请求，获取多个所述数据库的健康状态，还包括：

根据所述数据查询请求，获取各所述数据库的节点健康状态。

进一步地，所述获取各所述数据库的节点健康状态，包括：

获取各所述数据库节点的工作状态，所述节点包括中间管理节点、历史节点、路由节点、查询节点、霸主节点和协调节点；

根据所述节点的工作状态，获取所述节点健康状态。

更进一步地，所述根据所述节点的工作状态，获取所述节点健康状态，包括：

当所述中间管理节点、所述历史节点、所述路由节点、所述查询节点和所述霸主节点和所述协调节点的工作状态均在线时，所述节点健康状态为正常工作状态；

当所述中间管理节点、所述历史节点、所述路由节点、所述查询节点中的一个或多个下线时，所述节点健康状态为亚健康状态；

当所述霸主节点和/或所述协调节点下线时，所述节点健康状态为宕机状态。

具体地，所述获取多个数据库的健康状态，还包括：

获取各所述数据库的业务处理量健康状态和硬件健康状态。

具体地，所述根据各所述数据库的健康状态，生成查询优先顺序，包括：

根据所述节点健康状态、所述数据健康状态、所述业务处理量健康状态和所述硬件健康状态，生成所述查询优先顺序。

另一方面，本文还提供一种Druid数据库数据查询装置，包括：

接收单元，用于接收用户的数据查询请求；

获取单元，用于根据所述数据查询请求，获取多个数据库的健康状态，所述数据库分别部署在不同园区；

查询优先顺序生成单元，用于根据各所述数据库的健康状态，生成查询优先顺序；

查询单元，用于根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果；

反馈单元，用于将查询结果反馈给用户。

另一方面，本文还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述技术方案所述的方法步骤。

采用上述技术方案，本文所述的一种Druid数据库数据查询方法、装置和计算机设备，能够满足于跨园区部署的Druid数据库的数据查询需求，能够根据用户的数据查询请求获得各个园区的Druid数据库的健康状态，以将数据查询业务下发至健康状态最佳的数据库进行处理，从而极大地避免查询结果抖动造成的查询失败的情况，提高查询质量。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1示出了本文实施例提供的一种Druid数据库数据查询方法的流程示意图；

图2示出了本文实施例提供的一种获取数据库的数据健康状态的方法流程图；

图3示出了本文实施例提供的另一种获取数据健康状态的方法流程图；

图4示出了本文实施例提供的一种获取数据库节点健康状态的方法流程图；

图5示出了本文实施例提供的一种Druid数据库数据查询装置的结构示意图；

图6(a)示出了Druid数据库数据查询方法的一种应用场景示意图；

图6(b)示出了Druid数据库数据查询方法的另一种应用场景示意图；

图7示出了本文实施例提供的一种计算机设备的示意图。

附图符号说明：

51、接收单元；

52、获取单元；

53、查询优先顺序生成单元；

54、查询单元；

55、反馈单元；

702、计算机设备；

704、处理器；

706、存储器；

708、驱动机构；

710、输入/输出模块；

712、输入设备；

714、输出设备；

716、呈现设备；

718、图形用户接口；

720、网络接口；

722、通信链路；

724、通信总线。

具体实施方式

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

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

德鲁伊数据库(Druid)是一种分布式数据库，由于其能够提供超大数据规模、毫秒级时延的数据查询服务，以及在实时性要求较高的数据查询方面性能优良而得以泛应用。Druid通常采用单园区(也称为数据中心)部署的方式，然而跨园区部署能够大幅度提高Druid的高可用能力，因此，跨园区Druid部署也逐渐得到人们的关注。现有技术中，跨园区Druid部署通常采用如下方式：1、将Druid所有节点分布部署于多个园区；2、在两个园区分别部署有Druid集群，再通过代理设备代理两个Druid集群。然而，这两种部署方式均存在一些缺陷，具体而言，方式1，在数据摄取阶段时，Druid分多个节点工作，写入深度存储前需进行合并操作，严重浪费跨园区网络带宽，增加耗时，进一步提高管理节点压力，容易造成恶性循环导致整个集群宕机；且Druid的依赖模块，诸如HDFS(Hadoop Distributed FileSystem，Hadoop分布式文件系统)等不支持跨园区部署，这些模块若宕机会导致整个Druid集群宕机，使得Druid高可用能力不足。而方式2中，由于代理设备只能探寻到Druid集群是否处于宕机状态，对于其中部分节点下线的情况，依然会默认Druid能正常工作，然后对Druid集群轮询以完成数据查询业务。此时Druid集群虽未宕机，但可能出现数据时有时无的情况，使得查询结果质量差。轮询是指当代理机构获知两个Druid集群均未宕机时，将本次数据查询请求业务下发至与上一次未执行数据查询业务的一个Druid集群，即两个Druid集群轮流执行数据查询。

为了解决上述问题，本文实施例提供了一种Druid数据库数据查询方法，能够提高数据查询的准确性，提高用户满意度。图1是本文实施例提供的一种Druid数据库数据查询方法的流程示意图，所述方法适用于跨园区部署的Druid数据库系统，所述系统包括至少两个园区，每个所述园区均设置有Druid数据库。需要说明的是，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图1所示，所述方法可以包括：

S101：接收用户的数据查询请求；

S102：根据所述数据查询请求，获取多个数据库的健康状态，多个所述数据库分别部署在不同园区；

即本说明书实施例中，所述Druid数据库跨园区部署，每个园区均部署有一Druid数据库，除此之外，如图6(a)和图6(b)所示，为本说明书实施例提供的查询方法的应用场景示意图，每个园区还均设有Druid数据库的依赖模块，包括zookeeper，其作用为注册中心，存储Druid数据库的元数据，维持druid集群的运行；HDFS，作用为深度存储，实现冷数据容灾备份，还可以用于传递数据；MySQL，是一种关系型数据库管理系统，提供Druid数据库管理控制台查询；以及未显示在附图中的一些其他依赖，例如：Kafka，提供Druid数据库实现数据摄取。

S103：根据各所述数据库的健康状态，生成查询优先顺序；

S104：根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果；

即将各个园区的数按照其各自的健康状态从优到劣进行排序，将数据查询业务下发至健康状态最优的园区对应的数据库中；

S105：将查询结果反馈给用户。

本说明书实施例提供的一种Druid数据库数据查询方法，适用于跨园区部署的Druid数据库，在接收到用户发出的数据查询请求后，根据具体的数据查询请求获得各个园区的Druid数据库的健康状态，以将数据查询业务下发至健康状态最佳的数据库进行处理，能够极大地避免查询结果抖动，提高查询质量。

需要说明的是，本说明书实施例中，各所述园区的数据库的数据摄取均相同，即预先存储在各园区Druid数据库中的数据均相同，各园区数据库的服务器对等。由于本说明书实施例中。Druid数据库能够跨园区部署，因此与将Druid所有节点分布部署于多个园区的现有技术相比，能够极大地提高Druid数据库系统的高可用性。

数据库的健康状态包括数据库的数据健康状态，如图2所示，示出了获取数据库的数据健康状态的方法流程图，则步骤S102：根据所述数据查询请求，获取多个数据库的健康状态，具体包括：

S201：解析所述数据查询请求，获得所述数据查询请求所需的第一数据存储单元；

即第一数据存储单元与用户的数据查询请求相对应，Druid数据库中，数据存储于数据存储单元(也称为表)中。例如，用户的数据查询请求为查询员工信息，并解析得到该数据查询请求所需的数据位于数据存储单元a中。

在一些实施例中，对所述数据查询请求进行解析，还可以获得所述数据查询请求所需的时间信息，例如，对于“查询2020年入职的员工信息”的数据查询请求，则可以利用时间信息对数据存储单元进行删选，不必筛选建档时间早于2020年的数据存储单元，有利于提高对数据查询请求的响应速度。

S202：统计各数据库对应的所述第一数据存储单元的第一维度基数信息；

由于各数据库预先的数据摄取任务均相同，因此，此时对各数据库中的数据存储单元a的第一维度基数信息进行统计。

例如，数据存储单元a是一个员工信息统计表，其中存储有时间列、维度列和指标列等信息，其中时间列表征表a的时间戳，可用于表征该数据存储单元a的建档时间；维度列包括员工信息，例如员工编号信息、员工姓名信息、员工年龄信息、所在部门信息等；指标列表示需要聚合的数字，如成功次数，失败次数，点击量等等，可用于表征该数据存储单元a被引用或查询次数。

则所述数据存储单元的第一维度基数信息进行统计，具体是指对该数据存储单元a中的维度列的数量或其排列组合的数量进行统计，所述第一维度基数信息可用于表征其存储的数据的丰富程度。除此之外，还可以根据所述数据存储单元的体积量来判断。

S203：根据各所述数据库的第一维度基数信息，得到所述数据库的数据健康状态。

例如，对于其中一个园区的数据库(记为第一园区，数据库A)查询统计到其数据存储单元a的第一维度基数为4，另一个园区的数据库(记为第二园区，数据库B)中相应的数据存储单元a丢失了员工姓名信息，得到第一维度基数为3。则可根据各数据库中数据存储单元a的第一维度基数信息得到各数据库的健康状态，例如，根据第一维度基数信息对数据库的数据健康状态进行评分评级等。

进而根据数据库的健康状态，具体是数据健康状态，生成各数据库的查询优先顺序时，则可将各数据库的第一维度基数值进行比较：由于数据库A对应的第一维度基数为4大于数据库B对应的第一维度基数3，则可知数据库A的数据健康状态要优于数据库B的数据健康状态，则查询优先顺序为：数据库A优先于数据库B。需要说明的是，所述园区和其对应的数据库的数量可以不止有两个，此处仅以数据库A和数据库B进行举例说明，对于数据库数量更多的情况与数据库数量为两个的情况相类似。

需要说明的是，本说明书实施例中，对数据存储单元进行统计得到第一维度基数信息可通过Druid数据库的查询节点(Broker)实现。

因此，本说明书实施例中，可根据各数据库第一维度基数的值对各数据库的数据健康状态进行排序，以将数据查询请求下发至数据健康状态最佳的一个数据库中执行。

在一些可能的实施例中，第一数据存储单元可以包括多个数据存储单元，即需联立多个数据存储单元才能满足用户的数据查询需求，例如，所需的数据包括存储于数据存储单元a和存储于数据存储单元b的数据。则优选地，分别对数据库A和数据库B查询这两个数据存储单元的第一维度基数信息。若查询到数据库A相较于数据库B而言，其中数据存储单元a的信息更完善，而数据存储单元b的信息存在缺失，则从数据库A中查询数据存储单元a的数据并从数据库B中查询数据存储单元b的数据，协同完成用户的数据查询请求。

本说明书实施例提供的一种Druid数据库数据查询方法，能够根据用户数据查询请求，对各数据库中存储所需数据的第一数据存储单元的健康状态进行分析，以利用数据信息更全面的数据库或数据库的组合来完成数据查询业务，使得数据查询的结果能够更加准确，提高数据查询质量。

如图3所示，在一些优选的实施例中，获取多个数据库的健康状态还可以包括：

S301：以预设的筛选规则，获取各所述数据库的第二数据存储单元；

即所述第二数据存储单元与预设的筛选规则相对应，所述预设的筛选规则可以是，通过数据存储单元的建档时间进行筛选，例如：每隔一时间间隔则随机生成一个时间段条件，获取每个数据库对应的满足这个时间段条件的一个或多个数据存储单元。当然了，所述预设的筛选规则还可以有多种，例如：以数据存储单元对应的项目进行筛选、以数据存储单元中存储的数据的来源进行筛选等等。

S302：统计各数据库对应的所述第二数据存储单元的第二维度基数信息；

即对步骤S301中获得的第二数据存储单元以数据库为单位进行统计，例如，对于满足预设筛选条件X的第二数据存储单元(所述第二数据存储单元可以是一个数据存储单元或由多个数据存储单元组成)，统计第二数据存储单元的维度列的项数或其排列组合的数量，即为第二维度基数信息。

S303：根据各数据库的所述第二维度基数信息，得到各所述数据库的数据健康状态。

即分别获取第一园区数据库A和第二园区数据库B对应的第二维度基数信息，进而在根据各数据库的健康状态，生成查询优先顺序时，以第二维度基数信息的具体大小生成所述查询优先顺序：若第一园区数据库A的第二维度基数信息的维度列项数大于第二园区数据库B对应的第二维度基数信息的维度列项数，则说明数据库A的数据健康状态要优于数据库B的健康状态。

即本说明书实施例中，随机选择一个或一组数据存储单元进行维度列项数统计，以实时地对数据库的数据健康状态有全局性的掌控。从而在接收到用户发送的数据查询请求时，优先将数据查询请求发送给数据健康状态最佳的一个的数据库，可以避免将数据查询请求发送至发生数据严重丢失的数据库中的情况，能够提高数据查询请求的响应和执行效率。

以上对一个或一组数据存储单元的维度列项数统计得到第二维度基数信息以对数据库的数据健康状态进行评估，可以执行在步骤S201：解析所述数据查询请求，获得所述数据查询请求所需的第一数据存储单元之前，也可以与步骤S201同时执行，还可以执行在步骤S201之后。

在一些可行的实施例中，数据库的健康状态包括数据库的数据健康状态和节点健康状态，则步骤S102：根据所述数据查询请求，获取多个数据库的健康状态，除了查询各园区的数据库的数据健康状态外，还包括：

根据所述数据查询请求，获取各园区对应的所述数据库的节点健康状态。

如图4所示，获取各园区对应的所述数据库的节点健康状态，进一步包括：

S401：获取各数据库的节点工作状态，所述节点包括中间管理节点、历史节点、路由节点、查询节点、霸主节点和协调节点；

其中，所述中间管理节点(Middle Manager)，在Druid数据库中可用于负责数据摄取，提供实时的数据查询，以及通过HDFS(分布式文件系统)定时将数据传递至历史节点；所述历史节点(Historical)，可用于从HDFS读取中间管理节点的持久化数据，代理这些数据的查询业务，以及接收协调节点的数据加载与删除指令；所述路由节点(Router)，代理查询节点、霸主节点和协调节点的API，提供管理页面；所述查询节点(Broker)，可用于接收查询请求，分析查询请求所需数据所在位置，指定查询计划；所述霸主节点(Overload)，用于负责数据摄取任务的分配和管理，实现数据摄取的负载均衡；和所述协调节点(Coordinator)，用于管理数据存储，实现历史节点存储负载均衡。

在本说明书实施例中，所述各节点的工作状态可通过查询各节点在zookeeper的注册信息(节点存活列表)获得，所述zookeeper能够对节点存活列表进行更新，以实时地对各节点的工作状态进行监控。

S402：根据所述节点工作状态，获取所述节点健康状态。

步骤S402：根据所述节点的工作状态，获取所述节点健康状态，具体为：

当所述中间管理节点、所述历史节点、所述路由节点、所述查询节点和所述霸主节点和所述协调节点的工作状态均在线时，所述节点健康状态为正常工作状态；

当所述中间管理节点、所述历史节点、所述路由节点、所述查询节点中的一个或多个下线时，所述节点健康状态为亚健康状态；

当所述霸主节点和/或所述协调节点下线时，所述节点健康状态为宕机状态。

根据各园区对应的数据库的节点健康状态进行排序，正常工作状态优于亚健康状态，亚健康状态优于宕机状态；

当园区的数量较多时，可能有多个园区其数据库的节点健康状态相同，例如均为正常工作状态，或均为亚健康状态；而本说明书实施例提供的Druid数据库数据查询方法，能够在以节点健康状态的基础上，结合以数据健康状态对各数据库进行排序，使得选择出各方面健康状态均最佳的数据库来执行数据查询业务，提高数据查询服务质量。

若仍有两个或两个以上的数据库，其节点健康状态和数据健康状态均相同，则进一步地，本说明书实施例提供的一种Druid数据库数据查询方法，其中，步骤S102：根据所述数据查询请求，获取各所述园区的数据库的健康状态，还包括：

S501：根据所述查询需求信息，获取各所述园区数据库的业务处理量健康状态和硬件健康状态。

其中，业务处理量健康状态是指，各园区对应的数据库当前处理的数据查询请求的数量；例如，第一园区数据库A当前处理的数据查询请求的业务数量为100，而第二园区数据库B当前处理的数据查询请求的业务数量为90，则说明数据库A较数据库B而言更加繁忙，则在数据库A和数据库B的节点健康状态和数据健康状态均相等的前提下，将用户新发送的数据查询请求下发给第二园区的数据库B来执行。

硬件健康状态是指，各数据库为应当数据查询请求的服务器占用(或空闲)情况。例如，为应对当前的数据查询请求，第一园区数据库A的服务器占用率为90％，第二园区数据库B为应对其当前处理的数据查询请求，服务器占用率为92％，则说明，数据库A更有能力来应对新的数据查询请求，因此将新的数据查询请求下发给第一园区的数据库A来执行。所述硬件健康状态还可以通过获取内存占用情况等其他指标或结合多个硬件指标来获得。

因此，优选地，本说明书实施例中，步骤S104：根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果，进一步为：

根据所述节点健康状态、所述数据健康状态、所述业务处理量健康状态和所述硬件健康状态，生成所述查询优先顺序。

当Druid数据库的依赖设备的工作状态欠佳时，也会对Druid数据库的健康状态造成影响，因此，在一些优选的实施例中，所述获取多个数据库的健康状态，还可以包括：获取各园区内，Druid数据库与其依赖设备之间的依赖关系健康状态。例如：获取HDFS与zookeeper之间的依赖关系、Druid数据库与HDFS之间依赖关系等的健康状态。

综上，本说明书实施例提供的Druid数据库数据查询方法，能够综合节点健康状态、数据健康状态、业务处理量健康状态和硬件健康状态等多个维度对数据库的健康状态进行评估，粒度更细对数据库健康状态的评估也更加准确。

由于现有技术中通过端口探活的方式并不能获得各数据库详细的健康状态(端口探活只能获知数据库是否宕机)，比如当其查询节点工作正常而数据发生丢失导致数据健康状态欠佳时，仍会将用户的数据查询请求下发给数据库执行，会导致查询结果抖动，即数据时有时无的情况。而本说明书实施例中能够根据用户的数据查询请求，对数据库按其健康状态进行排序，从而将数据查询请求下发至健康状态最佳的一个数据库处进行执行，因此，与现有技术相比，本说明书中提供的查询方法能够使得健康状态最佳的数据库来处理查询业务，能够极大地提高查询结果的准确性，提高数据查询成功率，提高用户满意度。

如图5所示，本说明书实施例还提供一种Druid数据库数据查询装置，包括：

接收单元51，用于接收用户的数据查询请求；

获取单元52，用于根据所述数据查询请求，获取多个数据库的健康状态，所述数据库分别部署在不同园区；

查询优先顺序生成单元53，用于根据各所述数据库的健康状态，生成查询优先顺序；

查询单元54，用于根据所述查询优先顺序，选择健康状态最优的所述数据库进行数据查询，得到查询结果；

反馈单元55，用于将查询结果反馈给用户。

对应于图6(a)所示的一种应用场景，本说明书实施例还提供一种Druid数据库系统，所述系统包括至少包括第一园区和第二园区，所述第一园区和第二园区均设置有数据库以及所述数据库的依赖设备；所述系统还设置有查询前置装置，所述查询前置装置分别与各园区的数据库建立通讯连接。

所述查询前置装置包括第一接收模块、第一解析模块、第一监控模块、第一代理模块和第一反馈模块；

所述第一接收模块用于接收用户的数据查询请求；

所述第一解析模块对用户的数据查询请求进行解析，获得数据查询需求信息；例如，获得所述数据查询请求所需的数据存储单元等。

所述第一监控模块用于根据所述数据查询需求信息，获取各数据库的健康状态，并根据各数据库的健康状态生成数据库查询优先顺序；所述数据库的健康状态包括节点健康状态、所述数据健康状态、所述业务处理量健康状态和所述硬件健康状态。

所述第一代理模块用于根据所述数据库查询优先顺序，将所述数据查询请求分配至健康状态最佳的数据库中，并得到查询结果；

所述第一反馈模块用于将查询结果反馈给用户。

对应于图6(b)所示的一种应用场景，本说明书实施例还提供一种Druid数据库系统，所述系统包括至少包括第一园区和第二园区，所述第一园区和第二园区均设置有数据库、查询前置装置以及所述数据库的依赖设备；所述查询前置装置和与之对应的各园区的数据库建立通讯连接，属于不同园区的查询前置装置通信连接。

所述查询前置装置包括第二接收模块、第二解析模块、第二监控模块、第二代理模块、第二反馈模块和通信模块；

所述第二接收模块用于接收用户的数据查询请求；

所述第二解析模块对用户的数据查询请求进行解析，获得数据查询需求信息；

所述第二监控模块用于根据所述数据查询需求信息，获取各数据库的健康状态；

所述通信模块用于与其他园区的查询前置装置进行交互，以获知其他各个数据库的健康状态；

所述第二监控模块还用于根据通信模块交互得到的各数据库的健康状态，生成数据库查询优先顺序；所述数据库的健康状态包括节点健康状态、所述数据健康状态、所述业务处理量健康状态和所述硬件健康状态。

所述第二代理模块用于根据所述数据库查询优先顺序，将所述数据查询请求分配至健康状态最佳的数据库中，并得到查询结果；

所述第二反馈模块用于将查询结果反馈给用户。

本说明书实施例提供的Druid数据库系统，设置有查询前置装置，不仅实现了数据库高可用性，并且能够应对用户的数据查询请求根据各数据库的健康状态生成择优数据，使得健康状态最优的数据库来执行查询业务，避免查询结果抖动提高查询结果的准确性。

本说明书实施例提供的Druid数据库系统在各个园区均配置有依赖设备，因此可以避免在多园区搭建Druid数据库时依赖设备跨园区带来的安全可靠性问题，并且能够保证数据摄取速度，有利于减轻中间管理节点工作压力。

如图7所示，为本文实施例提供的一种计算机设备，所述计算机设备702可以包括一个或多个处理器704，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备702还可以包括任何存储器706，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器706可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备702的固定或可移除部件。在一种情况下，当处理器704执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备702可以执行相关联指令的任一操作。计算机设备702还包括用于与任何存储器交互的一个或多个驱动机构708，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备702还可以包括输入/输出模块710(I/O)，其用于接收各种输入(经由输入设备712)和用于提供各种输出(经由输出设备714))。一个具体输出机构可以包括呈现设备716和相关联的图形用户接口718(GUI)。在其他实施例中，还可以不包括输入/输出模块710(I/O)、输入设备712以及输出设备714，仅作为网络中的一台计算机设备。计算机设备702还可以包括一个或多个网络接口720，其用于经由一个或多个通信链路722与其他设备交换数据。一个或多个通信总线724将上文所描述的部件耦合在一起。

通信链路722可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路722可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图1-图4中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1至图4所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。