CN111432012A - Asynchronous communication method, device, system, terminal and computer readable storage medium - Google Patents

Asynchronous communication method, device, system, terminal and computer readable storage medium Download PDF

Info

Publication number
CN111432012A
CN111432012A CN202010237333.1A CN202010237333A CN111432012A CN 111432012 A CN111432012 A CN 111432012A CN 202010237333 A CN202010237333 A CN 202010237333A CN 111432012 A CN111432012 A CN 111432012A
Authority
CN
China
Prior art keywords
terminal
request
real
time
available
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010237333.1A
Other languages
Chinese (zh)
Inventor
陈建斌
吕观祥
董霖
叶新江
方毅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang Meiri Interdynamic Network Technology Co ltd
Original Assignee
Zhejiang Meiri Interdynamic Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang Meiri Interdynamic Network Technology Co ltd filed Critical Zhejiang Meiri Interdynamic Network Technology Co ltd
Priority to CN202010237333.1A priority Critical patent/CN111432012A/en
Publication of CN111432012A publication Critical patent/CN111432012A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1012Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The invention provides an asynchronous communication method, an asynchronous communication device, an asynchronous communication system, a terminal and a computer readable storage medium, wherein the method comprises the following steps: acquiring real-time working parameters from the second terminal; responding to the acquisition of the real-time working parameters, and judging whether the real-time working parameters are within a specified threshold range; when the real-time working parameters are not within the specified threshold range, determining the second terminal as an unavailable request processing party; when the real-time working parameters are within the specified threshold value range, determining the second terminal as an available request processing party; distributing the pending requests to all available request processing parties including the second terminal according to a predetermined distribution strategy. According to the technical scheme, the to-be-processed requests can be distributed among the request processing parties in a balanced manner based on the processing capacity of each request processing party, the balance of request distribution is improved, and the efficiency of asynchronous communication is improved.

Description

Asynchronous communication method, device, system, terminal and computer readable storage medium
[ technical field ] A method for producing a semiconductor device
The present invention relates to the field of communications technologies, and in particular, to an asynchronous communication method, an asynchronous communication device, an asynchronous communication system, a terminal, and a computer-readable storage medium.
[ background of the invention ]
Asynchronous communication is widely used in communication technology because of its advantage of low communication cost. In current asynchronous communication systems, a request initiator often has multiple request handlers. Generally, the request initiator may randomly transmit its own pending request to a plurality of request handlers, or sequentially transmit its own pending requests to the plurality of request handlers according to the order of the plurality of request handlers.
However, this request allocation is blind to the request originator and cannot predict whether the request handler can handle the request successfully. In other words, the request handler may fail to process the request allocated by the request initiator in time due to a failure, an overload, and the like, thereby affecting the efficiency of asynchronous communication.
Therefore, how to reduce the influence of the uncertainty of the processing capability of the request processing party on the asynchronous communication efficiency becomes a technical problem to be solved at present.
[ summary of the invention ]
The embodiment of the invention provides an asynchronous communication method, an asynchronous communication device, an asynchronous communication system, an asynchronous communication terminal and a computer readable storage medium, and aims to solve the technical problem that the efficiency of asynchronous communication is influenced by insufficient processing capacity of a request processing party in the related art.
In a first aspect, an embodiment of the present invention provides an asynchronous communication method, used for a first terminal, where the first terminal performs asynchronous communication with multiple available request processing parties when serving as a request initiator, and the method includes: acquiring real-time working parameters from the second terminal; responding to the acquisition of the real-time working parameters, and judging whether the real-time working parameters are within a specified threshold range; when the real-time working parameters are not within the specified threshold range, determining the second terminal as an unavailable request processing party; when the real-time working parameters are within the specified threshold value range, determining the second terminal as an available request processing party; distributing the pending requests to all available request processing parties including the second terminal according to a predetermined distribution strategy.
In a second aspect, an embodiment of the present invention provides an asynchronous communication method, which is used for a second terminal, where when a first terminal is used as a request initiator in asynchronous communication, the second terminal is a request handler, and the method includes: acquiring real-time working parameters; sending the real-time working parameters to a first terminal so that the first terminal can judge whether the second terminal is an available request processing party or not based on the real-time working parameters, and the first terminal distributes a request to be processed to the available request processing party; detecting whether the request to be processed distributed by the first terminal is received; and adding the request to be processed into a request processing queue when the request to be processed is received.
In a third aspect, an embodiment of the present invention provides an asynchronous communication apparatus, configured to a first terminal, where the first terminal performs asynchronous communication with multiple available request processing parties when serving as a request initiator, and the apparatus includes: the parameter acquisition unit is used for acquiring real-time working parameters from the second terminal; the parameter judgment unit is used for responding to the acquisition of the real-time working parameters and judging whether the real-time working parameters are within a specified threshold range; the first processing unit is used for determining the second terminal as an unavailable request processing party when the real-time working parameters are not in the specified threshold range; the second processing unit is used for determining the second terminal as an available request processing party when the real-time working parameters are within the specified threshold range; and the request distribution unit is used for distributing the requests to be processed to all available request processing parties including the second terminal according to a preset distribution strategy.
In a fourth aspect, an embodiment of the present invention provides an asynchronous communication apparatus, which is used for a second terminal, where when a first terminal is used as a request initiator in asynchronous communication, the second terminal is a request handler, and the apparatus includes: the parameter acquisition unit is used for acquiring real-time working parameters; a parameter sending unit, configured to send the real-time operating parameter to a first terminal, so that the first terminal determines, based on the real-time operating parameter, whether the second terminal is an available request handler, and the first terminal allocates a request to be processed to the available request handler; a request detection unit, configured to detect whether the to-be-processed request allocated by the first terminal is received; and the request processing unit is used for adding the request to be processed into a request processing queue when the request to be processed is received.
In a fifth aspect, an embodiment of the present invention provides an asynchronous communication system, including a first terminal and a second terminal, where when the first terminal is used as a request initiator, the second terminal is used as a request handler, and when the first terminal performs asynchronous communication with multiple available request handlers, the second terminal obtains real-time operating parameters; the second terminal sends the real-time working parameters to the first terminal; the first terminal responds to the acquisition of the real-time working parameters and judges whether the real-time working parameters are within a specified threshold range; when the real-time working parameters are not in the specified threshold range, the first terminal determines the second terminal as an unavailable request processing party; the first terminal determines the second terminal as an available request processing party when the real-time working parameters are within the specified threshold range; and the first terminal distributes the request to be processed to all available request processing parties including the second terminal according to a preset distribution strategy.
In a sixth aspect, an embodiment of the present invention provides a terminal, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being arranged to perform the method of any of the first and second aspects above.
In a seventh aspect, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for performing the method according to any one of the first and second aspects.
In the asynchronous communication process of the related art, the request initiator blindly sends the self request to be processed to the plurality of request processors randomly or sequentially, and the influence of the processing capacity of the request processors on the asynchronous communication efficiency is not considered. The above technical solution provides that the request processing party reports its real-time working parameters to the request initiating party, and the request initiating party can judge whether the request processing party has sufficient processing capability based on the real-time working parameters of the request processing party. Further, the request initiator can only distribute the request to be processed to the request processor with sufficient processing capacity, so as to adapt to the actual processing capacity of the request processor and ensure that the request to be processed is processed timely and smoothly.
In particular, an asynchronous communication system may include a first terminal and a second terminal. In the asynchronous communication process, when the first terminal serves as a request initiator, the first terminal distributes the self pending request to a plurality of available request processing parties. The request processing party is available, which means that the request processing party has enough processing capacity to process the pending request allocated by the first terminal, and therefore, a plurality of available request processing parties can effectively process the pending request allocated by the request processing party.
The second terminal acts as a request handler for the first terminal whether it can obtain and handle the pending request assigned by the first terminal, depending on whether the second terminal is an available request handler. The condition available to the request handler is that there is sufficient processing capacity to handle the pending request assigned by the first terminal, and the sufficient processing capacity is determined by its real-time operating parameters.
Therefore, the second terminal can report the real-time working parameters of the second terminal to the first terminal. Then, before the first terminal allocates the pending request, it may determine whether the real-time operating parameter of the second terminal is within a specified threshold range. Wherein, the specified threshold range refers to the range of the operating parameters required by the second terminal to have enough processing capacity to process the pending request allocated by the first terminal.
If the real-time operating parameter of the second terminal is not within the specified threshold range, it indicates that the second terminal cannot efficiently and smoothly process the pending request allocated by the first terminal in the operating state determined by the real-time operating parameter. At this time, the first terminal may determine that the second terminal is an unavailable request handler, and when allocating the pending request, no longer allocate to the second terminal.
If the real-time working parameter of the second terminal is within the range of the designated threshold, the second terminal has the capability of efficiently and smoothly processing the to-be-processed request distributed by the first terminal under the working state determined by the real-time working parameter. At this time, the first terminal may determine that the second terminal is an available request processing party, and when allocating the pending request, allocate the pending request to all available request processing parties including the second terminal according to a predetermined allocation policy.
According to the technical scheme, the request initiator can acquire the processing capacity of the request processors in the high-speed asynchronous communication, so that the requests to be processed are distributed among the request processors in a balanced manner based on the processing capacity of each request processor, and the condition that the overall efficiency of the asynchronous communication is influenced because a large number of requests to be processed are distributed to the request processors with insufficient processing capacity is avoided. On the basis of fully utilizing the system resources of each request processing party, the balance of request allocation is improved, and the efficiency of asynchronous communication is improved.
[ description of the drawings ]
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 shows a flow diagram of an asynchronous communication method according to one embodiment of the invention;
FIG. 2 shows a flow diagram of an asynchronous communication method according to another embodiment of the invention;
FIG. 3 illustrates a flow diagram of an asynchronous communication method according to yet another embodiment of the present invention;
FIG. 4 shows a block diagram of an asynchronous communication device according to an embodiment of the invention;
FIG. 5 shows a block diagram of an asynchronous communication device according to another embodiment of the invention;
fig. 6 shows a block diagram of a terminal according to an embodiment of the invention.
[ detailed description ] embodiments
For better understanding of the technical solutions of the present invention, the following detailed descriptions of the embodiments of the present invention are provided with reference to the accompanying drawings.
It should be understood that the described embodiments are only some embodiments of the invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the examples of the present invention and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
In the asynchronous communication process of the related art, the request initiator blindly sends the self request to be processed to the plurality of request processors randomly or sequentially, and the influence of the processing capacity of the request processors on the asynchronous communication efficiency is not considered.
In contrast, in the technical solution of the present application, the request processing party may report its real-time operating parameter to the request initiating party, and the request initiating party may determine whether the request processing party has sufficient processing capability based on the real-time operating parameter of the request processing party. Further, the request initiator can only distribute the request to be processed to the request processor with sufficient processing capacity, so as to adapt to the actual processing capacity of the request processor and ensure that the request to be processed is processed timely and smoothly.
The technical solution of the present application is described in detail by the following specific examples.
Fig. 1 shows a flow diagram of an asynchronous communication method according to an embodiment of the invention.
As shown in fig. 1, a flow of an asynchronous communication method according to an embodiment of the present invention is applied to a first terminal, and includes:
and 102, acquiring real-time working parameters from the second terminal.
An asynchronous communication system may include a first terminal and a second terminal. In the asynchronous communication process, when the first terminal serves as a request initiator, the first terminal distributes the self pending request to a plurality of available request processing parties. The request processing party is available, which means that the request processing party has enough processing capacity to process the pending request allocated by the first terminal, and therefore, a plurality of available request processing parties can effectively process the pending request allocated by the request processing party.
The second terminal acts as a request handler for the first terminal whether it can obtain and handle the pending request assigned by the first terminal, depending on whether the second terminal is an available request handler. The condition available to the request handler is that there is sufficient processing capacity to handle the pending request assigned by the first terminal, and the sufficient processing capacity is determined by its real-time operating parameters.
Therefore, the second terminal can report the real-time working parameters to the first terminal so that the first terminal can judge whether the second terminal is available.
Wherein the real-time operating parameters include, but are not limited to, a combination of one or more of: the queue length of the to-be-processed request, the processing time required for processing all the to-be-processed requests, the remaining memory, the CPU occupancy rate, and the working parameters determined based on the CPU occupancy rate and/or the remaining memory, and the real-time working parameters may also be any parameters capable of expressing the processing capability of the terminal on the request.
And 104, responding to the acquisition of the real-time working parameters, and judging whether the real-time working parameters are within a specified threshold range, wherein when the real-time working parameters are not within the specified threshold range, the step 106 is executed, and when the real-time working parameters are within the specified threshold range, the step 108 is executed.
Before the first terminal distributes the request to be processed, whether the real-time working parameters of the second terminal are within the range of the specified threshold value is judged. Wherein, the specified threshold range refers to the range of the operating parameters required by the second terminal to have enough processing capacity to process the pending request allocated by the first terminal.
And 106, determining the second terminal as an unavailable request processing party.
If the real-time operating parameter of the second terminal is not within the specified threshold range, it indicates that the second terminal cannot efficiently and smoothly process the pending request allocated by the first terminal in the operating state determined by the real-time operating parameter. At this time, the first terminal may determine that the second terminal is an unavailable request handler, and when allocating the pending request, no longer allocate to the second terminal. At this time, the first terminal only allocates the pending requests to all currently available request processing parties.
And step 108, determining the second terminal as an available request processing party.
And step 110, distributing the request to be processed to all available request processing parties including the second terminal according to a preset distribution strategy.
If the real-time working parameter of the second terminal is within the range of the designated threshold, the second terminal has the capability of efficiently and smoothly processing the to-be-processed request distributed by the first terminal under the working state determined by the real-time working parameter. At this time, the first terminal may determine that the second terminal is an available request processing party, and when allocating the pending request, allocate the pending request to all available request processing parties including the second terminal according to a predetermined allocation policy.
According to the technical scheme, the request initiator can acquire the processing capacity of the request processors in the high-speed asynchronous communication, so that the requests to be processed are distributed among the request processors in a balanced manner based on the processing capacity of each request processor, and the condition that the overall efficiency of the asynchronous communication is influenced because a large number of requests to be processed are distributed to the request processors with insufficient processing capacity is avoided. On the basis of fully utilizing the system resources of each request processing party, the balance of request allocation is improved, and the efficiency of asynchronous communication is improved.
In a possible design, the first terminal obtains the queue length of the to-be-processed request in the second terminal as a real-time working parameter, and the maximum queue length that the second terminal has enough processing capacity to process the to-be-processed request allocated by the first terminal can achieve is 50, and then the specified threshold range corresponding to the queue length of the to-be-processed request in the second terminal is less than 50.
If the queue length of the to-be-processed requests reported by the second terminal is 36, and 36 is smaller than 50, it indicates that the second terminal can continue to receive up to 50 to-be-processed requests, and the second terminal can efficiently complete the processing work on the to-be-processed requests within the range that the queue length of the to-be-processed requests is 50. Thus, it can be determined that the second terminal is an available request handler, and the second terminal can be a valid allocation object in a subsequent request allocation process.
If the queue length of the to-be-processed request reported by the second terminal is 50, it indicates that the processing capacity of the second terminal has reached the upper limit of the processing capacity of the second terminal. At this time, if the pending request is allocated to the second terminal, the pending request cannot be processed by the second terminal effectively in time. Therefore, it can be determined that the second terminal is an unavailable request handler, and the second terminal is not considered as a valid allocation object in a subsequent request allocation process.
In another possible design, the first terminal obtains the CPU occupancy of the second terminal as a real-time operating parameter. The CPU occupancy refers to the proportion of the CPU processing capacity that the second terminal needs to use to process the allocated pending requests, and if the second terminal still wants to have enough capacity to process the newly allocated pending requests, at least 40% of the CPU occupancy should be left for the newly allocated pending requests. In other words, when the second terminal wants to process the newly allocated pending request, the CPU occupancy of the second terminal cannot exceed 60% at the highest. Therefore, the specified threshold range corresponding to the CPU occupancy is less than 60%.
If the CPU occupancy reported by the second terminal is 30% and 30% is less than 60%, it indicates that the second terminal can continue to receive the pending request until the CPU occupancy reaches 60%. Thus, the first terminal may determine that the second terminal is an available request handler, and the second terminal may be a valid allocation object in a subsequent request allocation process.
If the CPU occupancy reported by the second terminal is 70%, and 70% is greater than 60%, it indicates that the second terminal has insufficient system resources for processing the new request to be processed. At this time, if the pending request is allocated to the second terminal, the pending request cannot be processed by the second terminal effectively in time. Therefore, it can be determined that the second terminal is an unavailable request handler, and the second terminal is not considered as a valid allocation object in a subsequent request allocation process.
In another possible design, the first terminal may obtain the queue length and the CPU occupancy of the pending request of the second terminal as real-time working parameters, and only when both are within the range of the designated threshold corresponding to the first terminal, it is determined that the second terminal has sufficient processing capability to process the new pending request. At this time, the first terminal may determine that the second terminal is an available request handler, and the second terminal may be a valid allocation object in a subsequent request allocation process. And if any one of the two is not in the range of the corresponding designated threshold value, determining that the new request to be processed cannot be processed effectively in time by the second terminal. Therefore, it can be determined that the second terminal is an unavailable request handler, and the second terminal is not considered as a valid allocation object in a subsequent request allocation process.
On the basis of the embodiment shown in fig. 1, fig. 2 shows a flow chart of an asynchronous communication method according to another embodiment of the invention.
As shown in fig. 2, an asynchronous communication method according to another embodiment of the present invention, for a second terminal, includes:
step 202, real-time working parameters are obtained.
When the first terminal is used as a request initiator in asynchronous communication, the second terminal is a request processor, and the first terminal needs to judge whether the second terminal is an available request processor. The condition available to the request handler is that there is sufficient processing capacity to handle the pending request assigned by the first terminal, and the sufficient processing capacity is determined by its real-time operating parameters.
Wherein the real-time operating parameters include, but are not limited to, a combination of one or more of: the queue length of the to-be-processed request, the processing time required for processing all the to-be-processed requests, the remaining memory, the CPU occupancy rate, and the working parameters determined based on the CPU occupancy rate and/or the remaining memory, and the real-time working parameters may also be any parameters capable of expressing the processing capability of the terminal on the request.
Step 204, sending the real-time working parameter to a first terminal, so that the first terminal can judge whether the second terminal is an available request processing party based on the real-time working parameter, and the first terminal allocates a request to be processed to the available request processing party.
The technical solution for the first terminal to determine whether the second terminal is an available request processing party is described in detail in the embodiment shown in fig. 1, and is not described herein again.
Step 206, detecting whether the request to be processed allocated by the first terminal is received.
Step 208, adding the pending request to a request processing queue when the pending request is received.
After reporting the real-time operating parameters to the first terminal, the first terminal may determine that the second terminal is an available requesting party or an unavailable requesting party. And under the condition that the first terminal judges that the second terminal is an available request processing party, the second terminal is taken as an effective distribution object, and the request to be processed is distributed to the second terminal. And when the second terminal detects the to-be-processed request distributed by the first terminal, the to-be-processed request can be added into the request processing queue, and each request in the request processing queue is sequentially processed.
The interaction process of the first terminal and the second terminal is further described below by means of fig. 3.
As shown in fig. 3, the asynchronous communication system includes a first terminal and a second terminal, wherein the interaction process of the first terminal and the second terminal in the asynchronous communication process is as follows:
and step 302, the second terminal acquires real-time working parameters.
And step 304, the second terminal sends the real-time working parameters to the first terminal.
In one possible design, the second terminal obtains the real-time operating parameters at predetermined time intervals. In other words, the second terminal detects its own real-time operating parameters and reports them to the first terminal periodically. That is, the first terminal determines the current processing capability of the second terminal once every time the second terminal reports its own real-time operating parameters.
Further, since the asynchronous communication system has a plurality of request processing parties, that is, a plurality of second terminals, each second terminal periodically reports its own real-time operating parameters to the first terminal. And the first terminal judges whether the real-time working parameter belongs to the second terminal once receiving the real-time working parameter, and refreshes an available request processing party list according to the judgment result.
Thus, the list of available requesting handlers is refreshed in real-time based on the first terminal's determination of any real-time work information received. Therefore, whether the request processing parties are available or not can be determined based on the real-time working state of each request processing party to the maximum extent, great convenience is provided for reasonable and balanced distribution of the requests to be processed, and the efficiency of asynchronous communication is improved.
In another possible design, the predetermined time interval may be adjusted based on the actual operating state before or after the second terminal acquires the real-time operating parameter at the predetermined time interval.
Specifically, it may be determined whether a difference between the currently acquired real-time operating parameter and the previously acquired real-time operating parameter is greater than or equal to a first threshold, and whether at least one of the currently acquired real-time operating parameter and the previously acquired real-time operating parameter is greater than or equal to a second threshold. And setting the time interval corresponding to the threshold range to which the difference value belongs as the preset time interval under the condition that the judgment results are yes.
The first threshold is the minimum operating parameter variation value required for the operating capability of the second terminal not to be changed drastically. If the difference between the real-time working parameter obtained this time and the real-time working parameter obtained last time is greater than or equal to the first threshold, it indicates that the variation range of the two real-time working parameters from the preset time interval is large, that is, the working capacity of the second terminal is greatly changed. For example, the CPU occupancy rate obtained this time is 70%, and the real-time operating parameter obtained last time before the predetermined time interval of 2min is 30%, which indicates that a large number of events occupying system resources are suddenly issued in 2min in the second terminal. The first threshold value is set to 35%, and the difference between the two values is 40%, which is greater than the first threshold value by 35%.
If the time interval of 2min is taken as the preset time interval, the real-time working parameter obtained last time is 30%, and the range of the real-time working parameter is less than 60%, the first terminal can use the second terminal as an available request processing direction to distribute the request to be processed. However, since the processing capability of the second terminal has changed drastically within 2min, for example, it is highly likely that the CPU occupancy of the second terminal reaches 61% at the 30 th time in 2 min. And as the preset time interval is not finished yet, the second terminal does not report new real-time working parameters to the first terminal, from 31s in 2min, the first terminal will continue to allocate the request to be processed to the second terminal. At this time, the CPU occupancy of the second terminal reaches 61%, and exceeds the specified parameter range less than 60%, that is, at this time, the second terminal cannot smoothly process the new request to be allocated.
Based on this, when the difference between the real-time operating parameter obtained this time and the real-time operating parameter obtained last time is greater than or equal to the first threshold, the predetermined time interval needs to be shortened, and the speed of detecting and reporting the real-time operating parameter by the second terminal is accelerated.
In addition, in an actual scene, if the difference between the two previous real-time working parameters and the two subsequent real-time working parameters reaches the first threshold, the two previous real-time working parameters and the two subsequent real-time working parameters may be lower. For example, the CPU occupancy rate obtained this time is 50%, the real-time operating parameter obtained last time is 10% before the predetermined time interval is 2min, the first threshold is set to be 35%, the difference between the two is 40%, and is greater than the first threshold by 35%, but both are greater than the specified threshold range less than 60%.
In this regard, a constraint condition may be added, that is, whether at least one of the real-time operating parameters obtained this time and the real-time operating parameters obtained last time is greater than or equal to a second threshold, where the second threshold may be any value close to the limit of the specified threshold range. And once any one of the real-time working parameters acquired this time and the real-time working parameters acquired last time is greater than or equal to a second threshold, indicating that the real-time working parameters are close to or exceed the limit of the specified threshold range.
For example, the second threshold is set to be 55%, the CPU occupancy rate obtained this time is 70%, and the real-time operating parameter obtained last time is 30%. Wherein, the difference value of the two is 40 percent and is larger than the first threshold value by 35 percent. And the CPU occupancy rate acquired this time is 70% greater than the second threshold value 55%. This means that a large number of events occupying system resources are bursty within 2min in the second terminal. In order to ensure the validity of the available request handler list, it is necessary to shorten the predetermined time interval and speed up the detection and reporting of the real-time operating parameters by the second terminal.
In addition, the difference value may be divided into a plurality of threshold value ranges, each threshold value range corresponds to a time interval, the larger the difference value is, the smaller the time interval corresponding to the threshold value range is, the more frequently the second terminal reports the real-time working parameter, and the more frequently the first terminal refreshes the available request handler list based on the real-time working parameter reported by the second terminal. Therefore, when the difference between the real-time working parameter obtained this time and the real-time working parameter obtained last time is greater than or equal to the first threshold, and at least one of the two is greater than or equal to the second threshold, the time interval corresponding to the threshold range to which the difference belongs is set as the preset time interval.
Step 306, the first terminal responds to the acquisition of the real-time working parameter, judges whether the real-time working parameter is within the range of the specified threshold, and enters step 308 when the real-time working parameter is not within the range of the specified threshold, and enters step 310 when the real-time working parameter is within the range of the specified threshold.
In step 308, the first terminal determines the second terminal as an unavailable request handler.
In step 310, the first terminal determines the second terminal as an available request handler.
Based on the above-described real-time refresh of the list of available requesting handlers based on the first terminal's determination of any real-time job information received, the first terminal determines the second terminal as an available requesting handler, which is equivalent to adding the second terminal to the set of available requesting handlers, or, alternatively, refreshing the list of available requesting handlers. Next, the first terminal may allocate the pending request to all available request processing parties including the second terminal according to a predetermined allocation policy. The predetermined allocation policy refers to how the first terminal allocates pending requests to all available request handlers.
In step 312, the first terminal obtains historical operating parameters of other available request processing parties.
And the other available request processing parties are request processing parties except the second terminal in all the available request processing parties.
The real-time working parameters of the second terminal are latest received by the first terminal and can be directly used as a basis for distributing the to-be-processed requests. And the other available request processing parties are determined by the first terminal before the second terminal is determined to be available, that is, for each other available request processing party, the first terminal receives the reported historical operating parameters at least once. Therefore, historical operating parameters of other available request processing parties can be used as a basis for distributing the pending requests.
In one possible design, the historical operating parameters are the latest historical operating parameters of the other available requesting processors. The historical operating parameters are the operating parameters reported last by other available requesting processors, in other words, in the last report, the first terminal determines that the requesting processor is available based on the operating parameters.
Therefore, the working state indicated by the last reported working parameter may be the real-time working state closest to the current time of the request processor because the reporting time is closest to the current time.
In another possible design, the historical operating parameter is an average of all or a portion of the historical operating parameters of the other available requesting processors. In an actual scenario, the request processing party may encounter a situation where the operating state has a large variation range. In order to avoid that the difference between the last reported working parameter of the request processing party and the real-time working parameter of the request processing party is too large to influence the distribution rationality of the request to be processed under the condition, the average value of all or part of historical working parameters of the request processing party can be used as the historical working parameter.
In step 314, the first terminal determines the weight of each available request handler according to the historical operating parameters of the other available request handlers and the real-time operating parameters of the second terminal.
The stronger the processing power embodied by the real-time operating parameters, the greater the weight of the requesting processor that is available. For example, if the queue length of the pending request of the available request handler a is 40 and the queue length of the pending request of the available request handler b is 51, among the plurality of available request handlers including the second terminal, a may continue to receive more pending requests than b can receive, and a has a processing capability higher than b. Accordingly, the weight of a is greater than b.
In addition, the conversion manner between the real-time operating parameters of the requesting processor and the weight of the requesting processor can be any manner that meets the actual requirement, such as setting the weight of the requesting processor equal to the product of the real-time operating parameters of the requesting processor and the designated conversion coefficient.
In step 316, the first terminal obtains all available historical operating parameters of the request processing party.
And 318, the first terminal determines the weight of each available request processing party according to the historical operating parameters of all the available request processing parties.
Similarly, if the second terminal is not an available request processing party, the first terminal only obtains the historical operating parameters and calculates the weight of all the currently available request processing parties.
And step 320, the first terminal determines the allocation target of the to-be-processed request among all the available request processing parties based on the weight of each available request processing party, or the first terminal determines the allocation target of the to-be-processed request among all the available request processing parties based on the weight of each available request processing party and the priority of the to-be-processed request.
In one possible design, the highest weighted requesting processor has the highest processing capability, so pending requests may be preferentially assigned to the highest weighted requesting processor. And after distributing the appointed number of the requests to be processed to the request processing party with the highest weight, the first terminal can detect whether a new real-time working parameter is received, and if the new real-time working parameter is received, the step of judging the real-time working parameter is returned so as to refresh the list of the available request processing parties. Then, the weights of all available request handlers are recalculated, so that the specified number of pending requests continues to be assigned to the request handler with the highest weight at that time.
In another possible design, the pending requests with the priority reaching the designated level may be allocated to the requesting processor with the highest weight, or the pending requests with the priority reaching the designated level may be allocated to the requesting processor with the designated number of bits before the weight ranking, randomly or according to a designated allocation rule. Therefore, the pending requests with high priority can be processed by the request processing party with stronger processing capability preferentially, and the practicability of asynchronous communication is improved.
It should be understood that any terminal in the asynchronous communication system can be used as a request initiator and also can be used as a request processor. For any first terminal as a request initiator, the plurality of request handlers report their own real-time operating parameters to the first terminal in the manner described in the above embodiment, so that the first terminal refreshes an available request initiator list once every time it receives a real-time operating parameter.
Meanwhile, in the same asynchronous communication system, a plurality of request initiators may be provided, and the request processing parties corresponding to each request initiator may be completely different or have an intersection. For any second terminal, when it is used as a request processing party of multiple request initiators, it needs to report its own real-time operating parameters to each request initiator according to a predetermined time interval set by each request initiator. Of course, any terminal in the asynchronous communication system may serve as a request initiator to receive the real-time work information reported by its own request handler, and also serve as a request handler of other request initiators to report its own real-time work information to other request initiators.
Figure 4 shows a block diagram of an asynchronous communication device according to one embodiment of the invention.
As shown in fig. 4, an asynchronous communication apparatus 400 according to an embodiment of the present invention is used for a first terminal that asynchronously communicates with a plurality of available request processing parties when the first terminal is used as a request initiator, and the asynchronous communication apparatus 400 includes: a parameter obtaining unit 402, configured to obtain real-time operating parameters from the second terminal; a parameter determining unit 404, configured to determine, in response to the acquisition of the real-time working parameter, whether the real-time working parameter is within a specified threshold range; a first processing unit 406, configured to determine, when the real-time operating parameter is not within the specified threshold range, the second terminal as an unavailable requesting processor; a second processing unit 408, configured to determine the second terminal as an available request handler when the real-time operating parameter is within the specified threshold range; a request allocating unit 410, configured to allocate the pending requests to all available request processing parties including the second terminal according to a predetermined allocation policy.
In an embodiment of the present application, optionally, the real-time operating parameter includes one or more of the following: the method comprises the steps of queue length of the requests to be processed, processing time required for processing all the requests to be processed, residual memory, CPU occupancy rate and working parameters determined based on the CPU occupancy rate and/or the residual memory.
In an embodiment of the present application, optionally, the request allocating unit 410 is configured to: acquiring historical operating parameters of other available request processing parties, wherein the other available request processing parties are request processing parties except the second terminal in all the available request processing parties, and the historical operating parameters are latest historical operating parameters of the other available request processing parties or average values of all or part of the historical operating parameters of the other available request processing parties; determining the weight of each available request processing party according to the historical working parameters of the other available request processing parties and the real-time working parameters of the second terminal; and determining the distribution target of the to-be-processed request in all the available request processing parties based on the weight of each available request processing party, or determining the distribution target of the to-be-processed request in all the available request processing parties based on the weight of each available request processing party and the priority of the to-be-processed request.
The asynchronous communication device 400 uses the scheme described in any one of the embodiments shown in fig. 1 to fig. 3, and therefore, all the technical effects described above are achieved, and are not described herein again.
Fig. 5 shows a block diagram of an asynchronous communication device according to another embodiment of the invention.
As shown in fig. 5, an asynchronous communication apparatus 500 according to another embodiment of the present invention is used for a second terminal, and when a first terminal is a request initiator in asynchronous communication, the second terminal is a request handler, and the asynchronous communication apparatus 500 includes: a parameter obtaining unit 502, configured to obtain real-time working parameters; a parameter sending unit 504, configured to send the real-time operating parameter to a first terminal, so that the first terminal determines, based on the real-time operating parameter, whether the second terminal is an available request handler, and the first terminal allocates a request to be processed to the available request handler; a request detecting unit 506, configured to detect whether the to-be-processed request allocated by the first terminal is received; a request processing unit 508, configured to, when receiving the pending request, add the pending request to a request processing queue.
In an embodiment of the present application, optionally, the real-time operating parameter includes one or more of the following: the method comprises the steps of queue length of the requests to be processed, processing time required for processing all the requests to be processed, residual memory, CPU occupancy rate and working parameters determined based on the CPU occupancy rate and/or the residual memory.
In an embodiment of the present application, optionally, the parameter obtaining unit 502 is configured to: acquiring the real-time working parameters at preset time intervals; the asynchronous communication device 500 further comprises: a judging unit, configured to judge whether a difference between the currently-acquired real-time operating parameter and a previously-acquired real-time operating parameter is greater than or equal to a first threshold, and judge whether at least one of the currently-acquired real-time operating parameter and the previously-acquired real-time operating parameter is greater than or equal to a second threshold; and the execution unit is used for setting the time interval corresponding to the threshold range to which the difference value belongs as the preset time interval under the condition that the judgment results are yes.
The asynchronous communication device 500 uses the scheme described in any one of the embodiments shown in fig. 1 to fig. 3, and therefore, all the technical effects described above are achieved, and are not described herein again.
Fig. 6 shows a block diagram of a terminal according to an embodiment of the invention.
As shown in fig. 6, a terminal 600 of one embodiment of the present invention includes at least one memory 602; and a processor 604 communicatively coupled to the at least one memory 602; wherein the memory stores instructions executable by the at least one processor 604 and configured to perform the aspects of any of the embodiments of fig. 1-3 described above. Therefore, the terminal 600 has the same technical effect as any one of the embodiments of fig. 1 to 3, and is not described herein again.
The electronic device of embodiments of the present invention exists in a variety of forms, including but not limited to:
(1) mobile communication devices, which are characterized by mobile communication capabilities and are primarily targeted at providing voice and data communications. Such terminals include smart phones (e.g., iphones), multimedia phones, functional phones, and low-end phones, among others.
(2) The ultra-mobile personal computer equipment belongs to the category of personal computers, has calculation and processing functions and generally has the characteristic of mobile internet access. Such terminals include PDA, MID, and UMPC devices, such as ipads.
(3) Portable entertainment devices such devices may display and play multimedia content. Such devices include audio and video players (e.g., ipods), handheld game consoles, electronic books, as well as smart toys and portable car navigation devices.
(4) The server is similar to a general computer architecture, but has higher requirements on processing capability, stability, reliability, safety, expandability, manageability and the like because of the need of providing highly reliable services.
(5) And other electronic devices with data interaction functions.
In addition, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for performing the method flow described in any one of the above embodiments of fig. 1 to 3.
The technical solutions of the present invention are described in detail above with reference to the drawings, and through the technical solutions of the present invention, pending requests can be distributed among request processing parties in a balanced manner based on the processing capabilities of the request processing parties, and the occurrence of a situation that the processing-capability-deficient request processing parties are distributed with a large number of pending requests to affect the overall efficiency of asynchronous communication is avoided. On the basis of fully utilizing the system resources of each request processing party, the balance of request allocation is improved, and the efficiency of asynchronous communication is improved.
It should be understood that the term "and/or" as used herein is merely one type of association that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.
It should be understood that although the terms first, second, etc. may be used to describe terminals in embodiments of the present invention, these terminals should not be limited by these terms. These terms are only used to distinguish one terminal from another. For example, a first terminal may also be referred to as a second terminal, and similarly, a second terminal may also be referred to as a first terminal, without departing from the scope of embodiments of the present invention.
The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrases "if determined" or "if detected (a stated condition or event)" may be interpreted as "when determined" or "in response to a determination" or "when detected (a stated condition or event)" or "in response to a detection (a stated condition or event)", depending on the context.
In the embodiments provided in the present invention, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions in actual implementation, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.
The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a Processor (Processor) to execute some steps of the methods according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (10)

1. An asynchronous communication method for a first terminal, wherein the first terminal, when acting as a request originator, performs asynchronous communication with a plurality of available request handlers, the method comprising:
acquiring real-time working parameters from the second terminal;
responding to the acquisition of the real-time working parameters, and judging whether the real-time working parameters are within a specified threshold range;
when the real-time working parameters are not within the specified threshold range, determining the second terminal as an unavailable request processing party;
when the real-time working parameters are within the specified threshold value range, determining the second terminal as an available request processing party; then
And distributing the pending requests to all available request processing parties including the second terminal according to a preset distribution strategy.
2. The asynchronous communication method according to claim 1,
the real-time operating parameters include one or more of the following in combination:
the method comprises the steps of queue length of the requests to be processed, processing time required for processing all the requests to be processed, residual memory, CPU occupancy rate and working parameters determined based on the CPU occupancy rate and/or the residual memory.
3. The asynchronous communication method according to claim 1, wherein the step of allocating the pending requests to all available request handlers including the second terminal according to a predetermined allocation policy comprises:
historical operating parameters of other available requesting processors are obtained, wherein,
the other available request handlers are request handlers other than the second terminal among the all available request handlers,
the historical working parameters are the latest historical working parameters of other available request processing parties or the average value of all or part of the historical working parameters of other available request processing parties;
determining the weight of each available request processing party according to the historical working parameters of the other available request processing parties and the real-time working parameters of the second terminal;
determining an allocation target of the pending request among all the available request handlers based on a weight of each of the available request handlers, or
Determining an allocation target of the pending request among all the available request handlers based on a weight of each of the available request handlers and a priority of the pending request.
4. An asynchronous communication method used for a second terminal, wherein when a first terminal is used as a request initiator in asynchronous communication, the second terminal is a request processor, the method comprises:
acquiring real-time working parameters;
sending the real-time working parameters to a first terminal so that the first terminal can judge whether the second terminal is an available request processing party or not based on the real-time working parameters, and the first terminal distributes a request to be processed to the available request processing party;
detecting whether the request to be processed distributed by the first terminal is received;
and adding the request to be processed into a request processing queue when the request to be processed is received.
5. The asynchronous communication method of claim 4, wherein said step of obtaining real-time operating parameters comprises:
acquiring the real-time working parameters at preset time intervals;
the method further comprises:
judging whether the difference value between the real-time working parameter obtained this time and the real-time working parameter obtained last time is larger than or equal to a first threshold value or not, and judging whether at least one of the real-time working parameter obtained this time and the real-time working parameter obtained last time is larger than or equal to a second threshold value or not;
and setting the time interval corresponding to the threshold range to which the difference value belongs as the preset time interval under the condition that the judgment results are yes.
6. An asynchronous communication apparatus for a first terminal, wherein the first terminal, when acting as a request originator, asynchronously communicates with a plurality of available request handlers, the apparatus comprising:
the parameter acquisition unit is used for acquiring real-time working parameters from the second terminal;
the parameter judgment unit is used for responding to the acquisition of the real-time working parameters and judging whether the real-time working parameters are within a specified threshold range;
the first processing unit is used for determining the second terminal as an unavailable request processing party when the real-time working parameters are not in the specified threshold range;
the second processing unit is used for determining the second terminal as an available request processing party when the real-time working parameters are within the specified threshold range;
and the request distribution unit is used for distributing the requests to be processed to all available request processing parties including the second terminal according to a preset distribution strategy.
7. An asynchronous communication apparatus for a second terminal, wherein the second terminal is a request handler when a first terminal is a request initiator in asynchronous communication, the apparatus comprising:
the parameter acquisition unit is used for acquiring real-time working parameters;
a parameter sending unit, configured to send the real-time operating parameter to a first terminal, so that the first terminal determines, based on the real-time operating parameter, whether the second terminal is an available request handler, and the first terminal allocates a request to be processed to the available request handler;
a request detection unit, configured to detect whether the to-be-processed request allocated by the first terminal is received;
and the request processing unit is used for adding the request to be processed into a request processing queue when the request to be processed is received.
8. An asynchronous communication system comprising a first terminal and a second terminal, wherein when the first terminal is used as a request initiator and the second terminal is used as a request processor, the first terminal performs asynchronous communication with a plurality of available request processors,
the second terminal acquires real-time working parameters;
the second terminal sends the real-time working parameters to the first terminal;
the first terminal responds to the acquisition of the real-time working parameters and judges whether the real-time working parameters are within a specified threshold range;
when the real-time working parameters are not in the specified threshold range, the first terminal determines the second terminal as an unavailable request processing party;
the first terminal determines the second terminal as an available request processing party when the real-time working parameters are within the specified threshold range; and
and the first terminal distributes the requests to be processed to all available request processing parties including the second terminal according to a preset distribution strategy.
9. A terminal, comprising: at least one processor; and a memory communicatively coupled to the at least one processor;
wherein the memory stores instructions executable by the at least one processor, the instructions being arranged to perform the method of any of the preceding claims 1 to 5.
10. A computer-readable storage medium having stored thereon computer-executable instructions for performing the method flow of any of claims 1-5.
CN202010237333.1A 2020-03-30 2020-03-30 Asynchronous communication method, device, system, terminal and computer readable storage medium Pending CN111432012A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010237333.1A CN111432012A (en) 2020-03-30 2020-03-30 Asynchronous communication method, device, system, terminal and computer readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010237333.1A CN111432012A (en) 2020-03-30 2020-03-30 Asynchronous communication method, device, system, terminal and computer readable storage medium

Publications (1)

Publication Number Publication Date
CN111432012A true CN111432012A (en) 2020-07-17

Family

ID=71549922

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010237333.1A Pending CN111432012A (en) 2020-03-30 2020-03-30 Asynchronous communication method, device, system, terminal and computer readable storage medium

Country Status (1)

Country Link
CN (1) CN111432012A (en)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1760914A (en) * 2005-11-01 2006-04-19 中国地质调查局发展研究中心 Network gridding service system of national geolopy spatial data
CN103873293A (en) * 2014-03-05 2014-06-18 杭州华三通信技术有限公司 Health detection device and method
CN105607724A (en) * 2015-12-22 2016-05-25 深圳市金立通信设备有限公司 Terminal control method and terminal
CN106330987A (en) * 2015-06-15 2017-01-11 交通银行股份有限公司 Dynamic load balancing method
CN106535253A (en) * 2016-11-23 2017-03-22 北京必创科技股份有限公司 Method for dynamic acquisition and transmission of wireless data
CN107124472A (en) * 2017-06-26 2017-09-01 杭州迪普科技股份有限公司 Load-balancing method and device, computer-readable recording medium
CN108664116A (en) * 2018-04-27 2018-10-16 北京邮电大学 Adaptive electricity saving method, device and the cpu controller of network function virtualization
CN109408227A (en) * 2018-09-19 2019-03-01 平安科技(深圳)有限公司 Load-balancing method, device and storage medium
CN109960565A (en) * 2017-12-25 2019-07-02 航天信息股份有限公司 Cloud platform, dispatching method of virtual machine and device based on cloud platform
CN110764912A (en) * 2019-10-25 2020-02-07 东北大学 Self-adaptive task scheduler and method

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1760914A (en) * 2005-11-01 2006-04-19 中国地质调查局发展研究中心 Network gridding service system of national geolopy spatial data
CN103873293A (en) * 2014-03-05 2014-06-18 杭州华三通信技术有限公司 Health detection device and method
CN106330987A (en) * 2015-06-15 2017-01-11 交通银行股份有限公司 Dynamic load balancing method
CN105607724A (en) * 2015-12-22 2016-05-25 深圳市金立通信设备有限公司 Terminal control method and terminal
CN106535253A (en) * 2016-11-23 2017-03-22 北京必创科技股份有限公司 Method for dynamic acquisition and transmission of wireless data
CN107124472A (en) * 2017-06-26 2017-09-01 杭州迪普科技股份有限公司 Load-balancing method and device, computer-readable recording medium
CN109960565A (en) * 2017-12-25 2019-07-02 航天信息股份有限公司 Cloud platform, dispatching method of virtual machine and device based on cloud platform
CN108664116A (en) * 2018-04-27 2018-10-16 北京邮电大学 Adaptive electricity saving method, device and the cpu controller of network function virtualization
CN109408227A (en) * 2018-09-19 2019-03-01 平安科技(深圳)有限公司 Load-balancing method, device and storage medium
CN110764912A (en) * 2019-10-25 2020-02-07 东北大学 Self-adaptive task scheduler and method

Similar Documents

Publication Publication Date Title
CN109246229B (en) Method and device for distributing resource acquisition request
CN110858843B (en) Service request processing method and device and computer readable storage medium
CN104714851B (en) A kind of method and device for realizing resource allocation
CN107819797B (en) Access request processing method and device
CN111030945B (en) Disaster recovery method, disaster recovery gateway, storage medium, device and system
CN104980472A (en) Network traffic control method and device
CN110933136A (en) Service node selection method, device, equipment and readable storage medium
CN113595926B (en) API data transmission method, device, equipment and medium based on data middlebox
CN114155026A (en) Resource allocation method, device, server and storage medium
CN110007867B (en) Cache space allocation method, device, equipment and storage medium
CN111538572A (en) Task processing method, device, scheduling server and medium
CN112596985B (en) IT asset detection method, device, equipment and medium
CN115586957B (en) Task scheduling system, method and device and electronic equipment
CN111432012A (en) Asynchronous communication method, device, system, terminal and computer readable storage medium
CN117032977A (en) Mixed part application resource allocation method and device, computer equipment and storage medium
CN111737000A (en) Method for realizing load balance
CN111857996B (en) Interrupt processing method, system, equipment and computer readable storage medium
CN106550342A (en) The overload controlling method and device of charging request message
CN114827281B (en) Method, system and device for sending and receiving network request
CN113291939B (en) Elevator dispatching method, device, electronic equipment and storage medium
CN117640541B (en) Cloud server resource allocation method, device, equipment and medium
CN113282419B (en) Resource scheduling method, electronic device, and computer-readable storage medium
CN115442432B (en) Control method, device, equipment and storage medium
CN116954853A (en) Interrupt processing method and device, electronic equipment and storage medium
CN115145725A (en) Cloud equipment distribution method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200717