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

Abstract

The invention discloses a data request method, device and system, relates to the technical field of the Internet, and is invented for solving the problem that a database is paralyzed due to too many query requests. The method of the present invention includes: establishing the first coroutine corresponding to the database, and detecting the load status of the database through the first coroutine to obtain the detection result; when receiving the query request reported by the terminal, establishing the second coroutine corresponding to the query request Coroutine, and obtain the test result from the first coroutine through the second coroutine; if the test result indicates that the database is in an overloaded state, stop forwarding the query request to the database. The invention is mainly applied in the postgresql database system.

Description

Method, device and system for data request

technical field

The present invention relates to the technical field of the Internet, in particular to a data request method, device and system.

Background technique

Inside the LAN, the console acts as a bridge between the terminal and the database, responsible for receiving, managing, and forwarding the query requests sent by the terminal to the database, and sending the query content returned by the database to the terminal. Usually, the processing resources allocated by the database server to query tasks are limited, and the number of query requests reported instantaneously in the local area network (hereinafter referred to as the number of concurrent requests) may be relatively large. In this case, the processing resources of the database server cannot handle all All query requests are responded to. At this time, the resource load pressure of the database is relatively high, and it is prone to paralysis. Once the database is paralyzed, it cannot be recovered, and the database server can only be restarted, thereby interrupting the normal operation of the local area network.

With the continuous growth of large-scale enterprises and institutions, the number of terminals in the LAN will increase, and the number of query requests in the network will increase accordingly, so the frequency of database failure will become higher and higher. For a large network, especially a multi-level network, the frequent failure of the 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 it can cope with the query requirements in a large-scale network environment has become a difficult problem for technicians.

Contents of the invention

In view of this, the present invention provides a data request method, device and system, which can solve the problem of database paralysis due to too many query requests.

In order to solve the above technical problems, on the one hand, the present invention provides a method for data request, the method comprising:

Establish the first coroutine corresponding to the database, and detect the load status of the database through the first coroutine, and obtain the detection result;

When the query request reported by the terminal is received, a second coroutine corresponding to the query request is established, and the detection result is obtained from the first coroutine through the second coroutine;

If the detection result indicates that the database is in an overloaded state, stop forwarding query requests to the database.

On the other hand, the present invention also provides a device for data request, which includes:

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

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

The processing unit is configured to stop forwarding the query request to the database when the detection result obtained by the obtaining unit indicates that the database is in an overloaded state.

In another aspect, the present invention also provides a data request system, the system includes: a terminal, a console, and a database server; wherein, the console includes the device referred to in the aforementioned second aspect;

The terminal is used to report a query request to the console, and the query request is used to request a data query from the database server;

The console is used to forward the query request to the database server when the detection result indicates that the database is in a normal load state, and stop forwarding the query request to the database server when the detection result indicates that the database is in an overloaded state;

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

The console is also used to receive the query content returned by the database server and send the query content to the terminal.

The data request method, device and system provided by the present invention can establish a resident first coroutine to continuously detect the load status of the database, and share the obtained detection results with the second coroutine established for the query request, So that the latter forwards or cancels the forwarding of the query request based on different detection results. Compared with the prior art, the present invention can suspend the forwarding of query requests when the database is in an overloaded state, and can give the database enough time to process existing requests in a timely manner and release corresponding processing resources, thereby preventing the database from being overwhelmed by query requests. Too much can lead to paralysis.

The above description is only an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the description, and in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable , the specific embodiments of the present invention are enumerated below.

Description of 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 embodiment. The drawings are only for the purpose of illustrating a preferred embodiment and are not to be considered as limiting the invention. Also throughout the drawings, the same reference numerals are used to designate the same components. In the attached picture:

Fig. 1 shows a flow chart of a data request method provided by the present invention;

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

Fig. 3 shows a flow chart of another data request method provided by the present invention;

Fig. 4 shows the schematic diagram of the waiting queue provided by the present invention;

Fig. 5 (a) and Fig. 5 (b) have shown the schematic diagram of hybrid forwarding query request provided by the present invention;

Fig. 6 shows a schematic structural diagram of a device for data request provided by the present invention;

Fig. 7 shows a schematic structural diagram of another data request device provided by the present invention;

Fig. 8 shows a schematic diagram of a data request system provided by the present invention.

Detailed ways

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although 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 by the embodiments set forth herein. Rather, these embodiments are provided for more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

In order to prevent the database from being paralyzed due to too many query requests, the embodiment of the present invention provides a data request method, which can suspend the forwarding of query requests when the database is in an overloaded state, thus allowing the database to have sufficient time to process A request has already been processed. As shown in Figure 1, the method includes:

101. Establish a first coroutine corresponding to the database, and detect the load status of the database through the first coroutine, and obtain a detection result.

When starting the database, the console creates an independent first coroutine, which is specially used to detect the load status of the database. The first coroutine in this embodiment is a resident coroutine, that is, the coroutine is established when the database is initialized and survives the entire process of data query. No matter whether the console receives the query request reported by the terminal, as long as the life cycle of the database is not over, the first coroutine will keep alive and continuously detect the resource load status of the database.

It should be noted that the continuous detection described in this embodiment refers to a process of maintaining a detection state, and is not limited to the situation of uninterrupted detection. In practical applications, the above-mentioned continuous detection method also includes: periodic detection according to a certain preset time interval, or irregular detection according to the instructions of the console, or automatic detection based on a certain preset strategy/rule Etc., this embodiment does not limit the timing, number of times or frequency of the first coroutine detecting the state of the database.

In this embodiment, the resource parameters that can reflect the database resource load status may be: memory usage ratio, central processing unit (Central Processing Unit, CPU for short) usage ratio, disk read-write interface usage ratio, and the like. 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, obtain the above resource parameters (or a combination of resource parameters), and obtain the detection result of the database load status by comparing with the preset standard threshold.

Under normal circumstances, the database server usually does not allocate all processing resources to data query tasks. Therefore, in practical applications, the usage ratio of the above resource parameters should be the usage ratio under the actual resource allocation range. For example, suppose that for a database server with 4G memory, if it allocates 1G memory resources for processing query requests, then when the current processing query request occupies 0.4G memory, its actual memory usage ratio should be 40%, not 10%.

The above detection method for obtaining resource parameters is only one of the implementation methods of this embodiment. In practical applications, the console may not care about the specific resource parameters of the database, but directly detects the response speed of the database from the result level. If the response speed of the database is too slow (it takes a long time), it indicates that the resource load of the database exceeds the normal capacity. In other words, the response speed of the database can comprehensively reflect the occupancy of various internal resources. Therefore, in practical applications, it is usually easier to test the response speed, and more ideal detection results can be obtained. This embodiment will focus on taking this detection method as an example for description later.

In this embodiment, the detection results acquired by the console may have different presentation forms. In an implementation of this embodiment, the detection result may be a gear level that can describe the load status of the database, such as "idle", "busy", "saturated", "overloaded", etc. Different gears are used for Reflect the different load levels of the database; or in another implementation of this embodiment, the test result can also be a simple value, such as 45, 67, etc., the size of the value is used to reflect the load level of the database, for this In this form, it is necessary to ensure that the value has a value range with a boundary, and the upper and lower boundaries of the range should correspond to two extreme load levels of the database (such as zero load and overload, etc.). In order to simplify the implementation in practical applications, in the third implementation of this embodiment, the detection results are only divided into two levels of "normal load state" and "overload state", and the boundaries between the two levels can be combined by the administrator. Factors such as network scale and database performance are comprehensively considered and set, and can also be calculated by the console according to preset rules and policies, and can be dynamically adjusted. Since it is easy to implement, the third form of detection result will be taken as an example for description later in this embodiment.

102. When receiving the query request reported by the terminal, establish a second coroutine corresponding to the query request, and obtain a detection result from the first coroutine through the second coroutine.

Different from the console directly forwarding the query request to the database in the prior art, in this embodiment, before the console forwards the query request to the database, it first needs to obtain the database status from the first coroutine through the second coroutine corresponding to the request As a result of the detection, when the database is in an overload state, the following step 103 is performed to stop forwarding query requests, thereby reducing the load pressure on the database.

The second coroutine in this step is a coroutine established for the query request and independent of the aforementioned first coroutine. When the console receives several query requests, it will establish several second coroutines, and there is no substantial relationship between the second coroutines. In this embodiment, the second coroutine is established based on the report of the query request, and ends after the query request obtains a query response or when the query is terminated. Compared with the life cycle of the first coroutine, the life cycle of the second coroutine is usually shorter.

In this embodiment, the first coroutine is dedicated to detecting the load status of the database, and is not responsible for sending the detection result to the second coroutine. Therefore, when the second coroutine forwards the query request to the database, it needs to actively ask the first coroutine for Test results. In practical applications, the number of concurrent requests on the console side is usually large, so the second coroutine corresponding to each query request needs to request the detection result from the first coroutine separately, and the actions of each coroutine to obtain the detection result are independent of each other , this embodiment does not limit all the second coroutines to request the detection results at the same time. In addition, as mentioned above, the detection of the database by the first coroutine is continuous. Based on the continuous change of the database load status, the detection results obtained by the first coroutine at different times may be different, while the second coroutine requests the detection The timing of the results is different, so in actual applications, the detection results obtained by different second coroutines may be different. For example, the detection result obtained by the second coroutine of request 1 in the previous period is "overload state", while the test result of request 2 The detection result obtained by the second coroutine in the next period is "normal load state". Based on different detection results, the processing results of different query requests are of course different.

103. If the detection result indicates that the database is in an overloaded state, stop forwarding the query request to the database.

When the detection result obtained by the second coroutine is that the database is in an overload state, the console stops sending the query request corresponding to the second coroutine to the database. For the subsequent processing of the query request, in an implementation of this embodiment, the console can discard the query request and notify the terminal. For the terminal, it is equivalent to the end of the query process; and in this embodiment In another implementation of , the console can also "suspend" the query request, and forward it to the database when the load pressure on the database is reduced.

In this step, the console can independently establish a processing coroutine to perform the operation of discarding or suspending the request. In practical applications, the console can separately establish a processing coroutine for each request that needs to be processed, and end the process after the processing is completed. The processing coroutine can also be resident in a general coroutine, and the general coroutine processes each query request uniformly.

In practical applications, no matter whether the processing coroutine is established separately or the general coroutine is established, a part of the processing resources of the console will be occupied. In order to avoid unnecessary overhead of console processing resources, in an implementation manner of this embodiment, the console may use an existing second coroutine to perform operations such as discarding and suspending requests.

104. If the detection result indicates that the database is in a normal load state, forward the query request to the database.

For the detection result obtained in step 102, if it indicates that the database is in a normal load state, it means that the processing resources of the database are partially idle, and will not be paralyzed due to further increase in query requests. Therefore, in this case, the console can receive The query request is sent to the database for response, and the query content returned by the database is forwarded to the terminal, thus completing a regular data query process.

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

In the prior art, as an intermediary between the terminal and the database, the console is only responsible for sending the query requests reported by the terminal to the database for processing. Send query request. Therefore, the database is easy to be paralyzed due to excessive resource load, and once the database is paralyzed, it cannot be recovered, and the database server can only be restarted, thereby interrupting the normal operation of the local area network. In this embodiment, the console can detect the load status of the database, and when the database load is too large, it will suspend sending query requests, thereby giving the database a chance to digest existing requests, preventing the database from being paralyzed, and improving the operating efficiency of the local area network. stability.

Secondly, in this embodiment, the console can continuously detect the database through a resident first coroutine, and the second coroutine can directly "request" the detection result from the first coroutine for subsequent processing operations. From the perspective of technical implementation, the second coroutine can also directly detect the database, but due to the large number of second coroutines, a large number of repeated detection operations will inevitably waste the limited processing resources of the console. In this embodiment, the repeated execution of similar operations can be reduced through the design idea of "result sharing", and the resource overhead of the console can be minimized.

Third, compared with performing corresponding operations through processes or threads in the prior art, this embodiment can perform various operations through lighter-weight coroutines. Since the coroutine is a program executed purely in the background, the terminal foreground or database server is completely unaware of the execution of its operation. Therefore, in addition to saving thread resources, the use of coroutines can also reduce the impact of execution operations on business operations.

Further, as a refinement of step 101 in Figure 1, in another embodiment of the present invention, the console can detect the response speed of the database through the first coroutine, so as to obtain a detection result that can comprehensively reflect the status of database resources . Specifically, as shown in Figure 2, the method includes:

201. Send a status detection message to the database through the first coroutine.

The status detection message is the same as the traditional data message in message format, and its header needs to carry the IP addresses of the console and the database as the source IP address and the destination IP address respectively. But different from the traditional data message, the status detection message is only used to test the response speed of the database, and its data content has no practical significance for the state, so the administrator can set the data content of the message at will, for example, the Its data content is set to "Hello DB" or "Test".

It should be noted that, since the content of the status detection message has no practical significance, the data content of the message should not be set too large from the perspective of saving network transmission bandwidth. In practical applications, it is more appropriate to control the data volume below tens of bytes.

As mentioned above, the detection of the status of the database is a continuous process. During the entire life cycle of the database, the console will periodically or randomly perform multiple status detections. Therefore, the number of times the console sends status detection messages is usually not It will be limited to one or a few times. In practical applications, the timing for the console to send the status detection message is determined by the timing when it starts the status detection, and the number of times the status detection message is sent is usually not less than the number of status detections.

202. Start local timing and wait for receiving a response message from the database.

203. Receive a response message from the database and stop timing.

When initializing the settings, the administrator can pre-set the content of the database reply. Similar to the status detection message, the content of the response message has no practical significance. In practical applications, it can be set to "Im OK" or "So Far So Good", etc.

In this step, the console starts local timing when sending the status detection message, the purpose of which is to calculate the time taken for the database to return the response message. In an implementation manner of this embodiment, the console can call the timer function interface to start timing through the first coroutine (of course, a separate coroutine can also be established). In addition, the console can also obtain the time value of sending the status detection message and receiving the response message by reading the system clock, and obtain the response time of the database based on the difference between the two time values. For the latter implementation, in practical applications, the console can read the atomic clock on the hardware main board, and can also read the system clock on the network side, which is not limited in this implementation.

204. Comparing the response time of the database with the preset specified time.

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

It should be noted that, for the setting of the specified time, in addition to considering the terminal's sensitivity to delay, the normal time consumption involved in message transmission should also be taken into consideration. In practical applications, the setting of the specified time can generally be limited to the ms level. In special cases (for example, the network cannot tolerate the slightest delay), the setting of the specified time can also be close to 0ms. This embodiment does not limit the size of the specified time .

205. Determine that the database is in an overloaded state.

206. Determine that the database is in a normal load state.

It should be noted that in practical applications, when the database load is heavy, there may be a situation where the database cannot feed back a response message. At this time, it is unrealistic for the console to blindly wait for the response message. Therefore, for this situation, a set of remedial plans should be formulated. In an implementation manner of this embodiment, the console may allow the administrator to set a duration threshold, and the threshold generally needs to be greater than the aforementioned specified time (for example, 500 ms, 1000 ms, etc.). When the timing of the console reaches the duration threshold, a state judgment is made. If the response message fed back by the database has not been received, the console stops timing and executes step 205 to directly determine that the database is in an overloaded state. But for the method of reading the system clock, since it does not involve local timing, the console cannot know whether the time consumed by the database exceeds the threshold value, so this implementation method is not suitable for this remedy.

In practical applications, after stopping sending query requests to the database, if the database still cannot digest existing requests, it can be determined that the database cannot be recovered normally. In this case, to ensure the normal operation of the LAN, the database server can be restarted. The restarted database will release all occupied processing resources, so normal processing of query requests can be resumed.

When judging whether the database cannot be recovered normally, the time dimension can be used as a reference standard. The console obtains a preset duration threshold, and after sending a status detection message to the database, the console starts local timing. If no response message from the database is received after reaching the time threshold, it is judged that the database cannot be recovered normally, and the database server is restarted. In this embodiment, the foregoing duration threshold may be greater than the foregoing duration threshold, but this embodiment does not limit its specific value.

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

Further, when the query request in the database is congested, so that restarting the database server still cannot completely release all occupied resources, the console can further restart the console server by itself. After the console server is restarted, all query requests received by the console are discarded, thus releasing the occupied processing resources. In addition, when re-establishing a connection with a terminal, the console can also limit the number of connected terminals, thereby further helping to reduce the load on the database. Similar to restarting the database server mentioned above, the console can also restart itself by calling the corresponding restart command.

The above embodiments have described the different processing modes executed by the console for different detection results. In an embodiment below, a processing method for receiving requests after the database returns to a normal load state will be given. Specifically, as shown in Figure 3, the method includes:

301. Establish a first coroutine corresponding to the database, and detect the load status of the database through the first coroutine, and obtain a detection result.

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

302. When receiving a query request reported by the terminal, establish a second coroutine corresponding to the query request, and obtain a detection result from the first coroutine through the second coroutine.

303. Stop forwarding the query request to the database.

304. Each second coroutine continues to obtain the detection result from the first coroutine.

In this step, when the forwarding of the query request is stopped due to the overload of the database, in addition to directly discarding the request, the console can also "suspend" each query request. When the database returns to a normal state, continue to re-forward the "suspended" query request to the database.

It should be noted that when the database is overloaded, the console can suspend the received query request and wait for it to be forwarded again. However, the console should reject the newly reported query request from the terminal, otherwise the number of requests gathered by the console will continue to increase, crowding out the processing resources of the console.

Since it involves re-determining the load state of the database, each second coroutine needs to continuously obtain new detection results. In practical applications, each second coroutine obtains the detection result from the first coroutine at regular intervals (for example, every 100 ms). When the obtained test result reflects that the database has returned to a normal load state, execute step 305 to re-forward the query request; and when the obtained test result reflects that the database is still in an overloaded state, continue to execute this step and wait for the next test result to be obtained . In practical applications, the time interval for the second coroutine to obtain the detection results can be consistent with the time interval for the first coroutine to detect the state of the database, that is, to ensure that the detection results obtained by the first coroutine every time can be obtained by the second coroutine. , so that query requests can be forwarded to the database for processing as soon as possible.

305. When the database returns to a normal load state, forward the query request to the database.

When the database returns to the normal load state, the console sends the waiting forwarding query request to the database through the second coroutine for response, and obtains the query content.

Below, an implementation of Figure 3 is given:

The console pre-establishes a waiting queue to store pending query requests. When the database is overloaded, the console will add query requests to the waiting queue for forwarding. When the database returns to the normal load state, the console forwards the query requests in the waiting queue to the database sequentially, starting from the head of the waiting queue, according to the first-in-first-out principle, until the waiting queue is emptied. Exemplarily, the query requests in the waiting queue may be as shown in FIG. 4 .

Furthermore, when the waiting queue is long, in order to prevent the newly reported query request from the terminal from waiting too long, in an improved way, the console can also perform mixed forwarding of the query request in the waiting queue and the newly received query request, Thus, both requests are considered in parallel. Exemplarily, as shown in FIG. 5 , request A represents a query request in a waiting queue, and request B represents a query request newly reported by a terminal. The console cross-forwards the two requests, for example, the "ABABABA..." method shown in Figure 5a. Of course, the console can also perform batch cross-forwarding in the manner of "AAABBBAAABBB..." shown in FIG. 5b. This embodiment does not limit the specific mixing mode adopted by the console.

Further, for the above implementation of joining the queue, the establishment and maintenance of the queue, and the enqueueing and dequeueing of requests will all cause a certain amount of memory occupation on the console. In a simpler implementation, the console can cancel the establishment of the waiting queue, and instead use random preemption to forward query requests. In this manner, the second coroutine of each request continuously obtains the latest detection request according to the implementation manner of the aforementioned step 304 . When the second coroutine finds that the database has returned to a normal load state, it forwards the request immediately. The execution of each second thread's preemptive forwarding is independent of each other, and the order of request forwarding is determined by the order in which the second thread starts preemption. Furthermore, after the database returns to the normal load state, the query request newly reported by the terminal can also participate in random preemptive forwarding, and preempt forwarding opportunities 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, so the terminal cannot know whether the database is in an overload state. In the above-mentioned embodiments, the terminal does not need to care about the load status of the database, and only needs to report the query request in the traditional way. Therefore, there will be a problem, that is, when the console stops forwarding the query request, the terminal will continue to report new query requests. When a large number of query requests are congested in the console, it is easy to cause the console to crash. In order to prevent a large backlog of query requests in the console, in another embodiment of the present invention, when the database is in an overloaded state, the console can send instruction information to each terminal, instructing the terminal to temporarily stop reporting new query requests, by This keeps the number of requests to the console under control. Correspondingly, when the database returns to a normal load state, the console can also send instruction information to each terminal, instructing the terminal to resume reporting query requests.

Furthermore, in the existing local area network architecture, usually administrators can monitor the local area network through a dedicated human-computer interaction platform. In yet another embodiment of the present invention, when the load status of the database changes, the console can also send prompt information to the administrator platform, so that the administrator can make corresponding decisions in time.

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

Further, as an implementation of the above-mentioned method embodiments, another embodiment of the present invention also provides a device for data request, which can be located in the console, or be independent of the console but establish a data request between the console and the console. The interaction relationship is used to realize the foregoing method embodiments. It should be noted that the console described in this embodiment may also be a server with network management functions in practical applications. As shown in FIG. 6, the device 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 the load status of the database through the first coroutine to obtain a detection result;

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

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 a normal load state.

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

Further, as shown in Figure 7, the device further includes:

The restart unit 64 is configured to restart the database server when the detection unit 61 has not received a response message from the database after reaching a preset time threshold; wherein the time threshold is greater than a specified time.

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

Further, the processing unit 63 is configured to re-forward the query request to the database after the database server returns to a 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 stopping forwarding the query request to the database, and forward the query request in the waiting queue to the database after the database server returns to a normal load state.

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

The second processing subunit 632 is configured to deliver indication information to the terminal, instructing the terminal to re-report the query request.

Further, as shown in Figure 7, the device further includes:

The calling unit 65 is used for calling the reserved function interface to send prompt information.

Furthermore, another embodiment of the present invention also provides a data request system as an implementation of the foregoing method embodiments. As shown in FIG. 8 , the system includes: a terminal 81 , a console 82 and a database server 83 . Wherein, the console may also be a server with network management functions in practical applications. The console 82 includes the devices as previously shown in FIG. 6 or FIG. 7 .

The terminal 81 is used to report a query request to the console 82, and the query request is used to request a data query from the database server 83;

The console 82 is used to forward the query request to the database server 83 when the test result indicates that the database is in a normal load state, and stop forwarding the query request to the database server 83 when the test result indicates that the database is in an overloaded state;

The database server 83 is used 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 the query content;

The console 82 is also used to receive the query content returned by the database server 83 and send the query content to the terminal 81 .

In the prior art, as an intermediary between the terminal and the database, the console is only responsible for sending the query requests reported by the terminal to the database for processing. Send query request. Therefore, the database is easy to be paralyzed due to excessive resource load, and once the database is paralyzed, it cannot be recovered, and the database server can only be restarted, thereby interrupting the normal operation of the local area network. Based on the device and system provided in this embodiment, the console can detect the load status of the database, and when the database load is too large, it will suspend sending query requests, thereby giving the database an opportunity to digest existing requests, preventing the database from being paralyzed, and then Improve the stability of LAN operation.

Secondly, based on the device and system provided in this embodiment, the console can continuously detect the database through a resident first coroutine, and the second coroutine can directly "request" the detection result from the first coroutine for subsequent Processing operations. From the perspective of technical implementation, the second coroutine can also directly detect the database, but due to the large number of second coroutines, a large number of repeated detection operations will inevitably waste the limited processing resources of the console. In this embodiment, the repeated execution of similar operations can be reduced through the design idea of "result sharing", and the resource overhead of the console can be minimized.

Third, compared with performing corresponding operations through processes or threads in the prior art, the device and system provided by this embodiment can perform various operations through lighter-weight coroutines. Since the coroutine is a program executed purely in the background, the terminal foreground or database server is completely unaware of the execution of its operation. Therefore, in addition to saving thread resources, the use of coroutines can also reduce the impact of execution operations on business operations.

In the foregoing embodiments, the descriptions of each embodiment have their own emphases, and for parts not described in detail in a certain embodiment, reference may be made to relevant descriptions of other embodiments.

It can be understood that related features in the above methods and devices can refer to each other. In addition, "first", "second" and so on in the above embodiments are used to distinguish each embodiment, and do not represent the advantages and disadvantages of each embodiment.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

The algorithms and displays presented herein are not inherently related to any particular computer, virtual system, or other device. Various generic systems can also be used with the teachings based on this. The structure required to construct such a system is apparent from the above description. Furthermore, the present invention is not specific to any particular programming language. It should be understood that various programming languages can be used to implement the contents of the present invention described herein, and the above description of specific languages is for disclosing the best mode of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood 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 the understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, in order to streamline this disclosure and to facilitate an understanding of one or more of the various inventive aspects, various features of the invention are sometimes grouped together in a single embodiment, figure, or its description. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention 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 can understand that the modules in the device in the embodiment can be adaptively changed and arranged in one or more devices different from the embodiment. Modules or units or components in the embodiments may be combined into one module or unit or component, and furthermore may be divided into a plurality of sub-modules or sub-units or sub-assemblies. All features disclosed in this specification (including accompanying claims, abstract and drawings) and any method or method so disclosed may be used in any combination, except that at least some of such features and/or processes or units are mutually exclusive. All processes or units of equipment are combined. Each feature disclosed in this specification (including 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 understand that although some embodiments described herein include some features included in other embodiments but not others, combinations of features from 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 present 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 should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of some or all of the object flow monitoring method, device, and system according to the embodiments of the present invention. Full functionality. The present invention can also be implemented as an apparatus or an apparatus program (for example, a computer program and a computer program product) for performing a part or all of the methods described herein. Such a program for realizing the present invention may be stored on a computer-readable medium, or may be in the form of one or more signals. Such a signal may be downloaded from an Internet site, or provided on a carrier signal, or provided 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 can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The use of the words first, second, and third, etc. does not indicate any order. These words can be interpreted as names.

Claims (17)

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:

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;

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 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 content;

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