A request sending method, device, electronic device and storage medium

Abstract

The present application discloses a request sending method, device, electronic device and storage medium. The sending method includes: placing the collected input requests in an elastic queue; judging whether the load timer has reached the timing period; judging whether the input requests in the elastic queue have reached the dynamic trigger condition; if there is an input request in the elastic queue that has reached the dynamic trigger condition, then sending the input request that has reached the dynamic trigger condition; if all input requests in the elastic queue have not reached the dynamic trigger condition, then not sending the input request and continuing to collect the input request, and continuing to place the collected input request in the elastic queue. The present application reduces unnecessary consumption of network and service resources. For specific input content requests, the trigger conditions can be flexibly set, and even inserted at runtime, to achieve scalable and more efficient input processing. Set a load timer to solve the problem of too single timeout mechanism.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a request sending method, device, electronic device and storage medium. Background Art

[0002] Currently, there are three methods and systems for large-scale or high-frequency input requests, including intra-process module, inter-process and network requests, and signal communication:

[0003] 1. Load balancing: Distribute input or requests to different processing entities according to certain rules, including process modules, different processes, different network hosts, and even different communication units, so as to distribute the load to different operation units for processing.

[0004] 2. Message Queue (MQ): Input or request is moved into the head of a queue structure, and then the processing entity removes the input or request from the tail of the queue for processing, such as: consumer and producer mode.

[0005] 3. Denial of Service (DoS): Inputs or requests that exceed pre-set upper limits, such as thresholds, are discarded to ensure the processing capacity and stability of the existing system.

[0006] The above existing technical solutions all have the following shortcomings and problems:

[0007] 1. The processing end is at the input or request response end (such as the server end of a network request), which causes processing lag and increases unnecessary consumption of network and service resources.

[0008] 2. It is transparent to input requests, that is, it does not care about the specific input content and cannot provide scalable and more efficient processing for specific input requests.

[0009] 3. The timeout mechanism is too simple, limited to connection timeout, read timeout and write timeout, and cannot handle the duration factors in the input request more efficiently.

[0010] With respect to the above-mentioned problems of the prior art, no effective solution has been proposed yet. Summary of the invention

[0011] The main purpose of the present application is to provide a request sending method, device, electronic device and storage medium to solve the problems of processing lag at the processing end, the inability to expand fixed input requests and the overly single timeout mechanism in the related technology.

[0012] In order to achieve the above purpose, this application provides a request sending method:

[0013] Step S1: placing the collected input requests in an elastic queue;

[0014] Step S2: Determine whether the load timer reaches the timing cycle;

[0015] Step S3: If the load timer has not reached the timing period, continue to wait and go to S2 to continue to determine whether the load timer has reached the timing period;

[0016] Step S4: if the load timer reaches the timing period, determine whether the input request in the elastic queue meets the dynamic trigger condition;

[0017] Step S5: If there is an input request in the elastic queue that has reached the dynamic trigger condition, then send the input request that has reached the dynamic trigger condition;

[0018] Step S6: If all input requests in the elastic queue do not meet the dynamic triggering condition, no input request is sent and the input requests continue to be collected, and the collected input requests continue to be placed in the elastic queue, and go to step S1.

[0019] The load timer is a global timer. The client sending the request and the server receiving the request share the same timer, and the load timer is asynchronous with the dynamic trigger condition, that is, the time when the dynamic trigger condition is met is not synchronized with the predetermined period of the load timer.

[0020] This application proposes an input damping algorithm and device for high-frequency input (i.e., a large number of input requests in a short period of time), which can effectively reduce the ineffective consumption of network and system resources, thereby increasing throughput, enhancing data processing capabilities, and improving system flexibility and availability. In the case of high-frequency input, i.e., intensive input, how to "damp" or buffer the pressure on the responder in a short period of time is similar to the shock absorber of a car, which keeps the car body stable when it hits stones and uneven roads.

[0021] The dynamic trigger condition determines whether an input request in the current elastic queue satisfies a certain dynamic trigger condition based on multiple dynamic trigger conditions according to a priority level and within a timing period of a load timer.

[0022] The priority level is set in advance, using a nonlinear time function, the closer the time is to the current time, the higher the priority level is, and the farther the time is from the current time, the lower the priority level is.

[0023] The priority level also includes setting the priority level that meets a certain dynamic trigger condition as the highest.

[0024] The multiple dynamic trigger conditions are manually pre-set by semantic rules or multiple keywords.

[0025] The dynamic trigger conditions described in this application dynamically adjust the processing mechanism according to the content and environment of the request, and can also perform semantic processing.

[0026] The queue capacity of the elastic queue satisfies the following formula:

[0027] L(x)=k(x-x0) / deltaT

[0028] Among them, k refers to the elastic coefficient, which is set according to the application scenario. Similar to the resistance coefficient of spring elastic force, the elastic coefficient can be a value or calculated by a correlation function. x refers to the size of the input information entropy, and x0 refers to the minimum information entropy of the system. deltaT refers to the duration, which is calculated from the period of the dynamic trigger condition.

[0029] The application scenarios include four scenarios: in-process module, inter-process, network request and signal communication.

[0030] If the elastic queue has exceeded its capacity or has reached the critical point of a preset value, the load timer receives a trigger condition that the current load of the client or server where the elastic queue is located is full, and the elastic queue no longer receives input requests until the load of the client or server where the elastic queue is located is reduced, and the condition that the load is not full is re-triggered and sent to the load timer.

[0031] The load timer is globally shared. If the server is fully loaded, the server sends a trigger condition indicating that the server is fully loaded to the load timer. The load timer then starts running in the next execution cycle until the current server load decreases and the load condition is re-triggered and sent to the load timer. Before the client sends a request, the load timer (the same load timer shared with the server) will also execute periodically.

[0032] So there is no need to wait for the server to notify the client, they all just notify the same load timer, and the load timer is not limited to one program, one machine, but can also be a cluster that can be synchronized with each other.

[0033] The elastic queue can be independently deployed on the client or server.

[0034] A request sending device is implemented by using a request sending method, comprising:

[0035] The collection module places the collected input requests in an elastic queue;

[0036] The load timer is globally shared, so that the entire device is synchronized under the same timing cycle;

[0037] A judgment module determines whether the input request in the elastic queue meets the dynamic trigger condition;

[0038] a sending module, which sends the input request that has reached the dynamic trigger condition if there is an input request that has reached the dynamic trigger condition in the elastic queue;

[0039] The acquisition module, load timer, judgment module and sending module are connected in sequence.

[0040] An electronic device comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor runs the computer program to enable the computer device to send a request.

[0041] A readable storage medium, characterized in that the readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a processor, a request sending method is described.

[0042] Beneficial technical effects:

[0043] 1. It can be deployed not only at the receiving or responding end (such as the server end of network requests or the output end of inter-component communication), but also at the initiating or requesting end of input or request (such as the client end of network requests or the input end of inter-component communication). It can pre-determine when the elastic queue is about to be overloaded, reducing unnecessary consumption of network and service resources.

[0044] 2. For specific input content requests, flexibly set trigger conditions, and even insert them at runtime to achieve scalable and more efficient input processing.

[0045] 3. Set a load timer to solve the problem of the timeout mechanism being too single, which greatly enriches the processing model of time factors. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The drawings constituting a part of this application are used to provide a further understanding of this application, so that other features, purposes and advantages of this application become more obvious. The schematic embodiment drawings and their descriptions of this application are used to explain this application and do not constitute an improper limitation on this application. In the drawings:

[0047] Figure 1 It is a flow chart of a request sending method provided according to an embodiment of the present application;

[0048] Figure 2 is a block diagram of a request sending device provided according to an embodiment of the present application;

[0049] Figure 3It is a signaling interaction diagram of a request sending method provided according to an embodiment of the present application;

[0050] Figure 4 An asynchronous flow chart of trigger conditions and load timers is provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0052] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0053] In the present application, the terms "upper", "lower", "left", "right", "front", "back", "top", "bottom", "inner", "outer", "middle", "vertical", "horizontal", "lateral", "longitudinal" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the drawings. These terms are mainly used to better describe the present application and its embodiments, and are not used to limit the indicated devices, elements or components to have a specific orientation, or to be constructed and operated in a specific orientation.

[0054] In addition, some of the above terms may be used to express other meanings in addition to indicating orientation or positional relationship. For example, the term "on" may also be used to express a certain dependency or connection relationship in some cases. For those of ordinary skill in the art, the specific meanings of these terms in this application can be understood according to specific circumstances.

[0055] In addition, the term "plurality" shall mean two or more.

[0056] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0057] This application provides a request sending method, such as Figure 1 As shown:

[0058] Step S1: placing the collected input requests in an elastic queue;

[0059] Step S2: Determine whether the load timer reaches the timing cycle;

[0060] Step S3: If the load timer has not reached the timing period, continue to wait and go to S2 to continue to determine whether the load timer has reached the timing period;

[0061] Step S4: if the load timer reaches the timing period, determine whether the input request in the elastic queue meets the dynamic trigger condition;

[0062] Step S5: If there is an input request in the elastic queue that has reached the dynamic trigger condition, then send the input request that has reached the dynamic trigger condition;

[0063] Step S6: If all input requests in the elastic queue do not meet the dynamic triggering condition, no input request is sent and the input requests continue to be collected, and the collected input requests continue to be placed in the elastic queue, and go to step S1.

[0064] For example, if we search for "an apple", Figure 3 As shown:

[0065] When I search for "one", in fact, in the existing technology, this "one" has already been triggered. When this event is triggered, it has already made a request to the server. However, "one" is meaningless. "An apple" is meaningful, which is the semantic trigger condition.

[0066] The word "apple" only has real meaning when it appears. The input "one" is blocked on the client side and "one" is placed in the elastic queue. When "one apple" is received, the trigger condition is met and the input request is sent.

[0067] "One apple" is a semantic rule. If the request does not trigger the semantic rule, the request is temporarily not a real request. At this time, it will be blocked and the input request will be placed in the elastic queue.

[0068] In addition, for the case of high-frequency and intensive input (i.e., a large number of input requests in a short period of time), this application proposes an input damping algorithm and device, which can effectively reduce the ineffective consumption of network and system resources, thereby increasing throughput, enhancing data processing capabilities, and improving system flexibility and availability. In the case of high-frequency input, i.e., intensive input, how to "damp" or buffer the pressure on the responder in a short period of time is similar to the shock absorber of a car, which keeps the car body stable when it hits stones and uneven roads.

[0069] When the trigger condition is not triggered, no request occurs, and the load on the network will not be increased. The input request cannot have been sent to the server, avoiding the server that has already received it. And at the service level, it is judged that the packet may be overloaded or the given conditions do not allow it, and then it may be discarded or pushed into a queue on the server. This puts a lot of pressure on the server, and the server may accept many useless requests. In fact, it also occupies the network transmission resources.

[0070] The load timer is a global timer. The client sending the request and the server receiving the request share the same timer. The load timer is asynchronous with the dynamic trigger condition, that is, the time when the dynamic trigger condition is satisfied is not synchronized with the cycle predetermined by the load timer. Figure 4 shown.

[0071] Therefore, elastic queues can be deployed independently on the client or server, and can process requests before they are sent, thereby reducing unnecessary network requests and reducing the consumption of network or server resources.

[0072] The dynamic trigger condition determines whether an input request in the current elastic queue satisfies a certain dynamic trigger condition based on multiple dynamic trigger conditions according to a priority level and within a timing period of a load timer.

[0073] The priority level is pre-set based on cold data and hot data, using a non-linear time function. The closer the time is to the current time, the higher the priority level is, and the farther the time is from the current time, the lower the priority level is.

[0074] This is similar to cooling in physics. For example, a newly generated input request is "hot" data and has a higher priority, while an input request that has existed for a longer time is "cold" data and has a lower priority. Unlike traditional queues, the priority algorithm is not one-dimensional, that is, only a first-after relationship. The priority can be calculated by setting the cooling coefficient, which can be used as a trigger condition for changing the queue release.

[0075] The priority level also includes setting the priority level that meets a certain dynamic trigger condition as the highest.

[0076] The multiple dynamic trigger conditions are manually pre-set semantic rules or multiple keywords. The keywords are short-term or temporary.

[0077] The dynamic trigger conditions described in this application dynamically adjust the processing mechanism according to the content and environment of the request, and can also perform semantic processing.

[0078] The queue capacity of the elastic queue satisfies the following formula:

[0079] L(x)=k(x-x0) / deltaT

[0080] Among them, k refers to the elastic coefficient, which is set according to the application scenario. Similar to the resistance coefficient of spring elastic force, the elastic coefficient can be a value or calculated by a correlation function. x refers to the size of the input information entropy, and x0 refers to the minimum information entropy of the system. deltaT refers to the duration, which is calculated from the period of the dynamic trigger condition.

[0081] The application scenarios include four scenarios: in-process module, inter-process, network request and signal communication.

[0082] The load timer of the in-process module should be implemented in the form of independent threads between the in-process modules.

[0083] Among the processes, the load counter should be implemented in the form of an independent process or service.

[0084] The network request and the load timer can be distributed at both ends of the network request and implemented in the form of independent threads or independent process services, or can be deployed only on the client side or only on the server side.

[0085] The signal communication, the load timer can be an independent operation, which can communicate with other input and output terminals or request receiving and request processing terminals.

[0086] If the elastic queue has exceeded its capacity or has reached the critical point of a preset value, the load timer receives a trigger condition that the current load of the client or server where the elastic queue is located is full, and the elastic queue no longer receives input requests until the load of the client or server where the elastic queue is located is reduced, and the condition that the load is not full is re-triggered and sent to the load timer. The load timer selects to send input requests that meet the trigger condition according to its set timing period.

[0087] The load timer is globally shared. If the server is fully loaded, the server sends a trigger condition indicating that the server is fully loaded to the load timer. The load timer then starts running in the next execution cycle until the current server load decreases and the load condition is re-triggered and sent to the load timer. Before the client sends a request, the load timer (the same load timer shared with the server) will also execute periodically.

[0088] So there is no need to wait for the server to notify the client, they all just notify the same load timer, and the load timer is not limited to one program, one machine, but can also be a cluster that can be synchronized with each other.

[0089] Due to the existence of independently running load timers, the trigger conditions can be passed to the timer in the form of parameters (intra-process or inter-process) or signals (inter-process, network, signal communication). The timer can then load it and make conditional judgments in the next running cycle, thereby achieving scalable and flexible processing of specific input requests.

[0090] The elastic queue can be independently deployed on the client or server.

[0091] A request sending device is implemented by using a request sending method, such as Figure 2 As shown, including:

[0092] The collection module places the collected input requests in an elastic queue;

[0093] The load timer is globally shared, so that the entire device is synchronized under the same timing cycle;

[0094] A judgment module determines whether the input request in the elastic queue meets the dynamic trigger condition;

[0095] a sending module, which sends the input request that has reached the dynamic trigger condition if there is an input request that has reached the dynamic trigger condition in the elastic queue;

[0096] The acquisition module, load timer, judgment module and sending module are connected in sequence.

[0097] An electronic device comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor runs the computer program to enable the computer device to send a request.

[0098] A readable storage medium, characterized in that the readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a processor, a request sending method is described.

[0099] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A request sending method, characterized in that: include: Step S1: placing the collected input requests in an elastic queue; Step S2: Determine whether the load timer reaches the timing cycle; Step S3: If the load timer has not reached the timing period, continue to wait and go to S2 to continue to determine whether the load timer has reached the timing period; Step S4: if the load timer reaches the timing period, determine whether the input request in the elastic queue meets the dynamic trigger condition; Step S5: If there is an input request in the elastic queue that has reached the dynamic trigger condition, then send the input request that has reached the dynamic trigger condition; Step S6: If all input requests in the elastic queue do not meet the dynamic trigger condition, no input request is sent and the input request continues to be collected, and the collected input request continues to be placed in the elastic queue, and the process goes to step S1; The dynamic trigger condition determines whether an input request in the current elastic queue satisfies a certain dynamic trigger condition based on multiple dynamic trigger conditions according to the priority level and under the timing period of the load timer; The multiple dynamic trigger conditions are manually pre-set by semantic rules or multiple keywords.

2. The request sending method according to claim 1, characterized in that: The load timer is a global timer. The client sending the request and the server receiving the request share the same timer, and the load timer is asynchronous with the dynamic trigger condition, that is, the time when the dynamic trigger condition is met is not synchronized with the predetermined period of the load timer.

3. The request sending method according to claim 1, wherein: The priority level is pre-set, using a non-linear time function, the closer the time is to the current time, the higher the priority level is, and the farther the time is from the current time, the lower the priority level is; The priority level also includes setting the priority level that meets a certain dynamic trigger condition as the highest.

4. The request sending method according to claim 1, wherein: The queue capacity of the elastic queue satisfies the following formula: L(x)=k(x-x0) / deltaT Among them, k refers to the elasticity coefficient, which is set according to the application scenario; x refers to the size of the input information entropy, and x0 refers to the minimum information entropy of the system; deltaT refers to the duration, which is calculated from the period of the dynamic trigger condition; The application scenarios include four scenarios: in-process module, inter-process, network request and signal communication.

5. The request sending method according to claim 4, characterized in that: If the elastic queue has exceeded its capacity or has reached the critical point of a preset value, the load timer receives a trigger condition that the current load of the client or server where the elastic queue is located is full, and the elastic queue no longer receives input requests until the load of the client or server where the elastic queue is located is reduced, and the condition that the load is not full is re-triggered and sent to the load timer. The load timer selects to send input requests that meet the trigger condition according to its set timing period.

6. The request sending method according to claim 1 or 2, characterized in that: The elastic queue can be independently deployed on the client or server.

7. A request sending device, characterized in that: The request sending method according to any one of claims 1 to 6 is implemented, comprising: The collection module places the collected input requests in an elastic queue; The load timer is globally shared, so that the entire device is synchronized under the same timing cycle; A judgment module determines whether the input request in the elastic queue meets the dynamic trigger condition; a sending module, which sends the input request that has reached the dynamic trigger condition if there is an input request that has reached the dynamic trigger condition in the elastic queue; The acquisition module, the load timer, the judgment module and the sending module are connected in sequence; The dynamic trigger condition determines whether an input request in the current elastic queue satisfies a certain dynamic trigger condition based on multiple dynamic trigger conditions according to the priority level and under the timing period of the load timer; The multiple dynamic trigger conditions are manually pre-set by semantic rules or multiple keywords.

8. An electronic device, characterized in that: The electronic device comprises a memory and a processor, the memory is used to store a computer program, and the processor runs the computer program to enable the computer device to execute a request sending method according to any one of claims 1-6.

9. A readable storage medium, characterized in that: The readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a processor, a request sending method according to any one of claims 1 to 6 is executed.

Images