Load balancing method, system, device, medium and program product

Abstract

The invention discloses a load balancing method, system and device, a medium and a program product, and belongs to the technical field of computers. The method comprises the following steps: after N messages delivered by a producer are received, iteratively updating a load balancing decision of each message by collecting a message accumulation amount and a host index value of a consumer in real time, and determining the load balancing decision of the N messages when iterative updating is stopped as a target load balancing decision of the N messages, and delivering the N messages to each consumer according to the target load balancing decision of the N messages. According to the invention, accurate matching between message distribution and actual processing capability of consumers is realized, the problem of resource mismatching caused by static distribution and neglect of processing capability difference of the consumers in the prior art is solved, the message accumulation risk is remarkably reduced, the overall resource utilization rate and consumption throughput of the consumers are improved, and the user experience is improved. The adaptive capacity and the overall stability of the system in a dynamic capacity expansion and contraction scene are enhanced, and finally the high performance and the reliability of the distributed message system are guaranteed.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a load balancing method, system, device, medium, and program product. Background Technology

[0002] Message queues, as core components of asynchronous communication in distributed systems, ensure system stability through decoupling service calls and peak-shaving mechanisms. Apache RocketMQ, with its lightweight architecture and high availability, has become a standard solution in the Internet, IoT, and other fields. Its consumer load balancing mechanism significantly improves consumption throughput by having multiple instances within a group process message queues in parallel.

[0003] Existing load balancing decisions (such as average allocation, ring averaging, and consistent hashing) are all based on static queue partitioning principles, coordinating queue allocation relationships among consumer instances through scheduled tasks. However, existing wired load balancing decisions only consider the number of message queues while ignoring the differences in actual consumer processing capabilities. This leads to resource mismatches among consumer instances with heterogeneous hardware configurations or complex business logic—high-configuration instances have idle processing capabilities, while low-configuration instances experience message backlog due to overload. This imbalance is particularly pronounced in dynamic scaling scenarios, directly causing performance degradation issues such as increased consumption latency and decreased overall system throughput. Summary of the Invention

[0004] The purpose of this application is to provide a load balancing method, system, device, medium, and program product that can solve the problems of uneven load, resource mismatch, and performance degradation caused by ignoring differences in consumer processing capabilities in existing load balancing decisions.

[0005] In a first aspect, embodiments of this application provide a load balancing method applied to a server, comprising: Receive N messages from the producer, where N is a positive integer; Collect message backlog and host metric values ​​for I consumers, where I is a positive integer; Based at least on the message backlog and the host metric value, for each message, iteratively update the load balancing decision for that message and the load balancing decisions for other messages; If the load balancing decisions for all messages cannot be changed, stop the iterative update and determine the load balancing decisions for the N messages at the time the iterative update stops as the target load balancing decisions for the N messages. Based on the target load balancing decision of the N messages, the N messages are delivered to the I consumers.

[0006] In some embodiments, the iterative update of the load balancing decision for the message and the load balancing decisions for other messages includes: Initialize the load balancing decision for the N messages; For the first message, the revenue of the first message is calculated based at least on the load balancing decision of the first message and the load balancing decisions of other messages corresponding to the first message, as well as the message backlog and the host metric value. While keeping the load balancing decisions of other messages corresponding to the first message unchanged, iteratively update the load balancing decision of the first message until the benefit of the first message reaches its maximum, and obtain the optimal load balancing decision of the first message, which will be used as the load balancing decision of the first message in subsequent iterative update processes. For the second message, the benefit of the second message is calculated based at least on the load balancing decision of the second message and the load balancing decisions of other messages corresponding to the second message, as well as the message backlog and the host metric value. While keeping the load balancing decisions of other messages corresponding to the second message unchanged, iteratively update the load balancing decision of the second message until the benefit of the second message reaches its maximum, and obtain the optimal load balancing decision of the second message, which will be used as the load balancing decision of the second message in subsequent iterative update processes. Repeat the above process until the optimal load balancing decision for the nth message is obtained, then stop iterative updates, where 1≤n≤N.

[0007] In some embodiments, the host metrics include at least CPU frequency, CPU utilization, free memory, and memory utilization; The benefit of the nth message includes at least the first benefit; The process for determining the first benefit of the nth message includes: The first benefit of the nth message is calculated according to the following formula:

[0008] in, This represents the load balancing decision for the nth message, where 1 ≤ i ≤ I. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the nth message is: the nth message is not delivered to the i-th consumer. A value of 1 indicates that the load balancing decision for the nth message is: the nth message is delivered to the i-th consumer. Indicates the CPU frequency of the i-th consumer. This represents the CPU utilization rate of the i-th consumer. This represents the free memory of the i-th consumer. This represents the memory usage rate of the i-th consumer.

[0009] In some embodiments, the benefit of the nth message may include at least a second benefit; The calculation process for the second benefit of the nth message includes: For the nth message, based on the load balancing decision of the other messages corresponding to the nth message for the i-th consumer, calculate the aggregation impact of the other messages corresponding to the nth message on the i-th consumer; The first sub-benefit of the nth message to the i-th consumer is calculated based at least on the aggregated impact of other messages corresponding to the nth message on the i-th consumer and the message backlog of the i-th consumer; The second sub-benefit of the nth message to the i-th consumer is calculated based at least on the first sub-benefit of the nth message to the i-th consumer and the load balancing decision of the nth message to the i-th consumer; The second benefit of the nth message is obtained based at least on the second sub-benefit of the nth message for each consumer.

[0010] In some embodiments, it also includes: Collect the message priority of the nth message; The step of obtaining the second benefit of the nth message based at least on the second sub-benefit for each consumer according to the nth message includes: The second benefit of the nth message is calculated based on the second benefit of the nth message and the message priority of the nth message.

[0011] In some embodiments, the process of determining the benefit of the nth message includes:

[0012] Where 1≤i≤I, 1≤o≤N, This represents the benefit of the nth message. The first preset parameter, This is the second preset parameter. This indicates the message priority of the nth message. This represents the load balancing decision for the 0th message. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the 0th message is: the nth message is not delivered to the 1st consumer. A value of 1 indicates that the load balancing decision for the 0th message is: the nth message is delivered to the 1st consumer. This represents the message backlog for the i-th consumer.

[0013] Secondly, embodiments of this application provide a load balancing system, including: The producer side is used to deliver N messages; On the server side, it is used to execute any of the load balancing methods described in the first aspect and generate a load balancing decision matrix. On the consumer side, the system delivers the N messages to the I consumers based on the load balancing decision matrix.

[0014] Thirdly, embodiments of this application provide an electronic device, including: processor; Memory for storing processor-executable instructions; The processor is configured to execute the instructions to implement any of the load balancing methods described in the first aspect.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium that, when instructions in the computer-readable storage medium are executed by a terminal's processor, enables the terminal to perform any of the load balancing methods described in the first aspect.

[0016] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the load balancing methods described in the first aspect.

[0017] In this embodiment, after receiving N messages from the producer, the load balancing decision for each message is iteratively updated by collecting the message backlog and host metrics of the consumers in real time. The load balancing decision for the N messages at the point where iterative updates stop is determined as the target load balancing decision for the N messages, and the N messages are delivered to each consumer according to the target load balancing decision. Iteratively updating the load balancing decision for each message based on the consumer's message backlog and host metrics achieves precise matching between message allocation and the consumer's actual processing capacity. This ensures that consumers with high processing capacity receive more message allocations due to their processing power advantage, thereby improving resource utilization, while consumers with low processing capacity receive fewer message allocations to avoid overload and backlog. This solves the resource mismatch problem caused by static allocation and neglect of differences in consumer processing capacity in existing technologies, significantly reducing the risk of message backlog. By continuously sensing the consumer load status (message backlog) and resource capacity (host metrics) and dynamically optimizing allocation, the overall resource utilization and consumption throughput of consumers are improved, enhancing the system's adaptability and overall stability in dynamic scaling scenarios, ultimately ensuring the high performance and reliability of the distributed messaging system. Attached Figure Description

[0018] Figure 1 An example diagram of an existing load averaging strategy provided in an embodiment of this application is shown; Figure 2 An example diagram of an existing ring-shaped average allocation strategy provided in an embodiment of this application is shown; Figure 3 An example diagram of an existing consistent hashing strategy provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating the steps of a load balancing method provided in an embodiment of this application is shown. Figure 5 A flowchart illustrating the iterative update of load balancing decisions provided in an embodiment of this application is shown. Figure 6 An example flowchart of a load balancing method provided in an embodiment of this application is shown; Figure 7 A schematic diagram of the structure of a load balancing system provided in an embodiment of this application is shown; Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0021] The load balancing method, system, device, medium, and program products provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0022] The following are explanations of some terms: Message middleware refers to an intermediary layer that supports and ensures the sending and receiving of message data between distributed applications. It can provide applications with capabilities such as business decoupling and increasing system throughput. Since its inception, RocketMQ has been widely adopted by many enterprise developers and cloud vendors due to its simple architecture, rich business functions, and strong scalability. It is widely used in business scenarios in fields such as the Internet, big data, mobile Internet, and the Internet of Things.

[0023] The basic working principle of message middleware is as follows: producers produce data and send it to the server for storage on a specified topic; consumers pull data from the server to the specified topic for consumption. Message middleware can decouple system applications, limit traffic and smooth peak loads, and increase system throughput. RocketMQ, as a message middleware, only uses a first-in, first-out queue for production and consumption. Its default consumer group only considers load balancing decisions based on the number of consumers and their geographical location, without considering the message processing capacity of each consumer. This can easily lead to consumer backlog and negatively impact middleware performance.

[0024] With the rapid development of technologies such as the Internet, big data, and the Internet of Things, distributed systems have become the core architecture supporting high-concurrency, large-scale data processing. Message middleware, as a key component in distributed systems for achieving asynchronous communication, decoupling service dependencies, and peak shaving, directly impacts the stability and throughput of the entire system. Among numerous message middleware options, Apache RocketMQ (Rocket Message Queue) stands out due to its simple architecture, rich functionality (such as transactional messages, ordered messages, and delayed messages), high throughput, and strong scalability. It is widely used in e-commerce transactions, financial payments, log collection, and device monitoring, becoming one of the core infrastructures of enterprise-level distributed systems.

[0025] In distributed message consumption scenarios, a consumer group typically consists of multiple consumer instances that collectively consume message queues under the same topic. How to fairly and efficiently distribute message queues among these consumer instances to achieve load balancing is a core issue in ensuring the efficiency of parallel message processing and avoiding single-node overload or resource waste. If the load balancing decision is unreasonable, some consumer instances may experience slow processing due to being allocated too many messages, leading to message backlog; while other instances may have idle resources due to insufficient messages, ultimately reducing overall consumption efficiency and even causing system performance bottlenecks.

[0026] The existing RocketMQ consumer load balancing mechanism is triggered by a scheduled task. Its core is to coordinate the allocation of message queues among multiple instances within a consumer group through built-in load balancing decisions, ensuring that messages are processed in parallel to improve consumption efficiency. The existing built-in load balancing decisions mainly include the following three categories: (1) Average load strategy. Figure 1 An example diagram of an existing load averaging strategy provided in an embodiment of this application is shown. (Refer to...) Figure 1 This strategy distributes all message queues evenly among consumer instances in sequence. For example, if a topic has 4 queues and there are 2 instances in a consumer group, then each instance is allocated 2 queues. If the number of queues is not divisible by the number of consumers, the remaining queues will be distributed to the first few instances in sequence (e.g., if 5 queues are allocated to 2 instances, the first instance will be allocated 3 queues, and the remaining instance will be allocated 2 queues).

[0027] (2) Ring average distribution strategy. Figure 2 An example diagram of a conventional ring-shaped average allocation strategy provided in an embodiment of this application is shown. (Refer to...) Figure 2 This strategy treats message queues as a ring structure, allocating them to consumer instances at fixed intervals. For example, if four queues are allocated to two instances, instance 1 is assigned queues 0 and 2, instance 2 is assigned queues 1 and 3, and so on. The essence of this ring-based average allocation strategy is still a mechanical division based on the number of queues, without considering dynamic changes in consumers.

[0028] (3) Consistent hashing strategy. Figure 3 An example diagram of an existing consistent hashing strategy provided in an embodiment of this application is shown. (Refer to...) Figure 3 This strategy calculates the hash value of the consumer ID, maps the result to a hash ring (e.g., using a TreeMap to store the hash value), maps the hash value of the message queue to the ring, and selects the nearest consumer in a clockwise direction as the allocation target. This strategy can reduce the queue reallocation overhead when adding or removing consumer instances, but the stability of the hash mapping depends on the uniformity of the hash distribution between the queue and consumers.

[0029] In summary, although existing built-in load balancing decisions implement basic queue allocation functionality, their core design relies solely on the number of message queues for allocation, completely ignoring the actual message processing capabilities of consumer instances. This presents the following technical problems: (1) The unevenness of consumers’ processing capacity was not taken into account.

[0030] In practical applications, different consumer instances may exhibit significant differences in processing capabilities due to factors such as hardware configuration (CPU / memory), network bandwidth, local cache status, or business logic complexity (e.g., message parsing time, downstream call latency). For example, a consumer deployed on a high-spec server might be able to process 1000 messages per second, while a low-spec instance might only be able to process 200. Existing strategies (such as an average allocation strategy) would distribute the same number of queues to both, resulting in idle resources on the high-spec instance and queue backlog on the low-spec instance, ultimately lowering overall consumption efficiency.

[0031] (2) It can easily lead to consumer accumulation and performance degradation.

[0032] When some consumers experience message processing delays due to insufficient processing capacity, their assigned queues will continuously accumulate unconsumed messages. Because the existing strategy lacks a dynamic adjustment mechanism (such as reallocating queues based on real-time consumption rates), the backlog will accumulate over time, further exacerbating consumer load and creating a vicious cycle where "slow nodes drag down the entire system." Simultaneously, the accumulated messages will consume broker memory and disk resources, potentially leading to broker performance degradation or even crashes, threatening the stability of the entire messaging system.

[0033] (3) Difficult to adapt to dynamically changing consumption scenarios.

[0034] In distributed systems, consumer instances may dynamically join or leave consumer groups due to scaling up, scaling down, or restarting from failures. While existing load balancing decisions can trigger rebalancing through scheduled tasks, they do not take into account the real-time processing capabilities of consumers. As a result, after rebalancing, there may still be an imbalance in allocation, with "stronger consumers receiving fewer resources and weaker consumers receiving more," which fails to effectively utilize system resources.

[0035] Therefore, existing load balancing decisions, by ignoring differences in consumer processing capabilities, struggle to meet the demands of efficient message consumption in high-concurrency, heterogeneous environments, easily leading to message backlog and system performance bottlenecks. Thus, there is an urgent need for a load balancing method that can sense consumer processing capabilities and dynamically optimize queue allocation to improve RocketMQ's consumption efficiency and system stability.

[0036] Figure 4 A flowchart illustrating the steps of a load balancing method according to an embodiment of this application is shown. (Refer to...) Figure 4 This application provides a load balancing method applied to the server side, including: S100: Receive N messages delivered by the producer, where N is a positive integer.

[0037] Specifically, the server side refers to the core service component in the message middleware responsible for receiving and storing producer messages, managing consumer load balancing, and message delivery. The producer refers to the application or service entity in the distributed system that generates and sends messages to the message middleware (such as RocketMQ), used to encapsulate business data into messages and deliver them to a specified topic on the server side.

[0038] S200: Collect message backlog and host metric values ​​for I consumers, where I is a positive integer.

[0039] Specifically, a consumer refers to an application or service entity that pulls and processes messages from the message middleware. Message backlog refers to the number of unprocessed messages accumulated by a consumer. By quantifying the current load status of each consumer, it reflects the consumer's processing latency or overload. A higher message backlog for a consumer indicates insufficient processing capacity. Host metrics refer to the system resource metrics of the host where the consumer resides, including CPU frequency, CPU utilization, free memory, and memory utilization, used to evaluate the consumer's real-time processing capability. By updating the load balancing decision for each message based on message backlog and host metrics, the load balancing decision dynamically adapts to changes in consumer resources, improving load balancing efficiency.

[0040] S300: At least based on the message backlog and host metric values, for each message, iteratively update the load balancing decision for that message and the load balancing decisions for other messages.

[0041] Specifically, load balancing decision refers to the strategy for assigning messages to specific consumers. This can be defined using a binary matrix structure to form a computable optimization objective. For example, a matrix element of 1 indicates that the message is delivered to the corresponding consumer, while a matrix element of 0 indicates that the message is not delivered to the corresponding consumer. Iteratively updating load balancing decisions refers to optimizing the delivery objective of a single message while keeping other message allocation strategies fixed. For instance, in iteratively updating load balancing decisions, a random round-robin order can be used to adjust the decision for each message sequentially.

[0042] S400. If the load balancing decision for all messages cannot be changed, stop the iterative update and determine the load balancing decision for N messages at the time when the iterative update stops as the target load balancing decision for N messages.

[0043] S500 makes a target load balancing decision based on N messages, delivering N messages to I consumers.

[0044] Specifically, the condition for stopping iterative updates is: the load balancing decision for each message has reached a local optimum, and the load balancing decisions for all messages no longer change. For example, by calculating the benefit of the load balancing decision for each message, when the benefit of the load balancing decision for each message reaches the maximum benefit for that message, it means that the load balancing decisions for all messages cannot be changed. The load balancing decisions for N messages after stopping iterative updates are then determined as the target load balancing decisions for those N messages. Based on the target load balancing decisions for the N messages, the N messages are delivered to I consumers.

[0045] In this embodiment, after receiving N messages from the producer, the load balancing decision for each message is iteratively updated by collecting the message backlog and host metrics of the consumers in real time. The load balancing decision for the N messages at the point where iterative updates stop is determined as the target load balancing decision for the N messages, and the N messages are delivered to each consumer according to the target load balancing decision. Iteratively updating the load balancing decision for each message based on the consumer's message backlog and host metrics achieves precise matching between message allocation and the consumer's actual processing capacity. This ensures that consumers with high processing capacity receive more message allocations due to their processing power advantage, thereby improving resource utilization, while consumers with low processing capacity receive fewer message allocations to avoid overload and backlog. This solves the resource mismatch problem caused by static allocation and neglect of differences in consumer processing capacity in existing technologies, significantly reducing the risk of message backlog. By continuously sensing the consumer load status (message backlog) and resource capacity (host metrics) and dynamically optimizing allocation, the overall resource utilization and throughput of consumers are improved, enhancing the system's adaptability and overall stability in dynamic scaling scenarios, ultimately ensuring the high performance and reliability of the distributed messaging system.

[0046] Figure 5 A flowchart illustrating the iterative update of load balancing decisions according to an embodiment of this application is shown. (Refer to...) Figure 5 In some embodiments, S300, iteratively updating the load balancing decision for the message and the load balancing decision for other messages, includes: S310. Initialize the load balancing decision for N messages.

[0047] Specifically, initializing the load balancing decision for N messages refers to pre-assigning an initial consumer node to each message. This can be achieved through round-robin allocation, heuristic allocation based on historical load, or random allocation; this embodiment does not impose specific limitations. By initializing the load balancing decision for N messages, a deterministic starting point is provided for iteratively updating the load balancing decision for each message, avoiding convergence uncertainty caused by random initialization.

[0048] S320. For the first message, calculate the benefit of the first message based at least on the load balancing decision of the first message and the load balancing decisions of other messages corresponding to the first message, as well as the message backlog and host metric values.

[0049] Specifically, calculating the benefit of the nth message refers to quantifying the impact of the message on the overall system load when it is distributed to different consumers. This can be achieved using a weighted function based on host metrics or a linear combination based on message backlog, to dynamically reflect the real-time processing capabilities of consumers.

[0050] S330. While keeping the load balancing decisions of other messages corresponding to the first message unchanged, iteratively update the load balancing decision of the first message until the benefit of the first message reaches its maximum, and obtain the optimal load balancing decision of the first message, which will be used as the load balancing decision of the first message in subsequent iterative update processes.

[0051] Specifically, keeping the load balancing decisions for other messages unchanged means fixing the distribution status of other messages while optimizing the current message. By iteratively updating the load balancing decision for the first message, we simulate how the revenue of the first message would change if it were delivered to a different consumer.

[0052] During the iterative update of the load balancing decision for the first message, the load balancing decisions for all other messages remain unchanged. By calculating the revenue allocated to each consumer for the first message, the maximum revenue for the first message is determined. The consumer corresponding to the maximum revenue of the first message is then identified as the target consumer, and delivering the first message to the target consumer is considered the optimal load balancing decision for the first message. This optimal load balancing decision for the first message is then updated in the initial load balancing decisions for the N messages, serving as the load balancing decision for the first message in subsequent iterative updates.

[0053] S340. For the second message, calculate the benefit of the second message based at least on the load balancing decision of the second message and the load balancing decisions of other messages corresponding to the second message, as well as the message backlog and host metric values.

[0054] S350. While keeping the load balancing decisions of other messages corresponding to the second message unchanged, iteratively update the load balancing decision of the second message until the benefit of the second message reaches its maximum, and obtain the optimal load balancing decision of the second message, which will be used as the load balancing decision of the second message in subsequent iterative update processes.

[0055] Specifically, after obtaining the optimal load balancing decision for the first message, firstly, based on the optimal load balancing decision for the first message and the load balancing decisions for the third to Nth messages, combined with the message backlog and host metric values ​​for each consumer, the benefit of the second message under the current load balancing is calculated. Next, keeping the optimal load balancing decisions for the first message and the load balancing decisions for the third to Nth messages unchanged, the benefit of delivering the second message to each consumer is calculated. The optimal load balancing decision for the second message is determined based on the consumer with the maximum benefit, and this decision serves as the load balancing decision for the second message in subsequent iterations.

[0056] S360. Repeat the above process until the optimal load balancing decision for the nth message is obtained, then stop iterative updates, 1≤n≤N.

[0057] Specifically, in the iterative process of determining the load balancing decision for the nth message, the optimal load balancing decisions for messages 1 to (n-1)th, and for messages (n+1) to Nth, are first determined. Then, while ensuring that the optimal load balancing decisions for messages 1 to (n-1)th, and for messages (n+1) to Nth, remain unchanged, the revenue from delivering the nth message to each consumer is calculated. By iteratively updating the maximum revenue, the optimal load balancing decision for the nth message is determined. After obtaining the optimal load balancing decisions for N messages, the iterative update stops.

[0058] Figure 6 An example flowchart of a load balancing method provided in an embodiment of this application is shown. (Refer to...) Figure 6 One or more producers jointly produce messages M1, M2, M3, and M4, and send messages M1, M2, M3, and M4 to the server. The server stores each message and waits for the messages to be allocated according to the target load balancing decision.

[0059] Host metrics were collected by deploying node-exporter on consumers 1, 2, and 3 respectively to assess the hardware processing capabilities of each consumer. Message backlog was collected by deploying the mqadmin command-line tool on consumers 1, 2, and 3 to reflect the current load pressure of the consumers. Both host metrics and message backlog were used as the basis for iteratively updating messages M1, M2, M3, and M4.

[0060] Specifically, host metrics include CPU frequency, CPU utilization, free memory, and memory utilization.

[0061] CPU frequency The collection rules are as follows:

[0062] CPU utilization The collection rules are as follows:

[0063] Free memory The collection rules are as follows:

[0064] Memory usage The collection rules are as follows:

[0065] message backlog The collection rules are as follows:

[0066] After the host metrics and message backlog of consumers 1, 2, and 3 are reported to the Prometheus monitoring system, the server pulls the host metrics and message backlog of each consumer and iteratively updates the load balancing decisions for messages M1, M2, M3, and M4.

[0067] During the iterative update of load balancing decisions for messages M1, M2, M3, and M4, an initial consumer is first assigned to each message. For example, the load balancing decision for the initialized message M1 is consumer 1, the load balancing decision for the initialized message M2 is consumer 2, the load balancing decision for the initialized message M3 is consumer 3, and the load balancing decision for the initialized message M4 is consumer 1.

[0068] Next, based on the host metrics and message backlog of each consumer, the benefit of delivering message M1 to consumer 1 is calculated. During the iterative update of message M1, while ensuring that the load balancing decisions for messages M2, M3, and M4 remain unchanged (i.e., the load balancing decision for message M2 is consumer 2, for message M3 it's consumer 3, and for message M4 it's consumer 1), the benefit of delivering message M1 to consumer 2 is calculated. Using the benefit of delivering message M1 to consumer 1 as a benchmark, the benefit of delivering message M1 to consumer 1 is compared with the benefit of delivering message M1 to consumer 2. The benefit of delivering message M1 to consumer 2 is then calculated. If the benefit of delivering message M1 to consumer 1 is less than the benefit of delivering message M1 to consumer 1, the load balancing decisions for messages M2, M3, and M4 remain unchanged. Based on the benefit of delivering message M1 to consumer 1, the benefit of delivering message M1 to consumer 3 is compared with the benefit of delivering message M1 to consumer 1. If the benefit of delivering message M1 to consumer 3 is less than the benefit of delivering message M1 to consumer 1, the benefit of delivering message M1 to consumer 1 is determined as the maximum benefit of message M1, and the optimal load balancing decision for message M1 is consumer 1.

[0069] Then, keeping the optimal load balancing decision for message M1 (i.e., delivering message M1 to consumer 1), and the load balancing decisions for messages M3 and M4 unchanged, calculate the benefits of delivering message M2 to consumer 1, consumer 2, and consumer 3 respectively. If the benefit of delivering message M1 to consumer 2 is the maximum benefit of message M2, then the optimal load balancing decision for message M2 is set to consumer 2.

[0070] Next, keeping the optimal load balancing decisions for messages M1 and M2, as well as the load balancing decision for message M4, unchanged, we calculate the revenue from delivering message M3 to consumers 1, 2, and 3 respectively. If the revenue from delivering message M3 to consumer 2 is the maximum revenue for message M3, then the optimal load balancing decision for message M3 is consumer 2.

[0071] Finally, keeping the optimal load balancing decisions for messages M1, M2, and M3 unchanged, the benefits of delivering message M4 to consumers 1, 2, and 3 are calculated respectively. If the benefit of delivering message M4 to consumer 3 is the maximum benefit for message M4, then the optimal load balancing decision for message M4 is set to consumer 3. Therefore, according to the decision of delivering message M1 to consumer 1, message M2 to consumer 2, message M3 to consumer 2, and message M3 to consumer 3, each message is delivered to its corresponding consumer to achieve load balancing.

[0072] In some embodiments, host metrics include at least CPU frequency, CPU utilization, free memory, and memory utilization.

[0073] The payoff for the nth message includes at least the payoff for the first message.

[0074] The process of determining the first payoff for the nth message includes: The first benefit of the nth message is calculated using the following formula:

[0075] in, This represents the load balancing decision for the nth message, where 1 ≤ i ≤ I. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the nth message is: the nth message is not delivered to the i-th consumer. A value of 1 indicates that the load balancing decision for the nth message is: the nth message is delivered to the i-th consumer. Indicates the CPU frequency of the i-th consumer. This represents the CPU utilization rate of the i-th consumer. This represents the free memory of the i-th consumer. This represents the memory usage rate of the i-th consumer.

[0076] Specifically, CPU frequency refers to the processor's operating clock frequency, used to reflect the consumer's maximum theoretical computing power; CPU utilization refers to the processor's activity level during the sampling period, used to dynamically indicate the current CPU load level; free memory refers to the unallocated physical memory capacity in the system, used to quantify the availability of memory resources; memory utilization rate refers to the proportion of used memory to total memory, used to characterize memory pressure; first benefit refers to the benefit component calculated based on host metric values, configured to be implemented by combining the exponential decay function of CPU frequency and CPU utilization, and the exponential decay function of free memory and memory utilization, used to transform the consumer's resource status into a quantifiable decision-making basis; load balancing decision. This refers to a binary indicator variable for the message distribution strategy, which is configured to be represented by a Boolean value to explicitly indicate the distribution relationship between messages and consumers.

[0077] In this application, by introducing a mechanism for calculating the first benefit, during the iterative process of message load balancing decision-making, for each message, based on the load balancing decisions of other messages corresponding to that message, the first benefit of that message at different consumers is calculated to characterize the resource status of each consumer in processing the message. A higher first benefit indicates more sufficient resources for processing the message. By delivering messages to consumers with sufficient resources, the actual resource status of consumers is fully considered, reducing message backlog caused by insufficient consumer processing capacity, and improving the consumption efficiency and system stability of the message middleware.

[0078] In another embodiment, the process of determining the reward of the nth message includes:

[0079] Where 1≤i≤I, 1≤o≤N, This represents the benefit of the nth message. The first preset parameter, This is the second preset parameter. This indicates the message priority of the nth message. This represents the load balancing decision for the 0th message. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the 0th message is: the nth message is not delivered to the 1st consumer. A value of 1 indicates that the load balancing decision for the 0th message is: the nth message is delivered to the ith consumer. This represents the message backlog for the i-th consumer.

[0080] Specifically, the first and second preset parameters can be coefficients used to adjust the relative importance of the consumer host metrics and the message backlog. These can be fixed values ​​set during system initialization or dynamically adjusted values ​​based on the runtime environment; this application does not impose specific restrictions. The message priority of the nth message refers to the message's importance indicator, which can be implemented using a numeric field set by the producer when delivering the message. A higher priority value indicates a higher delivery priority. The load balancing decision for the 0th message refers to a binary decision variable regarding the delivery status of other messages corresponding to the nth message. This can be represented by a Boolean variable or binary bits to indicate whether the message is delivered to a specific consumer. The message backlog for the i-th consumer refers to the number of messages that the consumer is currently not processing, which can be implemented using real-time statistics obtained from the message middleware monitoring system.

[0081] This application's embodiments dynamically integrate consumer host metrics, message backlog status, message priority, and load balancing decisions for other messages into the revenue function, enabling each message to comprehensively consider multiple factors when selecting a consumer. The introduction of a first and second preset parameter in the revenue function adjusts the weights of the consumer host metrics and message backlog components, preventing a single factor from dominating the decision. The product term of message priority and message backlog ensures that high-priority messages receive higher revenue from consumers with lighter loads. The values ​​of the load balancing decision variables are directly related to the message delivery status, and the load balancing decision is iteratively updated to maximize revenue, making message selection more aligned with actual processing capacity. The cumulative term of the consumer message backlog and other message load balancing decisions dynamically captures the current and expected load status, preventing instantaneous overload caused by multiple messages simultaneously selecting the same consumer. By using a weighted fusion mechanism of multi-dimensional indicators, the load balancing decision can adaptively respond to changes in consumer processing capacity and message characteristics. This effectively solves the problem of neglecting the dynamic processing capacity of consumers and message priority in traditional load balancing, avoids multiple messages from simultaneously selecting the same low-load consumer and causing new consumption backlog, thereby improving the performance and stability of the message middleware, ensuring that high-priority messages can be processed first, and avoiding message blocking.

[0082] In another embodiment, the host metrics include at least CPU frequency, CPU utilization, free memory, and memory utilization.

[0083] The payoff for the nth message includes at least the payoff for the first message.

[0084] The process of determining the first payoff for the nth message includes: The first benefit of the nth message is calculated using the following formula:

[0085] in, This represents the load balancing decision for the nth message, where 1 ≤ i ≤ I. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the nth message is: the nth message is not delivered to the i-th consumer. A value of 1 indicates that the load balancing decision for the nth message is: the nth message is delivered to the i-th consumer. Indicates the CPU frequency of the i-th consumer. This represents the CPU utilization rate of the i-th consumer. This represents the free memory of the i-th consumer. This represents the memory usage rate of the i-th consumer.

[0086] The benefit of the nth message includes at least the second benefit; The calculation process for the second benefit of the nth message includes: For the nth message, based on the load balancing decision of the other messages corresponding to the nth message for the i-th consumer, calculate the aggregation impact of the other messages corresponding to the nth message on the i-th consumer; Based at least on the aggregate impact of other messages corresponding to the nth message on the i-th consumer and the message backlog of the i-th consumer, calculate the first sub-benefit of the nth message on the i-th consumer; Calculate the second sub-revenue of the nth message to the i-th consumer based at least on the first sub-revenue of the nth message to the i-th consumer and the load balancing decision of the nth message to the i-th consumer; The second benefit of the nth message is obtained based on at least the second sub-benefit of the nth message for each consumer.

[0087] Specifically, the second benefit refers to the comprehensive evaluation index of global load balancing for the nth message. For the nth message, it is achieved by accumulating the second sub-benefits of all consumers. The purpose is to integrate the local consumer load status to form a global benefit index, ensuring that the message distribution can adaptively adjust to a Nash equilibrium state. The aggregate impact of other messages corresponding to the nth message on the i-th consumer refers to the cumulative value of the load balancing decisions of other messages corresponding to the nth message. This can be achieved by summing up the results to quantify the current implicit load status of the consumer, enabling the nth message to dynamically perceive whether the consumer has been occupied by other messages. The first sub-benefit refers to the intermediate calculation reflecting the consumer's load pressure. This can be achieved by linearly or non-linearly combining the aggregate impact of other messages corresponding to the nth message on the i-th consumer with the message backlog of the i-th consumer. The purpose is to reduce the benefit value when the consumer's message backlog is high or the implicit load is large, guiding messages to actively avoid high-load consumers. The second sub-benefit specifically refers to the correlation result between the first sub-benefit and the load balancing decision. This is achieved by multiplying the first sub-benefit by the load balancing decision value of the nth message on the i-th consumer, so that the benefit calculation is closely related to the actual delivery decision. When a message is selected to be delivered to a specific consumer, it is directly constrained by the load status of that consumer.

[0088] For example, in the RocketMQ system, when the server receives N messages delivered by the producer, when calculating the second benefit for the nth message, it first calculates the cumulative value of the load balancing decisions of all messages except the nth message for the i-th consumer as the aggregate impact; then, it calculates the first sub-benefit based on the aggregate impact and the current message backlog for the i-th consumer, for example, by using a weighted sum of the aggregate impact and the message backlog; next, it multiplies the first sub-benefit by the load balancing decision value of the nth message for the i-th consumer to obtain the second sub-benefit; finally, it sums the second sub-benefits for all consumers to obtain the second benefit.

[0089] In some embodiments, the process of calculating the second benefit of the nth message further includes: The message priority for collecting the nth message; The second benefit of message n is obtained based on at least the second sub-benefit of message n for each consumer, including: Calculate the second benefit of the nth message based on the second benefit of the nth message and the message priority of the nth message.

[0090] Specifically, message priority refers to the urgency or importance level of a message in business processing. It is implemented using a priority field set by the producer when delivering the message. For example, different priorities can be represented by integer values, enumeration types, or string identifiers to distinguish the criticality of messages and ensure that the system can identify the business value of high-priority messages. Calculating the second benefit of the nth message based on its second benefit and message priority means introducing message priority as a dynamic weighting factor into the benefit function. This can be achieved by combining the priority value with the second benefit using multiplication, addition, or other mathematical operations. This ensures that high-priority messages receive priority in load balancing decisions, avoiding the risk of high-priority messages being consumed by low-priority messages due to low-load consumers.

[0091] This application's embodiments, by introducing message priority, the aggregation effect of other messages, consumer message backlog, and load balancing decisions for each message, fully consider the dynamic changes in the implicit load state of consumers and message backlog. This effectively avoids the problem of message backlog surges caused by multiple messages simultaneously selecting the same consumer, ensuring that message distribution adaptively adjusts to a Nash equilibrium state, thus improving the load balancing robustness and overall performance of the message middleware system. Through this scheme, high-priority messages can be preferentially allocated to consumers with strong processing capabilities, effectively avoiding the backlog of high-priority messages, improving the system's real-time response capability to critical business operations, and ensuring the overall processing efficiency and reliability of the message middleware.

[0092] Figure 7 A schematic diagram of the structure of a load balancing system according to an embodiment of this application is shown. (Refer to...) Figure 7 This application provides a load balancing system, including: The producer side has 100 units, used to deliver N messages; Server-side 200 is used to execute any load balancing method and generate a load balancing decision matrix. Consumer-side 300 is used to deliver N messages to I consumers based on the load balancing decision matrix.

[0093] Specifically, producer 100 refers to the message sender, which uses a message queue client library to implement message delivery functionality. This ensures the clarity and completeness of message input sources, enabling server 200 to perform decision-making calculations based on a unified message set, avoiding data inconsistency issues caused by dispersed message sources. Server 200 is the core component for determining load balancing decisions. It uses a distributed computing framework to execute load balancing methods, dynamically generating the optimal load balancing decision for each message by combining message backlog and host metric values. This overcomes the shortcomings of traditional methods that allocate based solely on queue size while ignoring the actual processing capacity of consumers. Consumer 300 refers to the message receiver and processor, which uses a message queue client library to receive messages. This ensures that each consumer strictly follows the load balancing decision of server 200 when receiving messages, effectively preventing resource contention or backlog imbalances that might occur if consumers choose their own messages.

[0094] For example, the system achieves load balancing through a collaborative architecture of producer 100, server 200, and consumer 300. Producer 100 first sends N messages to server 200, which form the input basis for executing the load balancing method. After receiving the messages, server 200 executes the aforementioned load balancing method, iteratively calculating based on the message backlog of consumers and host metric values ​​to obtain the optimal load balancing decision for each message, and then delivers each message to the respective consumer 300.

[0095] In one specific implementation, producer 100 uses RocketMQ's Producer client library, delivering messages with priority indicators to the target topic by calling the send method. Server 200 extends RocketMQBroker, implementing a custom AllocateMessageQueueStrategy interface, executing the aforementioned load balancing method in the allocate method. Server 200 collects metrics such as CPU frequency, CPU utilization, free memory, memory utilization, and message backlog reported by the node-exporter of consumer 300 through the Prometheus monitoring system. Consumer 300 uses RocketMQ's PushConsumer client library, automatically pulling messages from the designated queue for processing based on the load balancing decision matrix issued by server 200. After server 200 completes the load balancing decision, it synchronizes the decision matrix to each consumer instance through a heartbeat mechanism, allowing the consumer instances to adjust their message pulling behavior accordingly.

[0096] This embodiment of the application clearly defines the boundaries of responsibility among the producer 100, server 200, and consumer 300. This ensures that the producer 100 guarantees the uniformity and integrity of message input, the server 200 generates optimal load balancing decisions based on the complete message set and consumer state data, and the consumer 300 strictly follows the optimal load balancing decisions, effectively preventing resource contention or imbalance. This end-to-end division of responsibilities allows load balancing strategies to be seamlessly integrated into the message middleware system, fully leveraging the dynamic adaptability to consumer processing capabilities and significantly improving the adaptability and stability of the message middleware in dynamic environments.

[0097] Figure 8 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. (Refer to...) Figure 8 This application also provides an electronic device, including: processor.

[0098] Memory is used to store processor-executable instructions.

[0099] The processor is configured to execute instructions to implement any load balancing method.

[0100] In this embodiment, the computer device includes a processor, memory, and network interface connected via a system bus. The processor of this computer device provides computing and control capabilities. The memory of this computer device includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of this computer device is used to store data samples. The network interface of this computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements any load balancing method.

[0101] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0102] This application also provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of a terminal, enables the terminal to execute any load balancing method.

[0103] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory, electrically erasable programmable read-only memory, erasable programmable read-only memory, programmable read-only memory, read-only memory, magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0104] Optionally, a readable storage medium can be coupled to the processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Of course, the processor and the readable storage medium can also exist as discrete components in the device.

[0105] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements any load balancing method.

[0106] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0107] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0111] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0112] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0114] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A load balancing method, characterized in that, Applied to the server side, including: Receive N messages from the producer, where N is a positive integer; Collect message backlog and host metric values ​​for I consumers, where I is a positive integer; Based at least on the message backlog and the host metric value, for each message, iteratively update the load balancing decision for that message and the load balancing decisions for other messages; If the load balancing decisions for all messages cannot be changed, stop the iterative update and determine the load balancing decisions for the N messages at the time the iterative update stops as the target load balancing decisions for the N messages. Based on the target load balancing decision of the N messages, the N messages are delivered to the I consumers.

2. The method as described in claim 1, characterized in that, The iterative update of the load balancing decision for this message and the load balancing decisions for other messages includes: Initialize the load balancing decision for the N messages; For the first message, the revenue of the first message is calculated based at least on the load balancing decision of the first message and the load balancing decisions of other messages corresponding to the first message, as well as the message backlog and the host metric value. While keeping the load balancing decisions of other messages corresponding to the first message unchanged, iteratively update the load balancing decision of the first message until the benefit of the first message reaches its maximum, and obtain the optimal load balancing decision of the first message, which will be used as the load balancing decision of the first message in subsequent iterative update processes. For the second message, the benefit of the second message is calculated based at least on the load balancing decision of the second message and the load balancing decisions of other messages corresponding to the second message, as well as the message backlog and the host metric value. While keeping the load balancing decisions of other messages corresponding to the second message unchanged, iteratively update the load balancing decision of the second message until the benefit of the second message reaches its maximum, and obtain the optimal load balancing decision of the second message, which will be used as the load balancing decision of the second message in subsequent iterative update processes. Repeat the above process until the optimal load balancing decision for the nth message is obtained, then stop iterative updates, where 1≤n≤N.

3. The method as described in claim 2, characterized in that, The host metrics include at least CPU frequency, CPU utilization, free memory, and memory utilization. The benefit of the nth message includes at least the first benefit; The process for determining the first benefit of the nth message includes: The first benefit of the nth message is calculated according to the following formula: in, This represents the load balancing decision for the nth message, where 1 ≤ i ≤ I. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the nth message is: the nth message is not delivered to the i-th consumer. A value of 1 indicates that the load balancing decision for the nth message is: the nth message is delivered to the i-th consumer. Indicates the CPU frequency of the i-th consumer. This represents the CPU utilization rate of the i-th consumer. This represents the free memory of the i-th consumer. This represents the memory usage rate of the i-th consumer.

4. The method as described in claim 3, characterized in that, The benefit of the nth message includes at least the second benefit; The calculation process for the second benefit of the nth message includes: For the nth message, based on the load balancing decision of the other messages corresponding to the nth message for the i-th consumer, calculate the aggregation impact of the other messages corresponding to the nth message on the i-th consumer; The first sub-benefit of the nth message to the i-th consumer is calculated based at least on the aggregated impact of other messages corresponding to the nth message on the i-th consumer and the message backlog of the i-th consumer; The second sub-benefit of the nth message to the i-th consumer is calculated based at least on the first sub-benefit of the nth message to the i-th consumer and the load balancing decision of the nth message to the i-th consumer; The second benefit of the nth message is obtained based at least on the second sub-benefit of the nth message for each consumer.

5. The method as described in claim 4, characterized in that, Also includes: Collect the message priority of the nth message; The step of obtaining the second benefit of the nth message based at least on the second sub-benefit for each consumer according to the nth message includes: The second benefit of the nth message is calculated based on the second benefit of the nth message and the message priority of the nth message.

6. The method as described in claim 2, characterized in that, The process for determining the reward of the nth message includes: Where 1≤i≤I, 1≤o≤N, This represents the benefit of the nth message. The first preset parameter, This is the second preset parameter. This indicates the message priority of the nth message. This represents the load balancing decision for the 0th message. The value can be 0 or 1. A value of 0 indicates that the load balancing decision for the 0th message is: the nth message is not delivered to the 1st consumer. A value of 1 indicates that the load balancing decision for the 0th message is: the nth message is delivered to the 1st consumer. This represents the message backlog for the i-th consumer.

7. A load balancing system, characterized in that, include: The producer side is used to deliver N messages; The server-side component is used to execute the load balancing method as described in any one of claims 1-6 and generate a load balancing decision matrix. On the consumer side, the system delivers the N messages to the I consumers based on the load balancing decision matrix.

8. An electronic device, characterized in that, include: processor; Memory for storing processor-executable instructions; The processor is configured to execute the instructions to implement the load balancing method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the terminal, the terminal is enabled to perform the load balancing method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the load balancing method as described in any one of claims 1-6.

Images