CN104408110B - 数据请求的方法、装置及系统 - Google Patents

Abstract

本发明公开了一种数据请求的方法、装置及系统，涉及互联网技术领域，为解决数据库因查询请求过多而发生瘫痪的问题而发明。本发明的方法包括：建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果；在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向第一协程获取检测结果；若检测结果表征数据库处于超负荷状态，则停止向数据库转发查询请求。本发明主要应用于postgresql数据库系统中。

Description

数据请求的方法、装置及系统

技术领域

本发明涉及互联网技术领域，尤其涉及一种数据请求的方法、装置及系统。

背景技术

在局域网内部，控制台作为终端与数据库之间的桥梁，负责接收、管理、转发终端向数据库发送的查询请求，并将数据库返回的查询内容下发给终端。通常数据库服务器分配给查询任务的处理资源是有限的，而局域网内瞬时上报的查询请求数量(后续简称为请求并发数)则有可能较大，这种情况下，数据库服务器的处理资源无法对所有的查询请求都进行响应，此时数据库的资源负荷压力较大，容易发生瘫痪。而一旦数据库发生瘫痪就无法进行恢复，只能重启数据库服务器，从而对局域网的正常运行造成中断。

随着大型企业、机关单位对局域网规模需求的不断增长，局域网中的终端数量将越来越多，网内的查询请求数量也会相应增长，因此数据库瘫痪的频率会越来越高。对于大型网络，特别是多级网络而言，数据库系统的频繁瘫痪势必会影响到网络的稳定性，降低局域网的运行效率。所以，如何对数据库系统进行有效维护，使其能够应对大规模网络环境下的查询需求，就成为摆在技术人员眼前的一道难题。

发明内容

有鉴于此，本发明提供一种数据请求的方法、装置及系统，能够解决数据库因查询请求过多而发生瘫痪的问题。

为解决上述技术问题，一方面，本发明提供了一种数据请求的方法，该方法包括：

建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果；

在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向第一协程获取检测结果；

若检测结果表征数据库处于超负荷状态，则停止向数据库转发查询请求。

另一方面，本发明还提供了一种数据请求的装置，该装置包括：

检测单元，用于建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果；

获取单元，用于在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向检测单元建立的第一协程获取检测结果；

处理单元，用于当获取单元获取的检测结果表征数据库处于超负荷状态时，停止向数据库转发查询请求。

再一方面，本发明还提供了一种数据请求的系统，该系统包括：终端、控制台以及数据库服务器；其中，控制台包括如前述第二方面所指的装置；

终端，用于向控制台上报查询请求，查询请求用于向数据库服务器请求进行数据查询；

控制台，用于在检测结果表征数据库处于正常负荷状态时，向数据库服务器转发查询请求，而在检测结果表征数据库处于超负荷状态时，停止向数据库服务器转发查询请求；

数据库服务器，用于在检测结果表征数据库处于正常负荷状态时，接收控制台转发的查询请求，并对查询请求进行响应，返回查询内容；

控制台，还用于接收数据库服务器返回的查询内容，并将查询内容下发给终端。

本发明提供的数据请求的方法、装置及系统，能够建立一个常驻的第一协程对数据库的负荷状态进行持续检测，并将获得的检测结果共享给为查询请求建立的第二协程，以便后者基于不同的检测结果对查询请求进行转发或取消转发的处理。与现有技术相比，本发明可以在数据库处于超负荷状态时暂停查询请求的转发，能够给予数据库充分的时间对已有请求进行及时处理并释放相应的处理资源，由此防止数据库因查询请求过多而发生瘫痪。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明提供的一种数据请求的方法流程图；

图2示出了本发明提供的另一种数据请求的方法流程图；

图3示出了本发明提供的又一种数据请求的方法流程图；

图4示出了本发明提供的等待队列的示意图；

图5(a)及图5(b)示出了本发明提供的混合转发查询请求的示意图；

图6示出了本发明提供的一种数据请求的装置的结构示意图；

图7示出了本发明提供的另一种数据请求的装置的结构示意图；

图8示出了本发明提供的一种数据请求的系统示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为防止数据库因查询请求过多而发生瘫痪，本发明实施例提供了一种数据请求的方法，该方法能够在数据库处于超负荷状态时暂停查询请求的转发，由此使得数据库有充分的时间对已有请求进行处理。如图1所示，该方法包括：

101、建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果。

在启动数据库时，控制台建立一个独立的第一协程，专门用于对数据库的负荷状态进行检测。本实施例中的第一协程为一种常驻协程，即该协程在数据库初始化时建立、并存活于整个数据查询的过程中。无论控制台是否接收终端上报的查询请求，只要数据库的生命周期没有结束，那么第一协程就会一直保持存活状态，对数据库的资源负荷状态进行持续检测。

需要说明的是，本实施例中所述的持续检测，是指一种保持检测状态的过程，并非限定于不间断检测的情况。在实际应用中，上述持续检测的方式还包括：按照某个预设的时间间隔进行周期性检测、或者根据控制台的指令进行不定期检测、再或者基于某种预设策略/规则进行自动检测等，本实施例不对第一协程检测数据库状态的时机、次数或者频率进行限制。

在本实施例中，能够反映数据库资源负荷状态的资源参数可以是：内存使用占比、中央处理器(Central Processing Unit，简称CPU)使用占比、磁盘读写接口使用占比等。当然，资源参数也可以是上述几种资源参数的组合。第一协程可以通过预先写好的接口程序向数据库发送数据请求，获取上述资源参数(或资源参数的组合)，并通过与预设标准阈值比对的方式获得数据库负荷状态的检测结果。

一般情况下，数据库服务器通常不会将全部的处理资源都分配给数据查询任务，因此在实际应用中，上述各资源参数的使用占比应当是其实际资源分配范围下的使用占比。例如，假设对于4G内存的数据库服务器而言，如果其分配1G内存资源用于处理查询请求，那么当当前处理查询请求占用0.4G内存时，其实际的内存使用占比应当为40％，而非10％。

上述获取资源参数的检测方式只是本实施例的一种实现方式之一，实际应用中，控制台也可以不必关心数据库的具体资源参数，而是从结果层面直接对数据库的响应速度进行检测，若数据库的响应速度过慢(用时较长)，则表明数据库的资源负荷超过了正常承受能力。换言之，数据库的响应速度能够综合体现其内部各种资源的占用情况，因此在实际应用中，对响应速度进行测试通常实现起来更为简便，并且能够获得更加理想的检测效果。本实施例后续将着重以此种检测方式为例进行说明。

在本实施例中，控制台获取的检测结果可以具有不同的表现形式。在本实施例的一种实现方式中，检测结果可以是一个能够描述数据库负荷状态的档位等级，例如“空闲”、“繁忙”、“饱和”、“过载”等，不同的档位用于反映数据库不同的负荷程度；或者在本实施例的另一种实现方式中，检测结果也可以是一个简单的数值，例如45、67等，该数值的大小用于反映数据库的负荷程度，对于这种形式，需要保证该数值具有一个存在边界的取值区间，该区间的上下边界应当对应数据库的两种极端负荷程度(例如0负荷及过载等)。而为了简化实际应用中的实施，在本实施例的第三种实现方式中，检测结果仅分为“正常负荷状态”与“超负荷状态”两档，两档之间的界限可由管理员结合网络规模、数据库性能等因素综合考虑并设定得出，也可以由控制台根据预设的规则策略自行计算得出，并可进行动态调整。由于便于实现，因此本实施例后续将以第三种形式的检测结果为例进行说明。

102、在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向第一协程获取检测结果。

与现有技术中控制台直接将查询请求转发给数据库不同，本实施例中，控制台在向数据库转发查询请求之前，首先需要通过对应该请求的第二协程向第一协程获取数据库状态的检测结果，当数据库处于超负荷状态时，执行下述步骤103，停止转发查询请求，由此减轻数据库的负荷压力。

本步骤中的第二协程是针对查询请求建立的、并独立于前述第一协程的协程。控制台接收到几条查询请求就建立几条第二协程，各条第二协程之间没有实质关联。本实施例中，第二协程基于查询请求的上报而建立，在查询请求获得查询响应后或查询终止时结束，相对于第一协程的存活周期而言，第二协程的存活周期通常较短。

本实施例中，第一协程专用于检测数据库的负荷状态，不负责向第二协程发送检测结果，因此，第二协程在向数据库转发查询请求时，需要主动向第一协程索取检测结果。实际应用中，控制台侧的请求并发数通常较多，因此每个查询请求对应的第二协程需要分别向第一协程索取检测结果，各条协程索取检测结果的动作是相互独立的，本实施例不限定所有第二协程同时索取检测结果。此外，如前所述，第一协程对数据库的检测是持续性的，基于数据库负荷状态的不断变化，第一协程在不同时间获取的检测结果可能存在差异，而第二协程索取检测结果的时机各自不同，因此实际应用中，不同第二协程获取的检测结果可能不同，例如，请求1的第二协程在前一时段获取的检测结果为“超负荷状态”，而请求2的第二协程在下一时段获取的检测结果则为“正常负荷状态”。基于不同的检测结果，不同查询请求的处理结果当然各有不同。

103、若检测结果表征数据库处于超负荷状态，则停止向数据库转发查询请求。

当第二协程获取的检测结果为数据库处于超负荷状态时，控制台停止将该第二协程对应的查询请求发送给数据库。对于该查询请求的后续处理，在本实施例的一种实现方式中，控制台可以将该查询请求丢弃，并通知终端，对于终端而言，相当于本次查询流程结束；而在本实施例的另一种实现方式中，控制台也可以“挂起”该查询请求，当数据库的负荷压力减轻时再转发给数据库。

本步骤中，控制台可以单独建立一个处理协程执行丢弃或挂起请求的操作，实际应用中，控制台可以为每个需要处理的请求单独建立一个处理协程，并在处理完成后结束该处理协程，也可以常驻一个总协程，由该总协程统一对各个查询请求进行处理。

实际应用中，无论单独建立处理协程还是建立总协程，都会占用控制台一部分处理资源。为尽量避免控制台处理资源的无谓开销，在本实施例的一种实现方式中，控制台可以利用已有的第二协程执行丢弃、挂起请求等操作。

104、若检测结果表征数据库处于正常负荷状态，则向数据库转发查询请求。

对于步骤102中获取的检测结果，如果其表征数据库处于正常负荷状态，那么表示数据库的处理资源存在部分闲置，不会因为进一步增加查询请求而发生瘫痪，因此在此情况下，控制台可以将接收的查询请求发送给数据库进行响应，并将数据库返回的查询内容转发给终端，由此完成一次常规的数据查询流程。

与步骤103相似的，在本实施例的一种实现方式中，控制台也可以通过对应请求的第二协程完成发送查询请求、转发查询内容等操作。

现有技术中，控制台作为终端与数据库之间的中介，仅负责将终端上报的查询请求发送给数据库进行处理，即使数据库的处理资源告急，出现较大的负荷压力，控制台也不会停止发送查询请求。因此数据库很容易因为资源负荷过大发生瘫痪，而一旦数据库发生瘫痪就无法进行恢复，只能对数据库服务器进行重启，由此使局域网的正常运行被中断。而在本实施例中，控制台可以对数据库的负荷状态进行检测，当数据库负荷过大时，暂停发送查询请求，由此给予数据库消化已有请求的机会，防止数据库瘫痪，进而提高局域网运行的稳定性。

其次，在本实施例中，控制台能够通过一个常驻的第一协程对数据库进行持续检测，第二协程直接向第一协程“索取”检测结果即可进行后续的处理操作。从技术实现的角度看，第二协程也能够直接对数据库进行检测，但是由于第二协程的数量较多，大量重复的检测操作势必会浪费控制台有限的处理资源。本实施例能够通过“结果共享”的设计思路降低相似操作的重复执行，可以最大限度减少控制台的资源开销。

第三，与现有技术中通过进程或线程执行相应操作相比，本实施例能够通过更为轻量级的协程执行各类操作。由于协程属于纯后台执行的程序，终端前台或数据库服务器完全感知不到其操作的执行，因此除能够节省线程资源外，采用协程还可以降低执行操作对业务运行的影响。

进一步的，作为对图1步骤101的细化，在本发明的另一实施例中，控制台可以通过第一协程对数据库的响应速度进行检测，从而获得能够综合反映数据库资源状态的检测结果。具体的如图2所示，该方式包括：

201、通过第一协程向数据库发送状态检测报文。

该状态检测报文在报文格式上与传统的数据报文相同，其报头需要携带控制台及数据库的IP地址，以分别作为源IP地址和目的IP地址。但与传统数据报文不同的是，该状态检测报文仅用于测试数据库的响应速度，其数据内容对于状态而言并无实际意义，因此管理员可以随意设置报文的数据内容，例如将其数据内容设置为“Hello DB”或者“Test”。

需要说明的是，由于状态检测报文的内容无实际意义，因此从节省网络传输带宽的角度考虑，报文的数据内容不应设置过大。实际应用中，其数据量大小控制在几十字节以下较为适宜。

如前所述，对数据库状态的检测是一个持续的过程，在数据库的整个生命周期中，控制台会定期或随机进行多次状态检测，因此，控制台发送状态检测报文的次数通常亦不会限定在一次或少数几次。实际应用中，控制台发送状态检测报文的时机由其启动状态检测的时机所决定，状态检测报文的发送次数则通常不少于状态检测的次数。

202、启动本地计时并等待接收数据库的响应报文。

203、接收数据库的响应报文并停止计时。

在初始化设置时，管理员可以预先设定好数据库回复的内容，与状态检测报文类似，响应报文的内容也并无实际意义，实际应用中可以将其设置为“Im OK”或“So Far SoGood”等。

本步骤中，控制台在发送状态检测报文时启动本地计时，其目的在于计算数据库返回响应报文的耗时。在本实施例的一种实现方式中，控制台可以通过第一协程(当然也可以建立单独的协程)调用计时器功能接口启动计时。此外，控制台也可以通过读取系统时钟的方式，获得发送状态检测报文即接收响应报文的时刻值，并基于两时刻值的差值获得数据库的响应耗时。对于后者实现方式，实际应用中控制台可以对硬件主板上的原子时钟进行读取，也可以读取网络侧的系统时钟，本实施对此不做限制。

204、对数据库的响应耗时与预设的规定时间进行比对。

若数据库的响应耗时大于预设的规定时间，则表明数据库的响应速度未达到控制台要求的响应速度，执行步骤205；若数据库的响应耗时小于或等于预设的规定时间，则表明数据库的响应速度达到控制台要求的响应速度，执行步骤206。

需要说明的是，对于规定时间的设置，除了要考虑终端对延时的敏感程度之外，还应将报文传输所涉及的正常耗时考虑在内。实际应用中，规定时间的设置一般可以限定在ms级别，特殊情况下(例如网络无法容忍丝毫时延)，该规定时间的设置也可以趋近于0ms，本实施例不对规定时间的大小进行限制。

205、确定数据库处于超负荷状态。

206、确定数据库处于正常负荷状态。

需要说明的是，实际应用中，当数据库负荷较大时，可能存在数据库无法反馈响应报文的情况。此时，控制台一味等待响应报文并不现实。因此针对此种情况，应当制定一套补救方案。在本实施例的一种实现方式中，控制台可以允许管理员设置一个时长门限值，该门限值一般需要大于前述规定时间(例如500ms、1000ms等)。当控制台计时到达该时长门限值时，做一次状态判断，如果还未接收到数据库反馈的响应报文，则控制台停止计时，并执行步骤205，直接确定数据库处于超负荷状态。但对于读取系统时钟的方式，由于其不涉及到本地计时，控制台无法得知数据库的耗时是否超过时长门限值，因此该实现方式并不适用于此补救方案。

实际应用中，在停止向数据库发送查询请求后，如果数据库仍无法消化已有请求，那么可以判定数据库无法正常恢复。此种情况下，为保证局域网的正常运行，可以对数据库服务器进行重启。重启后的数据库将释放所有被占用的处理资源，因此能够恢复对查询请求的正常处理。

在判断数据库是否无法正常恢复时，可以以时间维度作为参考标准。控制台获取一个预设的时长阈值，在向数据库发送状态检测报文后，控制台启动本地计时。如若在到达该时长阀值后仍未接收到数据库的响应报文，则判断数据库无法正常恢复，重启数据库服务器。本实施例中，上述时长阈值可以大于前述时长门限值，但本实施例并不对其具体数值进行限定。

在重启数据库服务器时，控制台可以调用预先写好的重启指令重启数据库服务器。由于控制台始终保持着针对数据库的第一协程，因此控制台可以通过第一协程调取重启数据库服务器的API，获得并执行其中的重启指令。当然本实施例并不限定控制台通过其他协程或线程调用重启指令。

进一步的，当数据库中的查询请求发生拥塞、导致重启数据库服务器仍无法完全释放掉全部被占用资源时，控制台还可以进一步自行重启控制台服务器。在重启控制台服务器后，控制台已接收的所有查询请求均被丢弃，由此释放被占用的处理资源。此外，在重新建立与终端的连接时，控制台也可以限制连接的终端数，由此进一步协助减轻数据库的负荷压力。与前述重启数据库服务器相似，控制台也可以通过调用相应的重启指令自行重启。

以上实施例对控制台针对不同检测结果执行的不同处理方式进行了说明。在下面的一个实施例中，将给出一种在数据库恢复正常负荷状态后针对以接收请求的处理方式。具体的，如图3所示，该方法包括：

301、建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果。

本实施例中，该检测结果表征数据库处于超负荷状态。

302、在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向第一协程获取检测结果。

303、停止向数据库转发查询请求。

304、各第二协程继续向第一协程获取检测结果。

本步骤中，当查询请求因数据库超负荷而被停止转发时，除将请求直接丢弃外，还可以由控制台将各个查询请求“挂起”。当数据库恢复正常状态时，再继续将“挂起”的查询请求重新转发给数据库。

需要说明的是，当数据库处于超负荷状态时，对于已经接收的查询请求，控制台可以将其挂起，等待再次转发。但是对于终端新上报的查询请求，控制台应当予以拒绝，否则控制台聚集的请求数量将会不断增长，挤占控制台的处理资源。

由于涉及重新确定数据库的负荷状态，因此各第二协程需要不断获取新的检测结果。实际应用中，各条第二协程定时(例如每隔100ms)向第一协程获取检测结果。当获取到的检测结果反映数据库恢复正常负荷状态时，执行步骤305，重新转发查询请求；而当获取到的检测结果反映数据库仍处于超负荷状态时，继续执行本步骤，等待获取下一次检测结果。实际应用中，第二协程获取检测结果的时间间隔可以与第一协程检测数据库状态的时间间隔保持一致，即保证第一协程每次获得的检测结果均能够被第二协程计时获取，使查询请求能够被尽快转发到数据库进行处理。

305、当数据库恢复正常负荷状态时，向数据库转发查询请求。

当数据库恢复正常负荷状态时，控制台通过第二协程将等待转发查询请求发送给数据库进行响应，获得查询内容。

下面，给出图3的一种实现方式：

控制台预先建立一条等待队列以存放被挂起的查询请求。当数据库处于超负荷状态时，控制台将查询请求加入到等待队列中进行等待转发。而当数据库恢复正常负荷状态后，控制台从等待队列的队首开始，按照先进先出的原则，依次将等待队列中的查询请求转发给数据库，直至等待队列清空为止。示例性的，等待队列中的查询请求可以如图4所示。

进一步的，当等待队列较长时，为防止终端新上报的查询请求等待过久，在一种改进方式中，控制台还可以对等待队列中的查询请求以及新接收的查询请求进行混合转发，由此对两者请求进行并行兼顾。示例性的，如图5所示，请求A代表等待队列中的查询请求，请求B代表终端新上报的查询请求。控制台对两种请求进行交叉转发，例如图5a中所示的“ABABABA…”方式。当然，控制台也可以按照图5b所示的“AAABBBAAABBB…”方式进行批量交叉转发。本实施例不对控制台采用的具体混合方式进行限制。

进一步的，对于上述加入队列的实现方式，队列的建立和维护、以及请求的入队出队均会对控制台造成一定的内存占用。在一种更为简单的实现方式中，控制台可以取消等待队列的建立，转而采用随机抢占的方式进行查询请求的转发。在这种方式中，各个请求的第二协程按照前述步骤304的实现方式不断获取最新的检测请求。当第二协程发现数据库恢复正常负荷状态时，立即进行请求转发。各条第二线程抢占转发的执行是相互独立的，请求转发的先后顺序由第二线程启动抢占的先后顺序决定。再进一步的，在数据库恢复正常负荷状态后，对于终端新上报的查询请求，也可以参与随机抢占转发，与被“挂起”的查询请求一同抢占转发的机会。

需要说明的是，实际应用中，终端并不能够获得表征数据库负荷状态的信息，因此终端无法得知数据库是否处于超负荷状态。在前述各实施例中，终端无需关心数据库的负荷状态，仅仅按照传统方式上报查询请求即可，因而会出现一个问题，即当控制台停止转发查询请求时，终端仍不断上报新的查询请求。当大量的查询请求拥塞在控制台时，容易导致控制台发生崩溃。为防止控制台大量积压查询请求，在本发明的另一各实施例中，当数据库处于超负荷状态时，控制台可以向各个终端下发指示信息，指示终端暂时停止上报新的查询请求，由此使得控制台的请求数量能够得到控制。相应的，当数据库恢复正常负荷状态时，控制台也可以向各个终端下发指示信息，指示终端重新恢复上报查询请求。

进一步的，在现有的局域网架构中，通常管理员可以通过专用的人机交互平台对局域网进行监控。在本发明的又一实施例中，当数据库的负荷状态发生变化时，控制台还可以向管理员平台发送提示信息，以便管理员计时做出相应决策。

例如，当数据库处于超负荷状态时，控制台可以调用预留的功能接口向管理员平台发送提示信息，告知管理员数据库发生拥塞，无法继续进行响应；当数据库恢复正常负荷状态时，控制台同样调用相同的功能接口向管理员平台发送提示信息，告知管理员数据库恢复正常，可以执行查询任务。本实施例中，控制台可以向管理员平台发送用作提示的静态页面，也可以直接调出对话框输出提示信息，或者还可以在工具栏或页面的其他指定区域中显示提示信息，本实施例不对提示信息展示形式进行限制。

进一步的，作为对上述各方法实施例的实现，本发明另一实施例还提供了一种数据请求的装置，该装置可以位于控制台中，或独立于控制台但与控制台之间建立有数据交互关系，用以实现前述各方法实施例。需要说明的是，本实施例中所述的控制台在实际应用中也可以是一个具有网络管理功能的服务器。如图6所示，该装置包括：检测单元61、获取单元62以及处理单元63；其中，

检测单元61，用于建立对应数据库的第一协程，并通过第一协程对数据库的负荷状态进行检测，获得检测结果；

获取单元62，用于在接收到终端上报的查询请求时，建立对应查询请求的第二协程，并通过第二协程向检测单元61建立的第一协程获取检测结果；

处理单元63，用于当获取单元62获取的检测结果表征数据库处于超负荷状态时，停止向数据库转发查询请求。

进一步的，处理单元63，用于当获取单元62获取的检测结果表征数据库处于正常负荷状态时，向数据库转发查询请求。

进一步的，检测单元61，用于通过第一协程向数据库发送状态检测报文，若未在规定时间内接收到数据库的响应报文，则检测结果为数据库处于超负荷状态。

进一步的，如图7所示，该装置进一步包括：

重启单元64，用于当在到达预设的时长阀值后检测单元61仍未接收到数据库的响应报文时，重启数据库服务器；其中时长阀值大于规定时间。

进一步的，重启单元64，用于通过第一协程调用并执行数据库服务器的重启指令。

进一步的，处理单元63，用于在数据库服务器恢复正常负荷状态后，将查询请求重新转发给数据库。

进一步的，如图7所示，处理单元63，包括：

第一处理子单元631，用于在停止向数据库转发查询请求后，将查询请求加入到等待队列中，在数据库服务器恢复正常负荷状态后，将等待队列中的查询请求转发给数据库。

进一步的，如图7所示，处理单元63，包括：

第二处理子单元632，用于向终端下发指示信息，指示终端重新上报查询请求。

进一步的，如图7所示，该装置进一步包括：

调用单元65，用于调用预留的功能接口发送提示信息。

进一步的，作为对上述各方法实施例的实现，本发明另一实施例还提供了一种数据请求的系统。如图8所示，该系统包括：终端81、控制台82以及数据库服务器83。其中，控制台在实际应用中也可以为具有网络管理功能的服务器。该控制台82包括如前图6或图7所示的装置。

终端81，用于向控制台82上报查询请求，查询请求用于向数据库服务器83请求进行数据查询；

控制台82，用于在检测结果表征数据库处于正常负荷状态时，向数据库服务器83转发查询请求，而在检测结果表征数据库处于超负荷状态时，停止向数据库服务器83转发查询请求；

数据库服务器83，用于在检测结果表征数据库处于正常负荷状态时，接收控制台82转发的查询请求，并对查询请求进行响应，返回查询内容；

控制台82，还用于接收数据库服务器83返回的查询内容，并将查询内容下发给终端81。

现有技术中，控制台作为终端与数据库之间的中介，仅负责将终端上报的查询请求发送给数据库进行处理，即使数据库的处理资源告急，出现较大的负荷压力，控制台也不会停止发送查询请求。因此数据库很容易因为资源负荷过大发生瘫痪，而一旦数据库发生瘫痪就无法进行恢复，只能对数据库服务器进行重启，由此使局域网的正常运行被中断。而基于本实施例提供的装置及系统，控制台可以对数据库的负荷状态进行检测，当数据库负荷过大时，暂停发送查询请求，由此给予数据库消化已有请求的机会，防止数据库瘫痪，进而提高局域网运行的稳定性。

其次，基于本实施例提供的装置及系统，控制台能够通过一个常驻的第一协程对数据库进行持续检测，第二协程直接向第一协程“索取”检测结果即可进行后续的处理操作。从技术实现的角度看，第二协程也能够直接对数据库进行检测，但是由于第二协程的数量较多，大量重复的检测操作势必会浪费控制台有限的处理资源。本实施例能够通过“结果共享”的设计思路降低相似操作的重复执行，可以最大限度减少控制台的资源开销。

第三，与现有技术中通过进程或线程执行相应操作相比，本实施例提供的装置及系统能够通过更为轻量级的协程执行各类操作。由于协程属于纯后台执行的程序，终端前台或数据库服务器完全感知不到其操作的执行，因此除能够节省线程资源外，采用协程还可以降低执行操作对业务运行的影响。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

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

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的对象流转监控的方法、装置及系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (17)

1.一种数据请求的方法，其特征在于，所述方法包括：

建立对应数据库的第一协程，并通过所述第一协程对数据库的负荷状态进行检测，获得检测结果；

在接收到终端上报的查询请求时，建立对应所述查询请求的第二协程，并通过所述第二协程向所述第一协程获取所述检测结果；

若所述检测结果表征数据库处于超负荷状态，则停止向所述数据库转发所述查询请求；

其中，所述通过所述第一协程对数据库的负荷状态进行检测，获得检测结果，包括：通过所述第一协程向所述数据库发送状态检测报文；

若未在规定时间内接收到数据库的响应报文，则所述检测结果为数据库处于超负荷状态。

2.根据权利要求1所述的方法，其特征在于，若所述检测结果表征数据库处于正常负荷状态，则所述方法进一步包括：

向所述数据库转发所述查询请求。

3.根据权利要求2所述的方法，其特征在于，若在到达预设的时长阀值后仍未接收到数据库的响应报文，则所述方法进一步包括：

重启数据库服务器；

其中所述时长阀值大于所述规定时间。

4.根据权利要求3所述的方法，其特征在于，所述重启数据库服务器，包括：

通过所述第一协程调用并执行所述数据库服务器的重启指令。

5.根据权利要求1所述的方法，其特征在于，在所述数据库服务器恢复正常负荷状态后，所述方法进一步包括：

将所述查询请求重新转发给所述数据库。

6.根据权利要求5所述的方法，其特征在于，所述将所述查询请求重新转发给所述数据库，包括：

在停止向所述数据库转发所述查询请求后，将所述查询请求加入到等待队列中；

在所述数据库服务器恢复正常负荷状态后，将所述等待队列中的查询请求转发给所述数据库。

7.根据权利要求5所述的方法，其特征在于，将所述查询请求重新转发给所述数据库，包括：

向所述终端下发指示信息，指示所述终端重新上报所述查询请求。

8.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

调用预留的功能接口发送提示信息。

9.一种数据请求的装置，其特征在于，所述装置包括：

检测单元，用于建立对应数据库的第一协程，并通过所述第一协程对数据库的负荷状态进行检测，获得检测结果；

获取单元，用于在接收到终端上报的查询请求时，建立对应所述查询请求的第二协程，并通过所述第二协程向所述检测单元建立的所述第一协程获取所述检测结果；

处理单元，用于当所述获取单元获取的所述检测结果表征数据库处于超负荷状态时，停止向所述数据库转发所述查询请求；

其中，所述检测单元，用于通过所述第一协程向所述数据库发送状态检测报文，若未在规定时间内接收到数据库的响应报文，则所述检测结果为数据库处于超负荷状态。

10.根据权利要求9所述的装置，其特征在于，所述处理单元，用于当所述获取单元获取的所述检测结果表征数据库处于正常负荷状态时，向所述数据库转发所述查询请求。

11.根据权利要求10所述的装置，其特征在于，所述装置进一步包括：

重启单元，用于当在到达预设的时长阀值后所述检测单元仍未接收到数据库的响应报文时，重启数据库服务器；其中所述时长阀值大于所述规定时间。

12.根据权利要求11所述的装置，其特征在于，所述重启单元，用于通过所述第一协程调用并执行所述数据库服务器的重启指令。

13.根据权利要求9所述的装置，其特征在于，所述处理单元，用于在所述数据库服务器恢复正常负荷状态后，将所述查询请求重新转发给所述数据库。

14.根据权利要求13所述的装置，其特征在于，所述处理单元，包括：

第一处理子单元，用于在停止向所述数据库转发所述查询请求后，将所述查询请求加入到等待队列中，在所述数据库服务器恢复正常负荷状态后，将所述等待队列中的查询请求转发给所述数据库。

15.根据权利要求13所述的装置，其特征在于，所述处理单元，包括：

第二处理子单元，用于向所述终端下发指示信息，指示所述终端重新上报所述查询请求。

16.根据权利要求9所述的装置，其特征在于，所述装置进一步包括：

调用单元，用于调用预留的功能接口发送提示信息。

17.一种数据请求的系统，其特征在于，所述系统包括：终端、控制台以及数据库服务器；其中，所述控制台包括如前述权利要求9至16中任一项所述的装置；

所述终端，用于向所述控制台上报查询请求，所述查询请求用于向所述数据库服务器请求进行数据查询；

所述控制台，用于在检测结果表征数据库处于正常负荷状态时，向所述数据库服务器转发所述查询请求，而在检测结果表征数据库处于超负荷状态时，停止向所述数据库服务器转发所述查询请求；

所述数据库服务器，用于在检测结果表征数据库处于正常负荷状态时，接收所述控制台转发的所述查询请求，并对所述查询请求进行响应，返回查询内容；

所述控制台，还用于接收所述数据库服务器返回的查询内容，并将所述查询内容下发给所述终端。