CN104408110B

CN104408110B - The method, apparatus and system of request of data

Info

Publication number: CN104408110B
Application number: CN201410681632.9A
Authority: CN
Inventors: 王院生
Original assignee: Beijing Qianxin Technology Co Ltd
Current assignee: Qax Technology Group Inc
Priority date: 2014-11-24
Filing date: 2014-11-24
Publication date: 2018-11-09
Anticipated expiration: 2034-11-24
Also published as: CN104408110A

Abstract

The invention discloses a kind of method, apparatus of request of data and systems, are related to Internet technical field, to solve the problems, such as that database is paralysed and invented because inquiry request is excessive.The method of the present invention includes：First association's journey of correspondence database is established, and the load condition of database is detected by first association's journey, obtains testing result；When receiving the inquiry request that terminal reports, second association's journey of corresponding inquiry request is established, and testing result is obtained to first association's journey by second association's journey；If testing result characterization database is in overload state, stop asking to database forwarding inquiries.Present invention is mainly applied in postgresql Database Systems.

Description

Data request method, device and system

Technical Field

The present invention relates to the field of internet technologies, and in particular, to a method, an apparatus, and a system for requesting data.

Background

In the local area network, the console is used as a bridge between the terminal and the database, and is responsible for receiving, managing and forwarding the query request sent by the terminal to the database, and issuing the query content returned by the database to the terminal. Generally, the processing resources allocated to the query task by the database server are limited, and the number of query requests (hereinafter, referred to as request concurrency number) reported instantaneously in the local area network may be large. And once the database is paralyzed, the database cannot be recovered, and only the database server can be restarted, thereby causing interruption to the normal operation of the local area network.

With the increasing demand of large enterprises and institutions on the scale of local area networks, the number of terminals in the local area networks will increase, and the number of query requests in the local area networks will also increase correspondingly, so that the frequency of database paralysis will increase more and more. For a large network, especially a multi-level network, frequent paralysis of a database system will inevitably affect the stability of the network, and reduce the operating efficiency of the local area network. Therefore, how to effectively maintain the database system so that the database system can meet the query requirement in a large-scale network environment becomes a difficult problem to be solved for technicians.

Disclosure of Invention

In view of this, the present invention provides a method, an apparatus and a system for requesting data, which can solve the problem of database paralysis caused by excessive query requests.

To solve the above technical problem, in one aspect, the present invention provides a method for requesting data, including:

establishing a first coroutine corresponding to the database, and detecting the load state of the database through the first coroutine to obtain a detection result;

when receiving a query request reported by a terminal, establishing a second protocol corresponding to the query request, and acquiring a detection result from the first protocol through the second protocol;

and if the detection result represents that the database is in an overload state, stopping forwarding the query request to the database.

In another aspect, the present invention further provides a device for requesting data, including:

the detection unit is used for establishing a first coroutine corresponding to the database and detecting the load state of the database through the first coroutine to obtain a detection result;

the acquisition unit is used for establishing a second coroutine corresponding to the query request when receiving the query request reported by the terminal, and acquiring a detection result from the first coroutine established by the detection unit through the second coroutine;

and the processing unit is used for stopping forwarding the query request to the database when the detection result obtained by the obtaining unit represents that the database is in an overload state.

In another aspect, the present invention further provides a system for requesting data, including: the system comprises a terminal, a console and a database server; wherein the console comprises an apparatus as referred to in the second aspect above;

the terminal is used for reporting a query request to the console, and the query request is used for requesting a database server to perform data query;

the console is used for forwarding the query request to the database server when the detection result representation database is in a normal load state, and stopping forwarding the query request to the database server when the detection result representation database is in an overload state;

the database server is used for receiving the query request forwarded by the console when the detection result represents that the database is in a normal load state, responding to the query request and returning query contents;

and the console is also used for receiving the query content returned by the database server and sending the query content to the terminal.

The method, the device and the system for the data request can establish a resident first co-program to continuously detect the load state of the database, and share the obtained detection result to a second co-program established for the query request, so that the latter can forward or cancel the forwarding of the query request based on different detection results. Compared with the prior art, the method and the system can suspend the forwarding of the query request when the database is in an overload state, can give sufficient time to the database to process the existing request in time and release corresponding processing resources, and therefore prevent the database from being paralyzed due to excessive query requests.

The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

FIG. 1 is a flow chart illustrating a method for requesting data according to the present invention;

FIG. 2 is a flow chart illustrating another method of data request provided by the present invention;

FIG. 3 is a flow chart of yet another method for requesting data provided by the present invention;

FIG. 4 illustrates a schematic diagram of a wait queue provided by the present invention;

FIGS. 5(a) and 5(b) are schematic diagrams illustrating a hybrid forwarding query request provided by the present invention;

FIG. 6 is a schematic diagram illustrating an apparatus for requesting data according to the present invention;

FIG. 7 is a schematic diagram of another data request device provided by the present invention;

fig. 8 is a schematic diagram of a system for requesting data according to the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

In order to prevent the database from being paralyzed due to excessive query requests, the embodiment of the invention provides a data request method, which can suspend the forwarding of the query requests when the database is in an overload state, so that the database has sufficient time to process the existing requests. As shown in fig. 1, the method includes:

101. and establishing a first coroutine corresponding to the database, and detecting the load state of the database through the first coroutine to obtain a detection result.

When the database is started, the console establishes an independent first protocol, which is specially used for detecting the load state of the database. The first protocol in this embodiment is a resident protocol, that is, the protocol is established during database initialization and survives the whole data query process. No matter whether the console receives the query request reported by the terminal or not, as long as the life cycle of the database is not finished, the first protocol keeps the survival state all the time and continuously detects the resource load state of the database.

The continuous detection described in the present embodiment refers to a process of maintaining a detection state, and is not limited to the case of continuous detection. In practical applications, the above continuous detection method further includes: the present embodiment does not limit the timing, frequency, or frequency of the first routine detecting the database state, such as performing periodic detection according to a preset time interval, performing aperiodic detection according to an instruction of the console, or performing automatic detection based on a preset policy/rule.

In this embodiment, the resource parameters capable of reflecting the load status of the database resource may be: memory usage, Central Processing Unit (CPU) usage, and disk read/write interface usage. Of course, the resource parameter may also be a combination of the above resource parameters. The first coroutine can send a data request to the database through a pre-written interface program, acquire the resource parameters (or the combination of the resource parameters), and acquire the detection result of the load state of the database in a mode of comparing the resource parameters with a preset standard threshold.

In general, the database server usually does not allocate all processing resources to the data query task, so in practical applications, the usage percentage of each resource parameter should be the usage percentage in its actual resource allocation range. For example, suppose that for a database server with 4G memory, if it allocates 1G memory resources for processing a query request, its actual memory usage percentage should be 40% instead of 10% when the current processing query request occupies 0.4G memory.

The above detection method for obtaining resource parameters is only one implementation manner of this embodiment, and in practical application, the console may also directly detect the response speed of the database from a result level without paying attention to specific resource parameters of the database, and if the response speed of the database is too slow (the time consumption is long), it indicates that the resource load of the database exceeds the normal bearing capacity. In other words, the response speed of the database can comprehensively reflect the occupation conditions of various resources inside the database, so that in practical application, the response speed is generally more conveniently tested, and a more ideal detection effect can be obtained. The embodiment will be described with an emphasis on such a detection method.

In this embodiment, the detection result obtained by the console may have different expressions. In an implementation manner of this embodiment, the detection result may be a gear level capable of describing a load state of the database, such as "idle", "busy", "saturation", "overload", and the like, where different gears are used to reflect different load degrees of the database; or in another implementation manner of this embodiment, the detection result may also be a simple value, for example, 45, 67, and the like, where the size of the value is used to reflect the load degree of the database, and for this form, it needs to be ensured that the value has a value interval with a boundary, and the upper and lower boundaries of the interval should correspond to two extreme load degrees (for example, 0 load, overload, and the like) of the database. In order to simplify the implementation in practical applications, in the third implementation manner of this embodiment, the detection result is only divided into two stages, namely, a "normal load state" and an "overload state", and a boundary between the two stages can be obtained by an administrator by comprehensively considering and setting factors such as a network scale and database performance, or can be obtained by a console by performing self-calculation according to a preset rule policy, and can be dynamically adjusted. For the convenience of implementation, the third form of the detection result will be described as an example in the following.

102. And when receiving a query request reported by the terminal, establishing a second protocol corresponding to the query request, and acquiring a detection result from the first protocol through the second protocol.

Unlike the prior art in which the console directly forwards the query request to the database, in this embodiment, before the console forwards the query request to the database, the console first needs to obtain a detection result of the database state from the first coroutine through the second coroutine corresponding to the request, and when the database is in an overload state, the following step 103 is executed to stop forwarding the query request, thereby reducing the load pressure of the database.

The second coroutine in this step is a coroutine established for the query request and independent of the first coroutine. The console receives several inquiry requests to establish several second coroutines, and there is no substantial association between every two coroutines. In this embodiment, the second protocol is established based on the report of the query request, and is ended after the query request obtains the query response or when the query is terminated, and the survival period of the second protocol is usually shorter than that of the first protocol.

In this embodiment, the first coroutine is dedicated to detecting the load state of the database and is not responsible for sending the detection result to the second coroutine, so that the second coroutine needs to actively ask for the detection result from the first coroutine when forwarding the query request to the database. In practical applications, the number of requests sent by the console side is usually large, so that the second coroutines corresponding to each query request need to ask for the detection result from the first coroutines, and actions of asking for the detection result by each coroutine are independent from each other. In addition, as mentioned above, the detection of the database by the first protocol is continuous, and the detection results obtained by the first protocol at different times may be different based on the continuous change of the load status of the database, and the times of requesting the detection results by the second protocol are different, so in practical applications, the detection results obtained by different second protocols may be different, for example, the detection result obtained by the second protocol of request 1 in the previous time period is "overload status", and the detection result obtained by the second protocol of request 2 in the next time period is "normal load status". The processing results of different query requests will of course differ from each other based on different detection results.

103. And if the detection result represents that the database is in an overload state, stopping forwarding the query request to the database.

And when the detection result obtained by the second protocol is that the database is in an overload state, the console stops sending the query request corresponding to the second protocol to the database. For the subsequent processing of the query request, in an implementation manner of this embodiment, the console may discard the query request and notify the terminal, which is equivalent to the end of the query process for the terminal; in yet another implementation of this embodiment, the console may also "suspend" the query request and forward it to the database when the load on the database is relieved.

In this step, the console may separately establish a processing routine to execute the operation of discarding or suspending the request, and in practical applications, the console may separately establish a processing routine for each request to be processed, and end the processing routine after the processing is completed, or may reside in a master routine, and the master routine processes the query requests in a unified manner.

In practical applications, no matter whether the processing coroutines are established separately or the total coroutines are established, a part of processing resources of the console are occupied. To avoid unnecessary overhead of console processing resources as much as possible, in one implementation of this embodiment, the console may perform operations such as discarding, suspending requests, and the like using the existing second routine.

104. And if the detection result represents that the database is in a normal load state, forwarding the query request to the database.

For the detection result obtained in step 102, if it represents that the database is in a normal load state, it indicates that the processing resource of the database is partially idle, and there is no paralysis due to further increasing the query request, so in this case, the console may send the received query request to the database for responding, and forward the query content returned by the database to the terminal, thereby completing a conventional data query process.

Similar to step 103, in an implementation manner of this embodiment, the console may also complete operations of sending the query request, forwarding the query content, and the like through the second protocol corresponding to the request.

In the prior art, the console serves as an intermediary between the terminal and the database and is only responsible for sending the query request reported by the terminal to the database for processing, and even if processing resources of the database are in urgency and a large load pressure occurs, the console does not stop sending the query request. Therefore, the database is easy to be paralyzed due to the overlarge resource load, and once the database is paralyzed, the database cannot be recovered, and only the database server can be restarted, so that the normal operation of the local area network is interrupted. In the embodiment, the console can detect the load state of the database, and when the load of the database is too large, the query request is suspended from being sent, so that the database is given a chance of digesting the existing request, the database is prevented from being paralyzed, and the running stability of the local area network is improved.

Secondly, in this embodiment, the console can continuously detect the database through a resident first protocol, and the second protocol can directly "ask" the detection result from the first protocol to perform subsequent processing operations. From the perspective of technical implementation, the second protocol can also directly detect the database, but because the number of the second protocol is large, a large number of repeated detection operations will inevitably waste the limited processing resources of the console. The embodiment can reduce repeated execution of similar operations through the design idea of result sharing, and can reduce resource overhead of the console to the maximum extent.

Third, compared with the prior art in which corresponding operations are executed by processes or threads, the present embodiment can execute various types of operations by a lighter coroutine. The coroutine belongs to a program executed in a pure background, and the terminal foreground or the database server can not sense the execution of the operation, so that the coroutine can be used for saving thread resources and reducing the influence of the execution operation on the service operation.

Further, as a refinement to step 101 in fig. 1, in another embodiment of the present invention, the console may detect the response speed of the database through the first routine, so as to obtain a detection result capable of comprehensively reflecting the resource status of the database. Specifically, as shown in fig. 2, the method includes:

201. and sending a state detection message to the database through the first protocol.

The message format of the state detection message is the same as that of the traditional data message, and the header of the state detection message needs to carry the IP addresses of the console and the database to be respectively used as a source IP address and a destination IP address. However, unlike the conventional data packet, the status check packet is only used to Test the response speed of the database, and the data content of the status check packet has no practical meaning for the status, so that the administrator can set the data content of the packet at will, for example, set the data content of the packet to "Hello DB" or "Test".

It should be noted that, because the content of the status detection packet has no practical significance, the data content of the packet should not be set too large from the viewpoint of saving the network transmission bandwidth. In practical applications, the data size is preferably controlled to be less than several tens of bytes.

As mentioned above, the detection of the database status is a continuous process, and the console periodically or randomly performs a plurality of status detections throughout the lifetime of the database, so the number of times the console sends the status detection message is not limited to one or a few times. In practical application, the timing of sending the state detection message by the console is determined by the timing of starting the state detection, and the sending times of the state detection message is usually not less than the state detection times.

202. And starting local timing and waiting for receiving a response message of the database.

203. And receiving a response message of the database and stopping timing.

During initialization setting, an administrator can preset the content of database reply, similar to the state detection message, the content of the response message has no practical significance, and the content can be set to 'Im OK' or 'So Far good' in practical application.

In this step, the console starts local timing when sending the status detection message, and the purpose is to calculate the time consumed by the database to return the response message. In one implementation of this embodiment, the console may invoke the timer function interface to start timing via the first protocol (although a separate protocol may also be established). In addition, the console can also obtain the time value of sending the state detection message, namely receiving the response message, by reading the system clock, and obtain the response time consumption of the database based on the difference value of the two time values. For the latter implementation manner, in practical application, the console may read the atomic clock on the hardware motherboard and may also read the system clock on the network side, which is not limited in this embodiment.

204. And comparing the response time of the database with the preset specified time.

If the response time of the database is longer than the preset specified time, it indicates that the response speed of the database does not reach the response speed required by the console, and step 205 is executed; if the response time of the database is less than or equal to the preset specified time, it indicates that the response speed of the database reaches the response speed required by the console, and step 206 is executed.

It should be noted that, for setting the specified time, in addition to considering the sensitivity of the terminal to the delay, the normal time consumption involved in the message transmission should be also considered. In practical applications, the setting of the specified time may be limited to the ms level, and in special cases (for example, the network cannot tolerate any delay), the setting of the specified time may also be close to 0ms, and the present embodiment does not limit the size of the specified time.

205. Determining that the database is in an overload state.

206. And determining that the database is in a normal load state.

It should be noted that, in practical application, when the load of the database is large, there may be a case that the database cannot feed back the response packet. At this time, it is not practical for the console to wait for the response message at once. Therefore, a set of remedies should be developed for this situation. In one implementation of this embodiment, the console may allow the administrator to set a duration threshold that generally requires more than the prescribed time (e.g., 500ms, 1000ms, etc.). When the timing of the console reaches the time length threshold value, a state judgment is made once, if a response message fed back by the database is not received, the console stops timing, and step 205 is executed to directly determine that the database is in an overload state. However, for the way of reading the system clock, since it does not involve local timing, the console cannot know whether the consumed time of the database exceeds the duration threshold, and therefore, this implementation is not suitable for this remedy.

In practical application, after the query request is stopped being sent to the database, if the database still cannot digest the existing request, it can be determined that the database cannot be normally recovered. In this case, the database server may be restarted to ensure normal operation of the lan. The restarted database will release all occupied processing resources, so normal processing of the query request can be resumed.

When judging whether the database can not be normally recovered, the time dimension can be used as a reference standard. The console acquires a preset time threshold value, and starts local timing after sending the state detection message to the database. If the response message of the database is not received after the time length threshold value is reached, the database is judged to be incapable of being normally recovered, and the database server is restarted. In this embodiment, the duration threshold may be greater than the duration threshold, but the embodiment does not limit the specific value of the duration threshold.

When restarting the database server, the console may call a pre-written restart instruction to restart the database server. Since the console always maintains the first protocol for the database, the console can call the API of the database server through the first protocol, and obtain and execute the restart instruction therein. Of course, the present embodiment does not limit the console to call the restart instruction through other coroutines or threads.

Furthermore, when the query request in the database is congested and the database server cannot completely release all occupied resources even when being restarted, the console can further restart the console server by itself. After restarting the console server, all query requests that the console has received are discarded, thereby freeing up occupied processing resources. In addition, the console may also limit the number of connected terminals when re-establishing connections with terminals, thereby further assisting in relieving database load. Similar to the restart database server, the console may also restart itself by invoking a corresponding restart instruction.

The above embodiment describes different processing modes executed by the console for different detection results. In one embodiment below, a processing approach for receiving requests after the database resumes a normal load state will be presented. Specifically, as shown in fig. 3, the method includes:

301. and establishing a first coroutine corresponding to the database, and detecting the load state of the database through the first coroutine to obtain a detection result.

In this embodiment, the detection result indicates that the database is in an overload state.

302. And when receiving a query request reported by the terminal, establishing a second protocol corresponding to the query request, and acquiring a detection result from the first protocol through the second protocol.

303. The query request is stopped from being forwarded to the database.

304. And each second coroutine continuously acquires the detection result from the first coroutine.

In this step, when the query requests are stopped from being forwarded due to overload of the database, the query requests can be directly discarded, and the console can suspend the query requests. When the database returns to the normal state, the suspended inquiry request is forwarded to the database again.

It should be noted that when the database is in an overload state, the console may suspend the received query request and wait for forwarding again. However, the console should reject the query request newly reported by the terminal, otherwise, the number of requests aggregated by the console will increase continuously, and the processing resources of the console will be occupied.

Each second protocol needs to continuously acquire new detection results because it involves re-determining the load status of the database. In practical applications, each second protocol acquires the detection result from the first protocol at a timing (e.g., every 100 ms). When the acquired detection result reflects that the database recovers to the normal load state, step 305 is executed to retransmit the query request; and when the obtained detection result reflects that the database is still in an overload state, continuing to execute the step and waiting for obtaining the next detection result. In practical application, the time interval for the second protocol to acquire the detection result can be kept consistent with the time interval for the first protocol to detect the state of the database, that is, the detection result acquired by the first protocol each time can be acquired by the second protocol, so that the query request can be forwarded to the database for processing as soon as possible.

305. And when the database recovers the normal load state, forwarding the query request to the database.

And when the database recovers the normal load state, the console sends the query request waiting for forwarding to the database for responding through the second coroutine to obtain query contents.

In the following, an implementation of fig. 3 is given:

the console pre-establishes a wait queue to hold pending query requests. When the database is in an overload state, the console adds the query request into a waiting queue to wait for forwarding. And after the database recovers the normal load state, the console sequentially forwards the query requests in the waiting queue to the database from the head of the waiting queue according to the first-in first-out principle until the waiting queue is empty. For example, the query requests in the wait queue may be as shown in FIG. 4.

Further, when the waiting queue is long, in order to prevent the query request newly reported by the terminal from waiting too long, in an improved manner, the console may also perform hybrid forwarding on the query request in the waiting queue and the newly received query request, so as to concurrently consider the two requests. For example, as shown in fig. 5, request a represents a query request waiting for a queue, and request B represents a query request newly reported by a terminal. The console cross-forwards both requests, for example in the "abaababa …" manner shown in fig. 5 a. Of course, the console may also perform batch cross forwarding in the manner of "aaabbba aaabbb …" shown in fig. 5 b. The embodiment is not limited to the specific mixing method adopted by the console.

Further, for the above implementation of adding queues, the establishment and maintenance of the queues and the enqueuing and dequeuing of requests all cause a certain memory occupation on the console. In a simpler implementation, the console may cancel the establishment of the wait queue and instead forward the query request in a random preemption manner. In this manner, the second protocol for each request continuously obtains the latest detection request according to the implementation manner of step 304. And when the second coroutine finds that the database recovers the normal load state, immediately forwarding the request. The execution of preemptive forwarding of each second thread is independent, and the sequence of request forwarding is determined by the sequence of the preemptive starting of the second thread. Furthermore, after the database recovers the normal load state, the query request newly reported by the terminal can also participate in random preemptive forwarding, and the opportunity of preemptive forwarding is performed together with the suspended query request.

It should be noted that, in practical applications, the terminal cannot obtain information representing the load state of the database, and therefore the terminal cannot know whether the database is in an overload state. In the foregoing embodiments, the terminal does not need to care about the load state of the database, and only reports the query request in the conventional manner, so that a problem arises in that when the console stops forwarding the query request, the terminal still reports new query requests continuously. When a large number of query requests are congested in a console, it is easy to cause the console to crash. In order to prevent the console from backlogging query requests in a large amount, in another embodiment of the present invention, when the database is in an overload state, the console may issue indication information to each terminal to indicate the terminal to temporarily stop reporting new query requests, thereby enabling the number of requests of the console to be controlled. Correspondingly, when the database recovers the normal load state, the console can also issue indication information to each terminal to indicate the terminal to resume reporting the query request.

Further, in the existing lan architecture, an administrator can monitor the lan through a dedicated human-computer interaction platform. In another embodiment of the present invention, when the load status of the database changes, the console may further send a prompt message to the administrator platform, so that the administrator can make a corresponding decision by timing.

For example, when the database is in an overload state, the console may call a reserved functional interface to send a prompt message to the administrator platform to inform the administrator that the database is congested and cannot continue to respond; when the database recovers to a normal load state, the console calls the same functional interface to send prompt information to the administrator platform to inform the administrator that the database recovers to be normal, and the query task can be executed. In this embodiment, the console may send a static page used as a prompt to the administrator platform, may also directly call out a dialog box to output the prompt information, or may also display the prompt information in a toolbar or other designated area of the page, and this embodiment does not limit the display form of the prompt information.

Further, as an implementation of the foregoing method embodiments, another embodiment of the present invention further provides a device for requesting data, which may be located in the console or be independent of the console but has a data interaction relationship with the console, so as to implement the foregoing method embodiments. It should be noted that, in practical application, the console described in this embodiment may also be a server with a network management function. As shown in fig. 6, the apparatus includes: a detection unit 61, an acquisition unit 62, and a processing unit 63; wherein,

the detection unit 61 is configured to establish a first coroutine corresponding to the database, and detect a load state of the database through the first coroutine to obtain a detection result;

the acquiring unit 62 is configured to establish a second coroutine corresponding to the query request when receiving the query request reported by the terminal, and acquire a detection result from the first coroutine established by the detecting unit 61 through the second coroutine;

and the processing unit 63 is configured to stop forwarding the query request to the database when the detection result obtained by the obtaining unit 62 indicates that the database is in an overload state.

Further, the processing unit 63 is configured to forward the query request to the database when the detection result obtained by the obtaining unit 62 indicates that the database is in the normal load state.

Further, the detecting unit 61 is configured to send a status detection message to the database through the first protocol, and if a response message of the database is not received within a specified time, the detection result indicates that the database is in an overload state.

Further, as shown in fig. 7, the apparatus further includes:

the restarting unit 64 is used for restarting the database server when the detection unit 61 does not receive the response message of the database after the preset duration threshold value is reached; wherein the duration threshold is greater than the prescribed time.

Further, the restarting unit 64 is configured to call and execute a restarting instruction of the database server through the first protocol.

Further, the processing unit 63 is configured to retransmit the query request to the database after the database server recovers the normal load state.

Further, as shown in fig. 7, the processing unit 63 includes:

the first processing subunit 631 is configured to add the query request to the waiting queue after the query request is stopped from being forwarded to the database, and forward the query request in the waiting queue to the database after the database server recovers the normal load state.

Further, as shown in fig. 7, the processing unit 63 includes:

the second processing subunit 632 is configured to issue indication information to the terminal, and indicate the terminal to report the query request again.

Further, as shown in fig. 7, the apparatus further includes:

and the calling unit 65 is used for calling the reserved functional interface to send the prompt message.

Further, as an implementation of the foregoing method embodiments, another embodiment of the present invention further provides a system for requesting data. As shown in fig. 8, the system includes: a terminal 81, a console 82 and a database server 83. In practical application, the console may also be a server with a network management function. The console 82 includes the apparatus shown in fig. 6 or 7, as previously described.

A terminal 81, configured to report an inquiry request to a console 82, where the inquiry request is used to request a database server 83 to perform data inquiry;

a console 82, configured to forward the query request to the database server 83 when the detection result indicates that the database is in a normal load state, and stop forwarding the query request to the database server 83 when the detection result indicates that the database is in an overload state;

the database server 83 is configured to receive the query request forwarded by the console 82 when the detection result indicates that the database is in a normal load state, respond to the query request, and return query content;

the console 82 is further configured to receive the query content returned by the database server 83, and send the query content to the terminal 81.

In the prior art, the console serves as an intermediary between the terminal and the database and is only responsible for sending the query request reported by the terminal to the database for processing, and even if processing resources of the database are in urgency and a large load pressure occurs, the console does not stop sending the query request. Therefore, the database is easy to be paralyzed due to the overlarge resource load, and once the database is paralyzed, the database cannot be recovered, and only the database server can be restarted, so that the normal operation of the local area network is interrupted. Based on the device and the system provided by the embodiment, the console can detect the load state of the database, and when the load of the database is too large, the query request is suspended to be sent, so that the database is given a chance to digest the existing request, the database is prevented from being paralyzed, and the running stability of the local area network is further improved.

Secondly, based on the device and the system provided by the embodiment, the console can continuously detect the database through a resident first coroutine, and the second coroutine can directly 'ask' the detection result from the first coroutine to perform subsequent processing operation. From the perspective of technical implementation, the second protocol can also directly detect the database, but because the number of the second protocol is large, a large number of repeated detection operations will inevitably waste the limited processing resources of the console. The embodiment can reduce repeated execution of similar operations through the design idea of result sharing, and can reduce resource overhead of the console to the maximum extent.

Third, compared with the prior art in which corresponding operations are executed by processes or threads, the apparatus and system provided in this embodiment can execute various operations by a lighter-weight coroutine. The coroutine belongs to a program executed in a pure background, and the terminal foreground or the database server can not sense the execution of the operation, so that the coroutine can be used for saving thread resources and reducing the influence of the execution operation on the service operation.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

It will be appreciated that the relevant features of the method and apparatus described above are referred to one another. In addition, "first", "second", and the like in the above embodiments are for distinguishing the embodiments, and do not represent merits of the embodiments.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The algorithms and displays presented herein are not inherently related to any particular computer, virtual machine, or other apparatus. Various general purpose systems may also be used with the teachings herein. The required structure for constructing such a system will be apparent from the description above. Moreover, the present invention is not directed to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any descriptions of specific languages are provided above to disclose the best mode of the invention.

In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.

The various component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components of the method, apparatus and system for object flow monitoring according to embodiments of the present invention. The present invention may also be embodied as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.

Claims

1. A method of data request, the method comprising:

establishing a first coroutine corresponding to a database, and detecting the load state of the database through the first coroutine to obtain a detection result;

when receiving a query request reported by a terminal, establishing a second protocol corresponding to the query request, and acquiring the detection result from the first protocol through the second protocol;

if the detection result represents that the database is in an overload state, stopping forwarding the query request to the database;

wherein, the detecting the load state of the database through the first routine to obtain the detection result comprises: sending a state detection message to the database through the first coroutine;

and if the response message of the database is not received within the specified time, the detection result indicates that the database is in an overload state.

2. The method of claim 1, wherein if the detection result indicates that the database is in a normal load state, the method further comprises:

forwarding the query request to the database.

3. The method of claim 2, wherein if the response message of the database is not received after reaching the preset duration threshold, the method further comprises:

restarting the database server;

wherein the duration threshold is greater than the prescribed time.

4. The method of claim 3, wherein restarting the database server comprises:

and calling and executing a restart instruction of the database server through the first coroutine.

5. The method of claim 1, wherein after the database server resumes a normal load state, the method further comprises:

re-forwarding the query request to the database.

6. The method of claim 5, wherein re-forwarding the query request to the database comprises:

after the query request is stopped being forwarded to the database, adding the query request into a waiting queue;

and after the database server recovers the normal load state, forwarding the query request in the waiting queue to the database.

7. The method of claim 5, wherein re-forwarding the query request to the database comprises:

and issuing indication information to the terminal to indicate the terminal to report the query request again.

8. The method of claim 1, further comprising:

and calling the reserved functional interface to send prompt information.

9. An apparatus for data request, the apparatus comprising:

an obtaining unit, configured to establish a second coroutine corresponding to a query request when the query request reported by a terminal is received, and obtain the detection result from the first coroutine established by the detection unit through the second coroutine;

the processing unit is used for stopping forwarding the query request to the database when the detection result obtained by the obtaining unit represents that the database is in an overload state;

the detection unit is configured to send a status detection packet to the database through the first protocol, and if a response packet of the database is not received within a specified time, the detection result indicates that the database is in an overload state.

10. The apparatus according to claim 9, wherein the processing unit is configured to forward the query request to the database when the detection result obtained by the obtaining unit indicates that the database is in a normal load state.

11. The apparatus of claim 10, further comprising:

the restarting unit is used for restarting the database server when the detection unit still does not receive the response message of the database after the preset duration threshold value is reached; wherein the duration threshold is greater than the prescribed time.

12. The apparatus of claim 11, wherein the restart unit is configured to call and execute a restart instruction of the database server through the first coroutine.

13. The apparatus according to claim 9, wherein the processing unit is configured to re-forward the query request to the database after the database server recovers a normal load state.

14. The apparatus of claim 13, wherein the processing unit comprises:

the first processing subunit is configured to add the query request to a waiting queue after the query request is stopped from being forwarded to the database, and forward the query request in the waiting queue to the database after the database server recovers a normal load state.

15. The apparatus of claim 13, wherein the processing unit comprises:

and the second processing subunit is used for issuing indication information to the terminal and indicating the terminal to report the query request again.

16. The apparatus of claim 9, further comprising:

and the calling unit is used for calling the reserved functional interface to send the prompt message.

17. A system for data request, the system comprising: the system comprises a terminal, a console and a database server; wherein the console comprises an apparatus as claimed in any one of the preceding claims 9 to 16;

the terminal is used for reporting a query request to the console, wherein the query request is used for requesting the database server to perform data query;

the database server is used for receiving the query request forwarded by the console when the detection result represents that the database is in a normal load state, responding to the query request and returning query content;

the console is also used for receiving the query content returned by the database server and sending the query content to the terminal.