CN111953772B

CN111953772B - Request processing method, device, server and storage medium

Info

Publication number: CN111953772B
Application number: CN202010801164.XA
Authority: CN
Inventors: 舒懿杰
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-08-11
Filing date: 2020-08-11
Publication date: 2022-11-22
Anticipated expiration: 2040-08-11
Also published as: CN111953772A

Abstract

The disclosure relates to a request processing method, a request processing device, a server and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: responding to a call request of a target interface of a second server in the server cluster, and determining a call request quantity parameter corresponding to the target interface, wherein the call request quantity parameter is used for representing the quantity of call requests which are not processed and completed in the server cluster; updating the quantity parameter of the call request; and controlling the second server to discard the call requests and update the call request quantity parameter again under the condition that the call request quantity parameter is greater than or equal to the target threshold value of the target interface. The number of the call requests which are not processed and completed in the server cluster is represented by the call request number parameter, and when the request processing time is abnormally prolonged, the current limitation can still be correctly triggered, so that the influence on other interfaces due to the abnormal prolongation of the request processing time of a certain interface is reduced, and the stability of the server cluster is improved.

Description

Request processing method, device, server and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a request processing method, an apparatus, a server, and a storage medium.

Background

When the number of requests received by the server is increased suddenly and the current resources of the server are insufficient to process a large number of received requests at the same time, the processing of the requests can be limited, i.e., limited, to avoid the server from crashing due to the flooding of a large number of requests. With the development of distributed services, a service may be distributed to operate on multiple servers in a server cluster, each server that operates the service is provided with at least one interface, and in the distributed service, it is necessary to limit a current for any interface of any service.

In the related art, for any interface of any service, the number of requests processed by the interface may be limited according to the total QPS (requests per second) of the interface on the server cluster. If the number of the requests received by the interface per second is not more than the current limiting threshold value of the interface, the server cluster normally processes the received requests; if the number of requests received per second by the interface is greater than the current limit threshold for the interface, the server cluster denies processing requests that exceed the current limit threshold.

In the above process, if the request processing time of a certain interface is abnormally prolonged and the number of requests received by the interface per second is not greater than the current limiting threshold of the interface, the server cluster does not limit the current of the interface. However, due to the extension of the request processing time, the interface occupies too much request processing resources, which causes that other interfaces are difficult to acquire the idle request processing resources to process requests, and the processing is abnormal, thereby causing poor stability of server cluster processing requests.

Disclosure of Invention

The embodiment of the disclosure provides a request processing method, a request processing device, a server and a storage medium, which can improve the stability of a server cluster. The technical scheme of the disclosure is as follows:

in one aspect, a request processing method is provided, and is applied to a first server in a server cluster, where the method includes:

responding to a call request of a target interface of a second server in a server cluster, and determining a call request quantity parameter corresponding to the target interface, wherein the call request quantity parameter is used for representing the quantity of the call requests which are not processed and completed in the server cluster;

updating the calling request quantity parameter;

and controlling the second server to discard the call requests under the condition that the call request quantity parameter is greater than or equal to a target threshold value of the target interface, and updating the call request quantity parameter again, wherein the target threshold value is the maximum quantity of the call requests which can be processed in the server cluster.

In a possible implementation manner, the determining, in response to a call request for a target interface of a second server in a server cluster, a call request quantity parameter corresponding to the target interface includes:

responding to a call request of a target interface of a second server in a server cluster, and acquiring the receiving time of the call request;

and determining the corresponding call request quantity parameter of the target interface in the time period associated with the receiving time according to the receiving time.

In another possible implementation manner, the determining, according to the receiving time, a parameter of a number of call requests corresponding to the target interface in a time period associated with the receiving time includes:

determining a first time period within which the reception time is located;

and determining the quantity parameter of the call requests corresponding to the first time period from the quantity parameters of the call requests corresponding to the target interface, wherein the quantity parameters of the call requests are respectively used for recording the quantity of the call requests which are not processed and completed in different time periods.

determining a first time period within which the reception time is located;

in response to that the time difference between the receiving time and the starting time of the first time period is smaller than a time difference threshold, determining a call request quantity parameter corresponding to the first time period and a call request quantity parameter corresponding to the second time period from a plurality of call request quantity parameters corresponding to the target interface, wherein the plurality of call request quantity parameters are respectively used for recording the number of call requests which are not processed and completed in different time periods, and the second time period is a last time period adjacent to the first time period;

and acquiring the sum of the call request quantity parameter corresponding to the first time period and the call request quantity parameter corresponding to the second time period as the call request quantity parameter corresponding to the target interface in the time period associated with the receiving time.

In another possible implementation manner, the updating the parameter of the number of call requests includes:

on the basis of the parameter of the number of the call requests, increasing a preset value, wherein the preset value is used for representing the number of the changed call requests;

the updating the parameter of the number of call requests again comprises the following steps:

and reducing the preset numerical value on the basis of the calling request quantity parameter.

In another possible implementation manner, the controlling the second server to discard the call request and update the call request number parameter again on the condition that the call request number parameter is greater than or equal to the target threshold of the target interface includes:

in response to the number of call requests parameter being greater than or equal to a target threshold of the target interface, sending a discard instruction to the second server, the discard instruction being used to instruct the second server to discard the call requests;

and updating the call request parameter again in response to first discarding information of the call request by the second server, wherein the first discarding information is used for indicating that the call request is discarded by the second server.

In another possible implementation manner, the controlling the second server to discard the call request and update the call request quantity parameter again on the condition that the call request quantity parameter is greater than or equal to the target threshold of the target interface includes:

sending the calling request quantity parameter to the second server;

and updating the call request parameter again in response to receiving second discarding information of the call request by the second server, wherein the second discarding information is used for indicating that the call request is discarded when the second server determines that the call request quantity parameter is greater than or equal to a target threshold value of the target interface.

In one aspect, a request processing apparatus applied to a first server in a server cluster is provided, the apparatus includes:

the determining unit is configured to execute a call request responding to a target interface of a second server in a server cluster, and determine a call request quantity parameter corresponding to the target interface, wherein the call request quantity parameter is used for representing the quantity of the call requests which are not processed and completed in the server cluster;

a first updating unit configured to perform updating of the call request quantity parameter;

a control unit configured to execute control of the second server to discard the call request on the condition that the parameter of the number of call requests is greater than or equal to a target threshold of the target interface;

a second updating unit configured to perform updating the call request quantity parameter again, wherein the target threshold is a maximum quantity of the call requests that can be processed in the server cluster.

In a possible implementation manner, the determining unit includes:

the acquisition subunit is configured to execute a call request responding to a target interface of a second server in the server cluster, and acquire the receiving time of the call request;

and the determining subunit is configured to determine, according to the receiving time, a parameter of the number of call requests corresponding to the target interface in a time period associated with the receiving time.

In another possible implementation manner, the determining subunit is configured to perform:

determining a first time period within which the reception time is located;

determining a call request quantity parameter corresponding to the first time period from a plurality of call request quantity parameters corresponding to the target interface, wherein the plurality of call request quantity parameters are respectively used for recording the number of call requests which are not processed and completed in different time periods.

determining a first time period within which the reception time is located;

In another possible implementation manner, the first updating unit is configured to perform:

the second updating unit is configured to execute:

and reducing the preset numerical value on the basis of the call request quantity parameter.

In another possible implementation manner, the control unit is configured to perform:

sending the calling request quantity parameter to the second server;

In one aspect, a server is provided, and the server includes: one or more processors; a memory for storing the processor-executable instructions; wherein the processor is configured to execute the instructions to implement the request processing method according to any one of the above possible implementation manners.

In one aspect, a storage medium is provided, and instructions in the storage medium, when executed by a processor of a server, enable the server to perform the request processing method according to any one of the above possible implementation manners.

In one aspect, a computer program product is provided, wherein instructions of the computer program product, when executed by a processor of a server, enable the server to perform the request processing method according to any one of the above possible implementations.

In the embodiment of the present disclosure, the first server represents the number of call requests to any interface in the server cluster by using the call request number parameter, updates the call request number parameter when the second server receives a call request to a certain interface, and updates the call request number parameter again after the second server completes processing of the call request, so that the call request number parameter can represent the number of call requests to the interface in the server cluster at any time. If the request processing time of the interface is abnormally prolonged, the call request quantity parameter of the interface is increased along with the increase of the received call requests, and the reduction of the call request quantity parameter is slow due to the prolongation of the request processing time, so that the call request quantity parameter is rapidly increased in a short time to reach the maximum quantity of call requests which can be processed by a server cluster, the current limiting processing of the call requests by a second server is triggered, the resources occupied by the interface due to the abnormal prolongation of the request processing time are reduced, the influence on other interfaces is reduced, and the stability of the server cluster is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

FIG. 1 is a schematic diagram illustrating a cluster of servers in accordance with an illustrative embodiment;

FIG. 2 is a flow diagram illustrating a method of request processing in accordance with an exemplary embodiment;

FIG. 3 is a flow chart illustrating a method of request processing in accordance with an exemplary embodiment;

FIG. 4 is a flow diagram illustrating a method of request processing in accordance with an exemplary embodiment;

FIG. 5 is a flowchart illustrating a method of request processing in accordance with an exemplary embodiment;

FIG. 6 is a diagram illustrating a determine call request quantity parameter in accordance with an illustrative embodiment;

FIG. 7 is a flow diagram illustrating a method of request processing in accordance with an exemplary embodiment;

FIG. 8 is a diagram illustrating a parameter for determining the number of invocation requests in accordance with an illustrative embodiment;

FIG. 9 is a block diagram illustrating a request processing device in accordance with an exemplary embodiment;

FIG. 10 is a block diagram illustrating a server in accordance with an example embodiment.

Detailed Description

In order to make the technical solutions of the present disclosure better understood, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in other sequences than those illustrated or described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the disclosure, as detailed in the appended claims.

FIG. 1 is a schematic diagram illustrating a server cluster in accordance with an exemplary embodiment. Referring to fig. 1, the server cluster 100 includes at least one first server 101 and a plurality of second servers 102.

Wherein the first server 101 generally refers to one of the at least one first server and the second server 102 generally refers to one of the plurality of second servers. A service is deployed on multiple second servers 102 simultaneously, and each second server 102 provides an interface of the service to the outside. The terminal or other server requests to call the interface of the service by sending a call request to the second server 102 in the server cluster 100, so as to obtain the corresponding return data.

The first server 101 assumes at least a request counting function in the server cluster 100. The first server 101 and the second server 102 are connected via a wireless or wired network. The first server 101 counts requests through interaction with the second server 102, and determines the number of call requests which are not processed and completed in the server cluster; and then when the number of the call requests which are not processed and finished in the server cluster is larger than the maximum number of the call requests which can be processed by the server cluster, carrying out current limiting processing on the call requests.

FIG. 2 is a flow diagram illustrating a request processing method in accordance with an exemplary embodiment. Referring to fig. 2, the request processing method is applied to a first server in a server cluster, and includes the following steps:

in step S201, in response to a call request to a target interface of a second server in the server cluster, a call request quantity parameter corresponding to the target interface is determined, where the call request quantity parameter is used to indicate the quantity of call requests that are not processed and completed in the server cluster.

In step S202, the call request number parameter is updated.

In step S203, the second server is controlled to discard the call requests and update the call request number parameter again under the condition that the call request number parameter is greater than or equal to a target threshold of the target interface, where the target threshold is the maximum number of call requests that can be processed in the server cluster.

In the embodiment of the present disclosure, the first server indicates, by using the parameter of the number of call requests, the number of call requests to any interface in the server cluster, and when the second server receives a call request to a certain interface, the parameter of the number of call requests is updated, and after the second server completes processing of the call request, the parameter of the number of call requests is updated again, so that the parameter of the number of call requests can indicate the number of call requests to the interface in the server cluster at any time. If the request processing time of the interface is abnormally prolonged, the call request quantity parameter of the interface is increased along with the increase of the received call requests, and the reduction of the call request quantity parameter is slow due to the prolongation of the request processing time, so that the call request quantity parameter is rapidly increased in a short time to reach the maximum quantity of call requests which can be processed by a server cluster, the flow limiting processing of the call requests by a second server is triggered, the resource occupied by the interface due to the abnormal prolongation of the request processing time is reduced, the influence on other interfaces is reduced, and the stability of the server cluster is improved.

FIG. 3 is a flow diagram illustrating a request processing method in accordance with an exemplary embodiment. In the embodiment of the present disclosure, taking an example that the second server performs the flow limiting processing on the invocation request based on the invocation request quantity parameter sent by the first server as an example, referring to fig. 3, the request processing method includes the following steps:

in step S301, the first server responds to a call request to a target interface of a second server in the server cluster, and determines a call request quantity parameter corresponding to the target interface.

The number parameter of the call requests is used for representing the number of call requests which are not processed and completed in the server cluster, and the call requests are used for requesting to call a target interface. In the embodiment of the present disclosure, a target interface is taken as an example of any one of the at least one interface.

In a possible implementation manner, the second server receives a call request for the target interface, and sends a request counting instruction to the first server, where the request counting instruction is used to indicate that the second server receives the call request for the target interface; and the first server responds to the request counting instruction and determines a calling request number parameter corresponding to the target interface.

The first server responds to the request counting instruction and determines the calling request quantity parameter corresponding to the target interface from the stored corresponding relation between the target interface and the calling request quantity parameter. Optionally, the first server is deployed with a remote dictionary service (redis), and stores the target interface and the call request quantity parameter based on the redis.

In step S302, the first server adds a preset value to the determined number of call requests parameter, where the preset value is used to indicate the number of changed call requests.

For example, the second server receives a call request for the target interface, and sends a request counting instruction to the first server, and the first server determines that the number parameter of the call requests corresponding to the target interface is 28; on the basis of the call request number parameter, 1 is added to obtain an updated call request number parameter 29.

In step S303, the first server sends the parameter of the number of call requests increased by the preset value to the second server.

The parameter of the number of the call requests after the preset value is increased is used for representing the number of the call requests to the target interface which are not processed and completed in the current server cluster. The unprocessed call request to the target interface in the current server cluster includes the call request received by the second server in step S301.

And the first server sends the calling request quantity parameter increased by the preset value to the second server, so that the second server can correspondingly process the calling request based on the calling request quantity parameter increased by the preset value.

In step S304, the second server receives the number of call requests parameter sent by the first server, and discards the call requests in response to the number of call requests parameter being greater than or equal to the target threshold of the target interface.

Wherein the target threshold is the maximum number of call requests that can be processed in the server cluster. The target threshold is any preset value, for example, the target threshold is 500, 800 or 1000. Optionally, the second server correspondingly stores the corresponding relationship between the target interface and the target threshold, receives the call request quantity parameter corresponding to the target interface, and determines the target threshold corresponding to the target interface from the stored corresponding relationship between the target interface and the target threshold.

The second server compares the calling request quantity parameter with a target threshold value; if the parameter of the number of call requests is greater than or equal to the target threshold, it indicates that the number of call requests that have not been processed in the server cluster has reached the upper limit of the call requests processed by the server cluster, and the second server does not continue to process the call requests received in step S301, that is, discards the call requests.

It should be noted that, if the parameter of the number of call requests is smaller than the target threshold, the second server continues to process the call requests according to the processing logic of the target interface.

In step S305, the second server sends second discard information to the first server, where the second discard information is used to indicate that the second server has discarded the call request.

And after determining to discard the call requests, the second server sends second discarding information to the first server, so that the first server updates the call request quantity parameter again based on the second discarding information, and the call request quantity parameter can represent the quantity of call requests which are not processed and completed by the server cluster at any time.

It should be noted that, if the second server processes the call request according to the processing logic of the target interface, the second server sends processing completion information to the first server after processing the call request according to the processing logic of the target interface is completed.

In step S306, the first server receives the second discard information, and reduces the preset value based on the parameter of the number of call requests.

It should be noted that, when the unprocessed call request indicated by the parameter of the number of call requests corresponding to the target interface is processed, the parameter of the number of call requests corresponding to the target interface is updated accordingly. Then, when the first server receives the second discard information, the call request quantity parameter may be processed by other call requests, and the first server updates the changed call request quantity parameter based on the second discard information, compared with the call request quantity parameter obtained in step S302 that has been changed.

For example, the updated call request number parameter obtained in step S302 is 29, and the second server completes processing of 3 call requests before the first server receives the second discard information, then in step S306, the first server decreases by 1 based on the second discard information on the basis of the changed call request number parameter 26, and obtains an updated call request number parameter 25.

It should be noted that, if the first server receives the processing completion information of the first server, the preset value is reduced on the basis of the parameter of the number of call requests. And the first server receives the processing completion information, the step of reducing the preset numerical value is performed on the basis of the calling request quantity parameter, the second server receives the second discarded information, and the step of reducing the preset numerical value is performed on the basis of the calling request quantity parameter in the same way.

FIG. 4 is a flow diagram illustrating a method of request processing in accordance with an exemplary embodiment. In the embodiment of the present disclosure, taking an example that a first server sends a discard instruction to a second server, and the second server is controlled to discard a call request, so as to implement flow limitation, referring to fig. 4, the request processing method includes the following steps:

in step S401, in response to a call request for a target interface of a second server in the server cluster, the first server determines a call request quantity parameter corresponding to the target interface.

Step S401 is similar to step S301, and will not be described herein again.

In step S402, the first server adds a preset value to the determined number of call requests parameter, where the preset value is used to indicate the number of changed call requests.

Step S402 is similar to step S302, and is not described herein again.

In step S403, in response to that the parameter of the number of call requests increased by the preset value is greater than or equal to the target threshold of the target interface, the first server sends a discard instruction to the second server, where the discard instruction is used to instruct the second server to discard the call requests.

Optionally, the first server stores a corresponding relationship between the target interface and the target threshold. The first server determines a target threshold value of a target interface from a corresponding relation between the target interface and the target threshold value; comparing the target threshold value with the calling request quantity parameter; if the number parameter of the call requests is greater than or equal to the target threshold, it indicates that the number of the call requests which are not processed and completed in the server cluster has reached the upper limit of the call requests processed by the server cluster, and sends a discard instruction to the second server, so that the second server discards the call requests and does not process the call requests any more.

It should be noted that, if the parameter of the number of call requests is smaller than the target threshold, a processing instruction is sent to the second server, so that the second server processes the call requests according to the processing logic of the target interface.

In step S404, the second server receives the discard instruction sent by the first server, and discards the call request.

And the second server receives the discarding instruction sent by the first server, and does not continue to process the call request, namely discards the call request.

It should be noted that, if the second server receives the processing instruction sent by the first server, the call request is processed according to the processing logic of the target interface.

In step S405, the second server sends first discard information to the first server, where the first discard information is used to indicate that the second server has discarded the call request.

Step S405 is the same as step S305, and is not described herein again.

In step S406, the first server receives the first discard information, and reduces the preset value based on the parameter of the number of call requests.

Step S406 is similar to step S306, and is not described herein again.

FIG. 5 is a flow diagram illustrating a request processing method in accordance with an exemplary embodiment. In the embodiment of the present disclosure, taking an example that the first server updates the call request quantity parameter according to the division of the time period, referring to fig. 5, the request processing method includes the following steps:

in step S501, the first server obtains a receiving time of a call request to a target interface of a second server in the server cluster in response to the call request.

In a possible implementation manner, the second server receives a call request for a target interface, and sends a request counting instruction to the first server, wherein the request counting instruction is used for indicating that the second server receives the call request for the target interface, and the request counting instruction carries receiving time of the call request; the first server obtains the receiving time of the calling request based on the request counting instruction.

In step S502, the first server determines a first time period during which the reception time is present.

It should be noted that the target interface corresponds to a plurality of time periods, each time period corresponds to one call request quantity parameter, and the call request quantity parameter corresponding to each time period is used for recording the quantity of call requests that are not processed and completed in the time period.

In a possible implementation manner, the target interface corresponds to a plurality of time periods, and the first server may determine, from the plurality of time periods, a first time period in which the receiving time is located, and accordingly, the step S502 includes: the first server respectively compares the receiving time with a plurality of time periods corresponding to the target interface; the time period in which the reception time is located is determined as a first time period.

For example, the receiving time is 1 hour 23 minutes 05 seconds at 27 days 4 and 27 in 2020, a time period corresponding to the target interface is 0 minutes 0 seconds at 0 hours at 27 days 0 at 4 and 27 days 2 at 27 months in 2020, the receiving time is in the time period, and the time period is the first time period.

In another possible implementation manner, the target interface corresponds to a plurality of time periods, the first server may further determine, according to a third time period determined last time, a first time period in which the receiving time is located from the plurality of time periods, and correspondingly, the step S502 includes: the first server acquires a last determined third time period from a plurality of time periods corresponding to the target interface; comparing the reception time with the third time period; in response to the reception time being within a third time period, determining the third time period as the first time period within which the reception time is located; in response to the receiving time not being within the third time period, acquiring a fourth time period adjacent to and after the third time period; comparing the reception time with the fourth time period; in response to the receive time being within the fourth time period, determining the fourth time period as the first time period within which the receive time is.

In the embodiment of the present disclosure, the first server determines the first time period in which the receiving time is located, with reference to the third time period determined last time. Because the receiving time of the received calling request is close to the last determined third time period, the receiving time is compared with the time periods by taking the third time period as a reference, the comparing time of the receiving time and the time periods can be reduced, the first time period in which the receiving time is located can be quickly determined, and the determining efficiency of the first time period is improved.

In another possible implementation manner, the first server may also continuously generate a corresponding time period for the target interface along with the reception of the request counting instruction, and accordingly, the step S502 includes: the first server compares the receiving time with the last generated time period corresponding to the target interface; determining a last generated time period as a first time period in response to a reception time being within the last generated time period; and in response to the fact that the receiving time is not in the time period generated last time, generating a first time period corresponding to the target interface, wherein the first time period comprises the receiving time.

The first time period is a time period of the target duration. The step of the first server generating the first time period may be: the first server takes the receiving time as the starting time of the first time period, and the time period of the target duration is determined to be the first time period. The step of the first server generating the first time period may also be: the first server takes the ending time of the time period generated last time as the starting time of the first time period, and determines the time period of the target duration as the first time period.

For example, the receiving time is 0 min 05 s at 2 h, 27 h, 4/27 h, 2020, and the last generated time period corresponding to the target interface may be 0 min 0 s at 0 h, 27 h, 4/27 h, 2020 to 0 min 0 s at 2 h, 27 h, 2020; the first server generates a first time period indicating a time period of the target duration in response to the time period not being generated last. The starting time of the first time period may be a reception time, and the first time period is 0 min 05 sec at 2 st at 27 st at 4 months in 2020 to 0 min 05 sec at 4 st at 27 st at 2020. The starting time of the first time period may be the ending time of the last generated time period, and the first time period is 0 min 0 s at 2 h, 4/27 h, 2020 to 0 min 0 s at 4 h, 27 h, 2020.

In the embodiment of the disclosure, the first server generates the first time period in which the receiving time is located along with the receiving of the request counting instruction, and the first server directly compares the receiving time with the last generated time period each time the request counting instruction is received, and generates the first time period if the receiving time is not in the last generated time period, so that the comparing time between the receiving time and the multiple time periods is reduced, and the determining efficiency of the first time period is improved.

In step S503, the first server determines a call request quantity parameter corresponding to the first time period from the call request quantity parameters corresponding to the target interface.

The multiple call request quantity parameters are respectively used for recording the number of call requests which are not processed and completed in different time periods. Each call request quantity parameter corresponds to a time period corresponding to the target interface.

In a possible implementation manner, the first server has stored a correspondence between a time period corresponding to the target interface and the call request quantity parameter, and the first server determines the call request quantity parameter corresponding to the first time period from the correspondence between the multiple time periods corresponding to the target interface and the call request quantity parameter.

In another possible implementation manner, the first time period is a newly generated time period, and the first server does not yet store the corresponding relationship between the first time period and the call request quantity parameter, so that the first server correspondingly stores the corresponding relationship between the first time period and the new call request quantity parameter. Wherein, the initial value of the new call request quantity parameter is 0.

In another possible implementation manner, if the receiving time of the call request is within the starting time period of the first time period, the call request represented by the call request quantity parameter corresponding to the second time period has not been processed yet, and there is an error between the call request quantity parameter corresponding to the first time period and the quantity of call requests that are actually unprocessed and completed by the target interface, the quantity of call requests that are unprocessed and completed by the target interface may be determined according to the call request quantity parameter corresponding to the first time period and the call request quantity parameter corresponding to the second time period. Accordingly, the step S503 may be replaced by the following steps: the first server determines a first time period in which the receiving time is located; in response to that the time difference between the receiving time and the starting time of the first time period is smaller than a time difference threshold, determining a calling request quantity parameter corresponding to the first time period and a calling request quantity parameter corresponding to a second time period from a plurality of calling request quantity parameters corresponding to the target interface, wherein the plurality of calling request quantity parameters are respectively used for recording the number of calling requests which are not processed and completed in different time periods, and the second time period is a previous time period adjacent to the first time period; and acquiring the sum of the call request quantity parameter corresponding to the first time period and the call request quantity parameter corresponding to the second time period as the call request quantity parameter corresponding to the target interface in the time period associated with the receiving time.

The time difference threshold may be any time period preset, for example, the time difference threshold may be 5 seconds, 8 seconds, or 10 seconds. The time difference threshold may also be determined based on a duration of time that the second server processes the request, for example, an average duration of time that the second server processes the request is 50 milliseconds, and the time difference threshold may be determined to be 50 milliseconds.

For example, fig. 6 is a schematic diagram illustrating a parameter for determining the number of call requests according to an exemplary embodiment, referring to fig. 6, where the vertical axis represents the number of call requests parameter at any time, the horizontal axis represents a time line for call request processing, and each block represents a request processing time period of one call request, starting from the receiving time of the call request to the processing end time of the call request.

If the first time period is the second time period, the second time period is the first time period, at the time t3, the first server is already at the receiving time of the request nine, and the call request quantity parameter corresponding to the first time period is increased for the request nine, and at the time t3, the call request quantity parameter corresponding to the first time period is 1. At time t3, the first server has increased and decreased the call request number parameter for the second time period for request one, request two, request three, request four, and request five, and has increased the call request number parameter for the second time period for request six, request seven, and request eight. At time t3, the call request quantity parameter corresponding to the second time period is 3. And adding the call request quantity parameter corresponding to the first time period and the call request quantity parameter corresponding to the second time period to obtain a sum value of 4, wherein the sum value is consistent with the quantity of the call requests which are not processed and finished by the target interface.

In the embodiment of the disclosure, if the receiving time of the call request is within the initial time period of the first time period, the first server determines the sum of the call request quantity parameters corresponding to two adjacent time periods as the quantity of the call requests unprocessed and completed by the target interface, so that the sum conforms to the quantity of the call requests unprocessed and completed by the target interface, thereby improving the accuracy of determining the quantity of the call requests unprocessed and completed by the target interface by the first server, further performing current limitation based on the quantity of the call requests unprocessed and completed by the target interface, reducing the occurrence of error current limitation, and improving the stability of cluster current limitation.

It should be noted that, the second server may generate a time period identifier of a time period in which the receiving time is located according to the receiving time of the invocation request, and send the time period identifier to the first server, so that the first server determines the corresponding invocation request quantity parameter according to the time period identifier. Accordingly, the above steps S501 to S503 may be replaced by the following steps: the second server receives a calling request of a target interface; determining a time period identifier corresponding to a first time period in which the receiving time is positioned according to the receiving time of the calling request; sending a request counting instruction to a first server, wherein the request counting instruction carries a time period identifier; the first server receives a request counting instruction; and determining the number parameter of the call requests corresponding to the time period identification according to the time period identification carried by the request counting instruction.

Optionally, a redis is deployed on the first server, and the first server correspondingly stores the time period identifier and the call request number parameter in a key (key) -value (value) form based on the redis, where the key represents the time period identifier and the value represents the call request number parameter. Fig. 7 is a flowchart illustrating a request processing method according to an exemplary embodiment, and referring to fig. 7, the second server receives a call request, and generates a time period identifier corresponding to a target interface according to a time period; and calling redis to accumulate the calling request quantity parameters corresponding to the time slot identification.

In step S504, the first server increases a preset value based on the parameter of the number of call requests corresponding to the first time period.

For example, the second server receives a call request for the target interface, the receiving time of the call request is 20 minutes 09 seconds at 27/2/4/2020, the second server sends a request counting instruction carrying the receiving time to the first server, the first server determines that a first time period of the receiving time is 0 minutes 0 seconds at 2/4/27/2020 to 0 minutes 0 seconds at 4/27/4/2020, and the number parameter of the call requests corresponding to the first time period is 5; then 1 is added on the basis of the call request quantity parameter to obtain an updated call request quantity parameter 6.

In order to make the process of updating the call request quantity parameter more clear, the following description is made with reference to fig. 6 and 8. Referring to fig. 6, the first server increases the call request quantity parameter corresponding to the first time period at the receiving time of request nine, the receiving time of request ten, the receiving time of request eleven, and the receiving time of request twelve, respectively. At time t4 in the first time period, the second server has increased the call request number parameter corresponding to the first time period for request nine, request ten and request eleven, respectively. At time t4, the call request number parameter for the first time period is 3.

Fig. 8 is a schematic diagram illustrating a parameter for determining the number of call requests according to an exemplary embodiment, and referring to fig. 8, the first server does not count the call requests of the target interface according to the division of the time period, that is, the target interface only corresponds to an infinite time period. At time t1, the call requests being processed by the target interface include a request one, a request two, a request three and a request four, and the number parameter of the call requests corresponding to the target interface is 4. If the operation that the first server reduces the number of the calling requests of the target interface fails when the first request is processed, the first server increases the number of the calling requests corresponding to the target interface to obtain 5 when the second server receives the fifth request; at time t2, the first server determines that the number parameter of the call requests corresponding to the target interface is 5, and the number of the call requests that are actually not processed and completed by the target interface is 4. Therefore, if the first server does not count the number of the call requests of the target interface through a plurality of time periods, and the operation of increasing or decreasing the number parameter of the call requests corresponding to the target interface by the first server fails, an error exists between the number parameter of the call requests corresponding to the target interface and the number of the call requests which are not processed and completed by the target interface. As time goes on, the situations of operation failure of the first server to increase or decrease the number parameter of the call requests corresponding to the target interface are accumulated continuously, so that the deviation between the number parameter of the call requests of the first server and the number of the call requests of the target interface which are not processed and completed really is larger and larger, and then the flow limitation is performed based on the number parameter of the call requests of the first server, which easily causes the occurrence of false flow limitation.

With continued reference to fig. 6, the first server counts the number of call requests of the target interface by a plurality of time periods, respectively. If the second time period is time period one, and the first server fails to reduce the number of call requests of the target interface when the processing of the first request is finished, at time t2, the number of call requests corresponding to the second time period is 5, an error exists between the number of call requests corresponding to the second time period and the number of call requests that are actually not processed and completed by the target interface, as time goes by, the first server increases or decreases the number of call requests corresponding to the first time period from the time when the second server receives the request nine, and at time t4, the number of call requests corresponding to the first time period is 3 and does not include the error generated in the second time period. And the first server gradually reduces the call request quantity parameter corresponding to the second time period along with the completion of the processing of the request two, the request three, the request four, the request five, the request six, the request seven and the request eight, so that the call request quantity parameter corresponding to the second time period is an error 1, and the call request quantity parameter of the first time period is not influenced.

In the embodiment of the disclosure, the first server counts the call requests of the target interface through a plurality of time periods, so that the call request quantity parameters corresponding to each time period are not affected by each other, the accumulation of errors of the call request quantity parameters corresponding to the target interface is reduced, the accuracy of determining the call request quantity parameters by the first server is improved, further, the current limitation is performed based on the determined call request quantity parameters, the occurrence of a wrong current limitation condition is reduced, and the stability and reliability of cluster current limitation are improved.

In step S505, the first server controls the second server to discard the call request and update the call request number parameter again on the condition that the call request number parameter is greater than or equal to the target threshold value of the target interface.

Step S505 is similar to steps S303 to S306 or steps S403 to S406, and is not repeated herein. The first server controls the second server to discard the call requests under the condition that the call request quantity parameter is greater than or equal to a target threshold value of the target interface; according to the receiving time of the call request, determining a call request quantity parameter corresponding to a first time period in which the call request is counted from a plurality of call request quantity parameters corresponding to a target interface; and reducing a preset value on the basis of the quantity parameter of the call request.

Continuing to refer to fig. 7, in an example, the second server calls redis to accumulate the call request quantity parameter corresponding to the time slot identifier, and determine whether the call request quantity parameter obtained by accumulation reaches a target threshold; and if the quantity parameter of the call requests obtained by accumulation does not reach the target threshold value, processing the call requests, namely executing the processing logic of the target interface on the call requests. And if the accumulated quantity parameter of the call requests reaches the target threshold value, the second server discards the call requests. Correspondingly, the second server discards the calling request or calls redis after the calling request is processed according to the processing logic of the target interface, so as to reduce the calling request parameters corresponding to the first time period, that is, the second server calls redis to deduct the calling request quantity parameters corresponding to the time period identifier. The second server may also return the request processing result to the terminal or other server that sent the invocation request. For example, after the second server discards the call request, the returned request processing result is that the system is busy, and processing is rejected. And after the second server finishes processing the call request according to the processing logic of the target interface, returning corresponding return data as a request processing result.

In the embodiment of the present disclosure, the first server represents the number of call requests to any interface in the server cluster by using the call request number parameter, updates the call request number parameter when the second server receives a call request to a certain interface, and updates the call request number parameter again after the second server completes processing of the call request, so that the call request number parameter can represent the number of call requests to the interface in the server cluster at any time. If the request processing time of the interface is abnormally prolonged, the call request quantity parameter of the interface is increased along with the increase of the received call requests, and the reduction of the call request quantity parameter is slow due to the prolongation of the request processing time, so that the call request quantity parameter is rapidly increased in a short time to reach the maximum quantity of call requests which can be processed by a server cluster, the flow limiting processing of the call requests by a second server is triggered, the resource occupied by the interface due to the abnormal prolongation of the request processing time is reduced, the influence on other interfaces is reduced, and the stability of the server cluster is improved.

All the above optional technical solutions may be combined arbitrarily to form the optional embodiments of the present disclosure, and are not described herein again.

FIG. 9 is a block diagram illustrating a request processing device in accordance with an exemplary embodiment. Referring to fig. 9, the apparatus is applied to a first server in a server cluster, and includes:

a determining unit 901, configured to execute, in response to a call request to a target interface of a second server in the server cluster, determining a call request quantity parameter corresponding to the target interface, where the call request quantity parameter is used to indicate the quantity of call requests that are not processed and completed in the server cluster;

a first updating unit 902 configured to perform updating the call request quantity parameter;

a control unit 903 configured to perform control of the second server to discard the call request on the condition that the parameter of the number of call requests is greater than or equal to a target threshold of the target interface;

a second updating unit 904 configured to perform updating the call request number parameter again, wherein the target threshold is a maximum number of call requests that can be processed in the server cluster.

In a possible implementation manner, the determining unit 901 includes:

an acquisition subunit configured to execute, in response to a call request to a target interface of a second server in the server cluster, acquiring a reception time of the call request;

and the determining subunit is configured to determine, according to the receiving time, a corresponding call request quantity parameter of the target interface in a time period associated with the receiving time.

In another possible implementation, the determining subunit is configured to perform:

determining a first time period in which the receiving time is located;

determining a call request quantity parameter corresponding to a first time period from a plurality of call request quantity parameters corresponding to a target interface, wherein the plurality of call request quantity parameters are respectively used for recording the number of call requests which are not processed and completed in different time periods.

determining a first time period in which the receiving time is located;

in response to that the time difference between the receiving time and the starting time of the first time period is smaller than a time difference threshold, determining a calling request quantity parameter corresponding to the first time period and a calling request quantity parameter corresponding to a second time period from a plurality of calling request quantity parameters corresponding to the target interface, wherein the plurality of calling request quantity parameters are respectively used for recording the number of calling requests which are not processed and completed in different time periods, and the second time period is a previous time period adjacent to the first time period;

In another possible implementation manner, the first updating unit 902 is configured to perform:

on the basis of the quantity parameter of the calling requests, increasing a preset value, wherein the preset value is used for representing the quantity of the changed calling requests;

a second updating unit 904 configured to perform:

and reducing a preset value on the basis of calling the request quantity parameter.

In another possible implementation, the control unit 903 is configured to perform:

in response to the call request quantity parameter being greater than or equal to the target threshold of the target interface, sending a discard instruction to the second server, wherein the discard instruction is used for instructing the second server to discard the call request;

sending a calling request quantity parameter to a second server;

and updating the parameters of the call requests again in response to receiving second discarding information of the call requests by the second server, wherein the second discarding information is used for indicating that the second server determines that the parameter of the number of the call requests is greater than or equal to a target threshold value of the target interface, and the call requests are discarded.

With regard to the apparatus in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be described in detail here.

It should be noted that: in the request processing apparatus provided in the foregoing embodiment, only the division of the functional modules is illustrated when performing the request processing, and in practical applications, the function distribution may be completed by different functional modules according to needs, that is, the internal structure of the first server is divided into different functional modules to complete all or part of the functions described above. In addition, the request processing apparatus and the request processing method provided by the above embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments and are not described herein again.

Fig. 10 is a block diagram of a server provided in an embodiment of the present disclosure, where the server 1000 may be a first server in the foregoing embodiment, or may be a second server in the foregoing embodiment. The server 1000 may generate a relatively large difference due to different configurations or performances, and may include one or more processors (CPUs) 1001 and one or more memories 1002, where the memories 1002 are used for storing executable instructions, and the processors 1001 are configured to execute the executable instructions to implement the request Processing method provided by each method embodiment. Of course, the server may also have components such as a wired or wireless network interface, a keyboard, and an input/output interface, so as to perform input/output, and the server may also include other components for implementing the functions of the device, which are not described herein again.

In an exemplary embodiment, there is also provided a storage medium comprising instructions, such as a memory 1002 comprising instructions, executable by a processor 1001 of the server 1000 to perform the request processing method described above. Alternatively, the storage medium may be a non-transitory computer readable storage medium, for example, the non-transitory computer readable storage medium may be a ROM (Read-Only Memory), a RAM (Random Access Memory), a CD-ROM (Compact Disc Read-Only Memory), a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, a computer program product is also provided, in which instructions, when executed by a processor of a server, enable the server to perform the request processing method in the above-described method embodiments.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A request processing method applied to a first server in a server cluster, wherein the first server is configured to assume a request counting function to determine the number of call requests that are not processed and completed in the server cluster, and the method comprises:

responding to a calling request of a terminal or other servers to a target interface of a second server in a server cluster, and determining a calling request quantity parameter corresponding to the target interface, wherein the calling request quantity parameter is used for representing the quantity of the calling requests which are not processed and completed in the server cluster;

controlling the second server to discard the call requests under the condition that the call request quantity parameter is greater than or equal to a target threshold of the target interface, and reducing the preset numerical value on the basis of the call request quantity parameter, wherein the target threshold is the maximum quantity of the call requests which can be processed in the server cluster;

under the condition that the request processing time of the target interface is abnormally prolonged, the call request quantity parameter of the target interface is increased along with the increase of the received call requests.

2. The method according to claim 1, wherein the determining, in response to a call request of a terminal or another server to a target interface of a second server in the server cluster, a call request quantity parameter corresponding to the target interface includes:

responding to a calling request of a terminal or other servers to a target interface of a second server in a server cluster, and acquiring receiving time of the calling request;

3. The method according to claim 2, wherein the determining, according to the receiving time, the parameter of the number of call requests corresponding to the target interface in the time period associated with the receiving time includes:

determining a first time period within which the reception time is located;

4. The method according to claim 2, wherein the determining, according to the receiving time, the parameter of the number of call requests corresponding to the target interface in the time period associated with the receiving time includes:

determining a first time period within which the reception time is located;

in response to that the time difference between the receiving time and the starting time of the first time period is smaller than a time difference threshold, determining a call request quantity parameter corresponding to the first time period and a call request quantity parameter corresponding to a second time period from a plurality of call request quantity parameters corresponding to the target interface, wherein the plurality of call request quantity parameters are respectively used for recording the number of call requests which are not processed and completed in different time periods, and the second time period is a last time period adjacent to the first time period;

5. The method according to claim 1, wherein the controlling the second server to discard the call request on the condition that the parameter of the number of call requests is greater than or equal to a target threshold of the target interface, and the reducing the preset value based on the parameter of the number of call requests comprises:

and in response to first discarding information of the second server for the call request, reducing the preset value on the basis of the call request quantity parameter, wherein the first discarding information is used for indicating that the second server discards the call request.

6. The method according to claim 1, wherein the controlling the second server to discard the call request on the condition that the parameter of the number of call requests is greater than or equal to a target threshold of the target interface, and the reducing the preset value based on the parameter of the number of call requests comprises:

sending the calling request quantity parameter to the second server;

and in response to receiving second discarding information of the second server for the call request, reducing the preset value on the basis of the call request quantity parameter, wherein the second discarding information is used for indicating that the second server determines that the call request quantity parameter is greater than or equal to a target threshold value of the target interface, and the call request is discarded.

7. A request processing apparatus applied to a first server in a server cluster, the first server being configured to perform a request counting function to determine the number of outstanding call requests in the server cluster, the apparatus comprising:

the determining unit is configured to execute a call request responding to a terminal or other servers for a target interface of a second server in a server cluster, and determine a call request quantity parameter corresponding to the target interface, wherein the call request quantity parameter is used for representing the quantity of the call requests which are not processed and completed in the server cluster;

the first updating unit is configured to increase a preset value on the basis of the call request quantity parameter, wherein the preset value is used for representing the changed quantity of the call requests;

a control unit configured to execute control of the second server to discard the call request on a condition that the call request number parameter is greater than or equal to a target threshold of the target interface;

and the second updating unit is configured to perform reduction on the preset numerical value on the basis of the call request quantity parameter, wherein the target threshold is the maximum quantity of the call requests which can be processed in the server cluster, and the call request quantity parameter of the target interface is increased along with increase of the received call requests under the condition that the request processing time of the target interface is abnormally prolonged.

8. The request processing apparatus according to claim 7, wherein the determining unit includes:

the acquisition subunit is configured to execute a call request of a terminal or other servers to a target interface of a second server in the server cluster, and acquire the receiving time of the call request;

9. The request processing apparatus according to claim 8, wherein the determining subunit is configured to perform:

determining a first time period within which the reception time is located;

10. The request processing apparatus according to claim 8, wherein the determining subunit is configured to perform:

determining a first time period within which the reception time is located;

11. The request processing apparatus according to claim 7, wherein the control unit is configured to perform:

12. The request processing apparatus according to claim 7, wherein the control unit is configured to perform:

sending the calling request quantity parameter to the second server;

13. A server, characterized in that the server comprises:

one or more processors;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the request processing method of any of claims 1 to 6.

14. A storage medium, wherein instructions in the storage medium, when executed by a processor of a server, enable the server to perform the request processing method of any one of claims 1 to 6.