Message queue cluster management method and device, computer device, and storage medium

Abstract

The present disclosure relates to a message queue cluster management method and device, computer equipment and storage medium. Including obtaining a plurality of message flows of a target message queue cluster at different historical time steps, predicting the message flow of the next time step according to the plurality of message flows to obtain the predicted message flow of the next time step; compare the predicted message flow with the preset message flow threshold, and generate a plurality of scheduling decisions according to the comparison result; for each scheduling decision, predict the running data of each server when the target message queue cluster executes the scheduling decision; according to the running data, determine the target scheduling decision from the plurality of scheduling decisions; control the target message queue cluster to execute the target scheduling decision. In this way, not only can the efficiency and stability of message processing of the target message queue cluster be guaranteed in the long term, but also unnecessary hardware investment and energy consumption can be reduced by reasonable allocation of resources, and the cluster operation and maintenance cost is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of message queues, and more particularly to a method, apparatus, computer device, and storage medium for managing a message queue cluster. Background Technology

[0002] As businesses continue to grow, the demand for messaging is increasing. Among these, RocketMQ, a distributed messaging middleware system with high performance, high reliability, and high scalability, has been widely adopted in various enterprise applications.

[0003] In related technologies, scaling decisions can be determined based on custom RocketMQ message backlog, message traffic, and other metrics, thereby adjusting the capacity of the Broker service cluster and achieving automated and efficient application scaling. These methods typically trigger scaling operations only after the Broker service cluster is overloaded or a traffic peak has occurred. However, the creation and scheduling of a Broker, and the subsequent full service readiness, require a certain time period. During this period, the Broker service cluster continues to bear high pressure, failing to effectively prevent performance bottlenecks. Similarly, scaling down is based solely on the current momentary low load, making it prone to misjudgment and repeated resource fluctuations. While achieving automation overall, it lacks predictability, and its efficiency and response speed are still insufficient to cope with sudden and drastic traffic fluctuations. Summary of the Invention

[0004] In view of this, the present disclosure provides a message queue cluster management method, apparatus, computer device, and storage medium to solve the problems existing in the related art.

[0005] A first aspect of this disclosure provides a method for managing a message queue cluster. The method includes: acquiring multiple message flows of a target message queue cluster at different historical time steps; predicting message flows for the next time step based on the multiple message flows to obtain predicted message flows for the next time step; comparing the predicted message flows with a preset message flow threshold; generating multiple scheduling decisions based on the comparison results; wherein the target message queue cluster includes multiple servers, each server running at least one message queue component, and the scheduling decisions are used to control at least one server to add or remove a message queue component; for each scheduling decision, predicting the running data of each server when the target message queue cluster executes the scheduling decision; determining a target scheduling decision from the multiple scheduling decisions based on the running data; and controlling the target message queue cluster to execute the target scheduling decision.

[0006] A second aspect of this disclosure provides a message queue cluster management apparatus, applied to the message queue cluster management selection method of the first aspect. The apparatus includes: an acquisition module, configured to acquire multiple message flows of a target message queue cluster at different historical time steps, and predict message flows for the next time step based on the multiple message flows to obtain predicted message flows for the next time step; a comparison module, configured to compare the predicted message flows with a preset message flow threshold, and generate multiple scheduling decisions based on the comparison results, wherein the target message queue cluster includes multiple servers, each server running at least one message queue component, and the scheduling decisions are used to control at least one server to add or remove a message queue component; a determination module, configured to predict the running data of each server when the target message queue cluster executes the scheduling decision for each scheduling decision; and an execution module, configured to determine a target scheduling decision from the multiple scheduling decisions based on the running data; and control the target message queue cluster to execute the target scheduling decision.

[0007] A third aspect of this disclosure provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described message queue cluster management method.

[0008] A fourth aspect of this disclosure provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the steps of the message queue cluster management method described above.

[0009] According to a fifth aspect of this disclosure, a computer program product is provided that, when executed by a processor, implements the steps of the above-described message queue cluster management method.

[0010] The above-mentioned at least one technical solution adopted in the embodiments of this disclosure can achieve the following beneficial effects: by acquiring multiple message traffic data of the target message queue cluster at different historical time steps, the message traffic of the next time step is predicted based on the multiple message traffic data to obtain the predicted message traffic of the next time step; the predicted message traffic is compared with a preset message traffic threshold, and multiple scheduling decisions are generated based on the comparison results, wherein the target message queue cluster includes multiple servers, each server runs at least one message queue component, and the scheduling decisions are used to control at least one server to add or remove a message queue component; for each scheduling decision, the running data of each server is predicted when the target message queue cluster executes the scheduling decision; the target scheduling decision is determined from the multiple scheduling decisions based on the running data; and the target message queue cluster is controlled to execute the target scheduling decision.

[0011] As can be seen, this embodiment of the present disclosure, by first acquiring multiple message traffic data at different historical time steps of the target message queue cluster and then predicting the message traffic at the next time step based on this, can grasp the load change trend of message processing of the target message queue cluster in advance, avoiding passive response problems caused by a lack of prediction of message traffic fluctuations, providing scientific data support for subsequent scheduling decisions, and effectively reducing system risks caused by sudden increases or decreases in message traffic; then, the predicted message traffic is compared with a preset message traffic threshold to generate multiple scheduling decisions, which can formulate differentiated scheduling decisions for message queue components for different traffic scenarios, ensuring the pertinence and diversity of scheduling decisions, and avoiding the limitations that may exist in a single scheduling decision; subsequently, the target message queue cluster executes the scheduling decision based on the predicted message traffic. During the scheduling process, the operational data of each server is filtered from multiple scheduling decisions to select the target scheduling decision. This allows for a comprehensive assessment of the impact of different decisions on the server's operational status, identifying the decision that, while ensuring stable system operation, meets the preset message traffic processing requirements and optimizes server resource utilization. This avoids server overload or resource idleness caused by blind scheduling. Finally, the target message queue cluster is controlled to execute the target scheduling decision, implementing the optimal target scheduling scheme and achieving precise control over the message processing capabilities of the target message queue cluster. This not only ensures the long-term efficiency and stability of message processing in the target message queue cluster but also reduces unnecessary hardware investment and energy consumption through reasonable resource allocation, thereby lowering cluster operation and maintenance costs. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 A schematic diagram illustrating the elastic scaling of message queues via HPA in a K8s cluster, provided as an exemplary embodiment of this disclosure;

[0014] Figure 2 A flowchart illustrating a message queue cluster management method provided as an exemplary embodiment of this disclosure;

[0015] Figure 3 A schematic diagram of the structure of a Transformer model provided as an exemplary embodiment of this disclosure;

[0016] Figure 4 A schematic diagram of the structure of a target message traffic prediction model provided as an exemplary embodiment of this disclosure;

[0017] Figure 5 A flowchart illustrating another message queue cluster management method provided as an exemplary embodiment of this disclosure;

[0018] Figure 6 This is a schematic diagram of the structure of a message queue cluster management device provided in an embodiment of the present disclosure;

[0019] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure;

[0020] Figure 8 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure;

[0021] Figure 9 A schematic diagram of a computer program product provided in an embodiment of this disclosure. Detailed Implementation

[0022] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0023] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0024] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0025] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0026] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0027] With the continuous development of enterprise businesses, the demand for messaging is showing an increasing trend. Among these, RocketMQ, a distributed messaging middleware system with high performance, high reliability, and high scalability, has been widely used in various enterprise applications. However, in practical use cases, message backlog is a common problem, especially under high load or high traffic conditions. Message backlog and high traffic can easily cause excessive system load, and in severe cases, may even lead to RocketMQ crashes. Here, RocketMQ is designed based on a highly available distributed cluster architecture, featuring low latency, high throughput, high reliability, and scalability. It is mainly used to solve problems such as asynchronous message communication, peak shaving, and system decoupling in distributed systems, and supports rich features such as publish / subscribe, message filtering, transactional messages, and scheduled messages.

[0028] When using RocketMQ, if the broker experiences performance bottlenecks, related technologies can address this by adding new brokers, creating new topics on new brokers, or using brokers with existing topics to alleviate the load on existing brokers, thus scaling up to prevent service crashes. However, this method is cumbersome, prone to errors, and time-consuming. Another approach is to leverage Kubernetes' Horizontal Pod Autoscaling (HPA) to automatically adjust the number of Pods in the Replication Controller (RC), Deployment, or Replica Set (RS) based on CPU and memory utilization, thereby achieving automatic scaling. It's important to understand that one broker process runs within one Pod.

[0029] As mentioned above, the Broker is the core role in message relay, responsible for receiving, storing, forwarding, and delivering messages. It is the core service node of RocketMQ, through which all producers and consumers interact with RocketMQ. A Topic is a logical classification or publish-subscribe channel for messages, serving as the core medium and unified address for message passing between producers and consumers. Kubernetes, often simply referred to as a K8s cluster, is an open-source platform for automatically deploying, scaling, and managing containerized applications. In Kubernetes, a Pod is the smallest deployable computing unit that can be created, scheduled, and managed. It is a logical collection of one or more containers that share storage, network resources, and a set of operating specifications. HPA is a core automation feature in Kubernetes that automatically adjusts the number of Pods managed by a specific controller (such as Deployment, StatefulSet, or ReplicaSet) to match its current average resource utilization (such as CPU, memory) or custom metrics with user-specified target values. RC is the controller originally used in Kubernetes to ensure the number of Pods. RS is an upgraded version of RC, with the same core goal: ensuring a specified number of Pods run stably. Deployment is a higher-level API object designed to manage stateless applications, indirectly managing Pods by managing ReplicaSets. CPU, short for Central Processing Unit, is the core component of a computer, often referred to as the computer's "brain." Its main functions are interpreting and executing computer instructions and processing data.

[0030] Figure 1 This diagram illustrates how message queue elastic scaling is achieved through HPA in a Kubernetes cluster, as provided in an exemplary embodiment of this disclosure. Figure 1As shown, the Kubernetes cluster 100 mainly includes a monitoring unit 101, a bridging unit 102, a control unit 103, and a Broker service cluster 105. The monitoring unit 101 is typically implemented by a Prometheus server, responsible for collecting, storing, and providing monitoring data to the Broker service cluster 105. The bridging unit 102 typically uses a Prometheus Adapter as a metrics adapter, converting the monitoring data from the monitoring unit 101 into Custom Metrics data recognizable by the Custom Metrics API. The control unit 103 includes an HPA controller, which obtains the converted Custom Metrics data through the Custom Metrics API and calculates the required number of Pods according to predefined rules. Then, the management unit 104 can generate control commands based on the required number of Pods calculated by Kubernetes to control the Broker service cluster 105 to adjust the number of Brokers. The Broker service cluster 105 consists of multiple Brokers, which are divided into two roles: master Broker (Broker-master Pod) and slave Broker (Broker-slave Pod). Typically, a master Broker and a slave Broker appear in pairs.

[0031] As mentioned above, Prometheus is an open-source system monitoring and alerting toolkit, and an independent time-series database and monitoring platform; the Custom Metrics API is a standard, extended application programming interface specification defined by the Kubernetes cluster; the Prometheus Adapter is a program that specifically implements the Custom Metrics API specification; Custom Metrics data refers to any non-Kubernetes cluster native metrics data exposed through the Custom Metrics API that are used to describe the specific state and performance of an application.

[0032] like Figure 1As shown, the Broker service cluster 105 is managed by a StatefulSet and contains multiple Brokers, specifically a master Broker (Broker-master Pod) and slave Brokers (Broker-slave Pods), typically deployed in pairs. When the management unit 104 adjusts the number of Brokers in the StatefulSet, the Kubernetes cluster 100 automatically performs Broker creation or deletion operations, thereby enabling the scaling up and down of the Broker service cluster 105. Here, the StatefulSet is one of the core workload objects in the Kubernetes cluster used to manage stateful applications.

[0033] like Figure 1 As shown, in the K8S cluster 100, the monitoring unit 101 can continuously collect data on various custom metrics of the Broker service cluster 105, such as message backlog or message traffic. When elastic scaling is required, the control unit 103 queries this data through the bridging unit 102 and calculates the required number of Brokers according to rules. Automatic scaling is achieved by adjusting the number of Brokers in the StatefulSet. It is evident that the above method can determine scaling decisions based on custom RocketMQ message backlog, message traffic, and other metrics, thereby adjusting the capacity of the Broker service cluster 105, achieving automated and efficient application scaling, and improving system reliability and stability. The StatefulSet provides a unique identifier and stable, persistent storage for the Brokers it manages, ensuring the orderliness and predictability of Broker deployment, scaling, and updates. Furthermore, the Broker service cluster is a core component of the message queue cluster.

[0034] In summary, manual scaling is cumbersome, complex to configure, prone to errors, and requires significant manpower and time. While elastic scaling of RocketMQ via HPA in a Kubernetes cluster achieves automation, saves manpower and resources, and shortens operation time, it suffers from poor real-time performance for custom metrics such as message traffic, exhibiting a certain degree of lag. Furthermore, the scheduling strategy of Kubernetes cluster brokers for scaling has limitations; the broker scheduling in these technologies does not differentiate between the resource requirements of the business and does not consider the different resource needs of the master and slave brokers in RocketMQ. This means that the server scheduled by the broker may not be the optimal solution, potentially introducing new risks to subsequent use of RocketMQ.

[0035] To address the aforementioned issues, this disclosure provides a message queue cluster management method. This method involves acquiring multiple message traffic data from the target message queue cluster at different historical time steps, predicting the message traffic for the next time step based on these multiple message traffic data, and obtaining the predicted message traffic for the next time step. The predicted message traffic is then compared with a preset message traffic threshold to obtain a comparison result. Multiple scheduling decisions are generated based on the comparison result, whereby the scheduling decisions control the scheduling of newly added or removed message queue components on multiple servers within the target message queue cluster. The method further involves determining the operational data of each server after executing the multiple scheduling decisions, identifying a target scheduling decision from among the multiple scheduling decisions based on this operational data, and finally executing the target scheduling decision.

[0036] As can be seen, this embodiment of the present disclosure, by first acquiring multiple message traffic data at different historical time steps of the target message queue cluster and then predicting the message traffic at the next time step based on this, can grasp the load change trend of message processing of the target message queue cluster in advance, avoiding passive response problems caused by a lack of prediction of message traffic fluctuations, providing scientific data support for subsequent scheduling decisions, and effectively reducing system risks caused by sudden increases or decreases in message traffic; then, the predicted message traffic is compared with a preset message traffic threshold to generate multiple scheduling decisions, which can formulate differentiated scheduling decisions for message queue components for different traffic scenarios, ensuring the pertinence and diversity of scheduling decisions, and avoiding the limitations that may exist in a single scheduling decision; subsequently, by predicting the target message queue cluster... When executing scheduling decisions, each server's operational data is filtered from multiple scheduling decisions to select the target scheduling decision. This allows for a comprehensive assessment of the impact of different decisions on the server's operational status, selecting the decision that, while ensuring stable system operation, meets the preset message traffic processing requirements and optimizes server resource utilization. This avoids server overload or resource idleness caused by blind scheduling. Finally, executing the target scheduling decision implements the optimal target scheduling scheme, enabling precise control over the message processing capabilities of the target message queue cluster. This not only ensures the long-term efficiency and stability of message processing in the target message queue cluster but also reduces unnecessary hardware investment and energy consumption through reasonable resource allocation, thereby lowering cluster operation and maintenance costs.

[0037] Figure 2 This is a flowchart illustrating a message queue cluster management method provided as an exemplary embodiment of this disclosure. Figure 1 As shown, it specifically includes:

[0038] S201, construct a target message traffic prediction model, and input multiple message traffic data from the target message queue cluster at different historical time steps into the target message traffic prediction model to generate the predicted message traffic for the next time step. Here, the target message queue cluster is... Figure 1The Broker service cluster shown is 105.

[0039] In practical applications, Transformer excels at capturing long-range dependencies in time series. However, its prediction accuracy remains limited when dealing with time series data such as message traffic, which exhibits complex volatility and nonlinearity. To overcome this shortcoming, this embodiment combines the adversarial learning mechanism of Generative Adversarial Networks (GANs) with Transformer. By introducing a discriminator from GAN, the Transformer-based generative network is co-trained and optimized. This alleviates the common problem of accumulated errors in time series prediction, thereby significantly improving the accuracy and robustness of RocketMQ message traffic prediction. Here, Transformer is a deep learning model architecture based on a self-attention mechanism. Its core lies in completely abandoning traditional recurrent neural network and convolutional neural network structures, instead utilizing an attention mechanism to globally model the dependencies between elements in the input sequence. GAN is a deep learning model architecture whose core idea originates from two-player zero-sum games in game theory, where training is achieved through the adversarial competition between two neural networks: a generator and a discriminator.

[0040] In some embodiments, the Transformer employs a network architecture entirely based on a self-attention mechanism. This self-attention mechanism effectively captures long-range dependencies. The specific calculation formula for the self-attention mechanism is as follows:

[0041]

[0042] in, This represents a matrix composed of query vectors. Represents a matrix composed of key vectors; A matrix representing value vectors; Indicates the dimension of the input data. Indicates the activation function; I This represents the input data set.

[0043] Figure 3 This is a schematic diagram of the structure of a Transformer model provided as an exemplary embodiment of this disclosure. For example... Figure 3As shown, the Transformer model consists of an input module 301, an encoding module 302, a decoding module 303, and an output module 304. The raw input data is first converted into vector form by an input embedding layer, and then superimposed with a position encoding module 3011 to capture the relative position information of the raw data in the corresponding time series, providing key positional information for subsequent processing. It should be understood that the raw data here can be message traffic at different time steps.

[0044] like Figure 3 As shown, the encoding module 302 can be composed of N independent encoding layers stacked together. Each encoding layer includes a multi-head attention layer, two regularization layers, and a feedforward neural network layer. The multi-head attention layer focuses on different details of the original data in different subspaces, while the regularization layers stabilize the neural network training process, accelerate model convergence, and slightly alleviate overfitting. The feedforward neural network further processes the data output by the multi-head attention layer. Here, a regularization layer follows both the multi-head attention layer and the feedforward neural network layer.

[0045] like Figure 3 As shown, the decoding module 303 can also be composed of N independent decoding layers stacked together. Each decoding layer includes a Mask multi-head attention layer, a multi-head attention layer, a feedforward neural network, and three regularization layers. Here, a regularization layer follows each of the Mask multi-head attention layer, the multi-head attention layer, and the feedforward neural network layer. The Mask multi-head attention layer is used to filter out invalid information and ensure the logical rationality of the time-series prediction; the multi-head attention mechanism is used to capture long-distance dependencies from multiple dimensions; and the feedforward neural network layer can perform nonlinear transformations and dimensional expansion on the features output by the attention layer.

[0046] like Figure 3 As shown, the output module 304 includes a linear transformation layer and an activation layer. The linear transformation layer can perform a linear transformation on the data output by the decoding module 303, mapping the data output by the decoding module 303 to the target dimension. Then, the model output in the form of a probability distribution is obtained through the Softmax activation function of the activation layer.

[0047] As can be seen, the Transformer model, with its self-attention mechanism, breaks through the limitations of traditional recurrent neural networks in processing long sequences, directly capturing the correlation between message flows at different historical time steps and identifying long-distance dependencies. The multi-head attention mechanism simultaneously mines multi-scale temporal features, capturing both short-term fluctuations and long-term trends. The feedforward neural network layer performs non-linear transformations on the features, enhancing the capture of complex patterns. Positional encoding clearly defines the time step order, allowing the Transformer model to accurately analyze the patterns between message flows at different historical time steps, thereby reliably predicting message flows at the next time step. This lays the foundation for subsequently combining with GAN networks to form a target message flow prediction model to improve the accuracy of RocketMQ traffic prediction.

[0048] Figure 4 This is a schematic diagram illustrating the structure of a target message traffic prediction model provided as an exemplary embodiment of this disclosure. Figure 4 As shown, the network architecture of the target message traffic prediction model is a structure that integrates Transformer and Generative Adversarial Network (GAN). Real data 401 is input into generator 402 to generate predicted data 403. Simultaneously, both real data 401 and the generated predicted data 403 are input into discriminator 404. Discriminator 404 outputs a judgment label 405, indicating whether the predicted data 403 is true or false. Combined with an error backpropagation mechanism, generator 402 is optimized. Through adversarial training between generator 402 and discriminator 404, effective generation and discrimination of predicted data are achieved, thereby improving the performance of the target message traffic prediction model. It should be understood that the real data 401 here can include multiple message traffic flows from the target message queue cluster at different historical time steps, and the predicted data can include the predicted message traffic at the next time step. The judgment label 405 is output as true when the predicted data 403 and real data 401 are the same or meet a preset error; otherwise, it is output as false. Generator 402 here can be... Figure 3 The Transformer model shown.

[0049] In some embodiments, message traffic from 16 consecutive time steps can be used as input data for a preset message traffic prediction model, where the preset message traffic prediction model is an untrained target message traffic prediction model. When training the preset message traffic prediction model, the generator can use message traffic from the first 15 consecutive time steps (e.g., ...) as input data. Figure 4 The actual data (4001) shown is input into the generator, which predicts the message flow for the 16th time step based on the message flow of the previous 15 consecutive time steps (e.g., ...). Figure 4The predicted data shown is 403. At this point, the generator can process the message flow of the first 15 time steps through its internal multi-head attention layer and feedforward neural network layer, and output the predicted message flow for the next time step, i.e., the 16th time step. Meanwhile, the discriminator receives two types of input simultaneously: the predicted message flow generated by the generator and the actual message flow of the 16th time step. The discriminator's task is to distinguish between "true" and "false" data, essentially differentiating between real and predicted message flow. If the result is determined to be false, training continues; if it is determined to be true, the target message flow prediction model is generated.

[0050] Based on this, message traffic at different time steps can be obtained, and message traffic from multiple consecutive time steps can be used as a training sample to train the preset message traffic prediction model according to the training method described above. During model training, the output error of the discriminator will be backpropagated to the generator. Through an adversarial training mechanism, the generator's prediction ability is continuously optimized. The generator and discriminator undergo multiple rounds of iterative training, playing against each other and dynamically adjusting parameters until the target message traffic prediction model reaches a Nash equilibrium state, that is, the predicted message traffic generated by the generator is realistic enough that the discriminator cannot effectively distinguish between the predicted message traffic and the real message traffic. At this point, the preset message traffic prediction model is considered to have achieved good prediction performance, and thus the preset message traffic prediction model at this time is determined to be the target message traffic prediction model.

[0051] Here, the message traffic at 16 time steps can be monitored by a monitoring unit deployed in the target message queue cluster (such as...). Figure 1 The monitoring unit 101 shown continuously collects data, and the monitoring unit can capture the message traffic of the target message queue cluster at fixed time intervals (e.g., every second or every minute).

[0052] The loss function of the discriminator mentioned above The specific calculation formula is as follows:

[0053]

[0054] in, Indicates the number of training samples for the test; Indicates truth; Indicates false; D (·) indicates that a set of data is input into the discriminator model. i Indicates data identifier.

[0055] In some embodiments, for generators (such as...) Figure 4 The design of the loss function for generator 402 shown in the figure also considers the generator loss of the original adversarial generative network. and MSE The combined effect of loss functions. Based on this, the formula for calculating the generator's loss function can be defined as follows:

[0056]

[0057]

[0058]

[0059] in, Indicates mean square error; Indicates the number of training samples for the test; This indicates a predicted message flow. This represents the actual message traffic; express The proportion of; express The specific weight can be set as follows: .

[0060] Based on this, a trained target message traffic prediction model can be used to determine the predicted message traffic for the next time step based on the message traffic of the target message queue cluster at different historical time steps.

[0061] S202: Obtain the operational data of multiple servers in the target message queue cluster, compare the predicted message traffic for the next time step with a preset message traffic threshold, and generate a scheduling decision based on the comparison result and the operational data of multiple servers in the target message queue cluster. The preset message traffic threshold may include a preset expansion threshold and a preset reduction threshold. This indicates the maximum traffic limit that the target message queue cluster can comfortably handle at its current cluster size, and the preset scaling-down threshold. This represents the minimum traffic threshold at which the resource utilization of the target message queue cluster is too low under the current cluster size.

[0062] In some embodiments, the predicted message traffic output after S101 can be... respectively with and When a comparison is performed, When the target message queue cluster is scaled down, The target message queue cluster is then expanded. Expansion can involve adding a new group of brokers, while shrinking can involve removing a group of brokers. Here, a group of brokers includes a master broker and slave brokers. In practice, master and slave brokers always appear in pairs, so both need to be processed simultaneously.

[0063] In some embodiments, to when Taking the scaling up of a target message queue cluster as an example, this embodiment mainly considers the impact of three metrics—disk I / O, memory, and CPU—on Broker performance, and uses this as a basis to achieve elastic scaling and resource scheduling. The core lies in simultaneously optimizing load balancing at two levels: first, balancing the utilization of various resources within a single server; and second, balancing the load across all servers within the entire target message queue cluster.

[0064] Specifically, assume the target message queue cluster consists of m master brokers and m slave brokers, that is, the set of brokers in the target message queue cluster. ,in, Indicates the first master broker; Indicates the first one from the Broker; Indicates the second master broker; Indicates the second one from Broker; Indicates the first m The main broker; Indicates the first m A cluster of servers in the target message queue cluster, originating from a broker. ,in, Indicates the first server; This indicates the second server; Indicates the first n Each server. Based on this, when At this time, it is necessary to expand by one group of Brokers. After the expansion, the resource utilization load status of each server in the target message queue cluster will be as follows. The calculation formula can be:

[0065]

[0066] in, Indicates the server after expansion CPU utilization; Server after expansion Memory utilization; Indicates the server after expansion Disk I / O utilization; It is the expanded server Average utilization of various resources; Indicates the first i One server. In the above formula... , , , The respective calculation formulas are as follows:

[0067]

[0068]

[0069]

[0070]

[0071] in, This indicates the CPU resources used by the main broker; This indicates the memory resources used by the main broker; This indicates the disk I / O resources used by the main broker; This indicates the CPU resources used by the Broker; This indicates the memory resources used by the Broker; This indicates the disk I / O resources used by the Broker; Indicates the current scheduling to the server. The number of main brokers; Indicates the current scheduling to the server. The number of Brokers; This indicates that after the expansion, the main broker will schedule the servers. The logo; This indicates that after scaling up, data is scheduled from the Broker to the server. The identifier, i.e., when the primary broker of a broker expansion is scheduled to the server. hour =1, otherwise =0, The values ​​are similar; Indicates server Currently, CPU resources used by applications other than the target message queue cluster; Indicates server Currently, the memory resources used by other applications besides the target message queue cluster; Indicates server Currently, disk I / O resources are being used by applications other than the target message queue cluster; Indicates server Total CPU value ； Indicates server Total memory usage; Indicates server The total disk I / O resources. Here, the Broker itself has load balancing, and generally the resource consumption of each Broker is not significantly different, as shown in the formula. , , , , , The specific calculation formula is as follows:

[0072]

[0073]

[0074]

[0075]

[0076]

[0077]

[0078] in, This represents the current message traffic of the entire target message queue cluster; This indicates the predicted message flow for the next time step. This indicates the CPU resources currently being used by the main broker. This indicates the memory resources currently occupied by the main broker. This indicates the disk I / O resources currently being used by the master broker. This indicates the CPU resources currently being used by the Broker. This indicates the memory resources currently used by the Broker. This indicates the disk I / O resources currently used by the broker; here, since the number of master brokers and slave brokers is the same, both are represented by [insert value here]. m To express.

[0079] In some embodiments, the CPU load status of all servers in the target message queue cluster after expansion. Memory load status Disk I / O resource load status The specific calculation formula is as follows:

[0080]

[0081]

[0082]

[0083] in, This represents the average CPU utilization of the target message queue cluster after expansion. This represents the average memory utilization of the target message queue cluster after expansion. This represents the average disk I / O resource utilization of the target message queue cluster after expansion, and the corresponding calculation formula is:

[0084]

[0085]

[0086]

[0087] The variance formula for the load state described above can be used as the objective function to construct a mathematical model for multi-objective load balancing after the expansion of the target message queue cluster. :

[0088]

[0089]

[0090] in, for The variance formula; for The variance formula; for The variance formula; for Variance formula; constraints, , , , This means that after expansion, the master broker or slave broker will only schedule to one server. That is, the master broker and slave broker can schedule to different servers or the same server, but a broker can only schedule to one server. This indicates that after expansion, the resource utilization rate will not exceed 1. Based on this, the optimal solution set is obtained for multiple objectives in the multi-objective optimization problem. This will give us the final scheduling decision for the expanded master and slave brokers, that is, the scheduling position of the newly added master and slave brokers, and which server they will be scheduled to.

[0091] As can be seen, this embodiment of the present disclosure, by first acquiring multiple message traffic data at different historical time steps of the target message queue cluster and then predicting the message traffic at the next time step based on this, can grasp the load change trend of the target message queue cluster's message processing in advance. This avoids the passive response problem caused by a lack of prediction of message traffic fluctuations, provides scientific data support for subsequent scheduling decisions, and effectively reduces the system risks caused by sudden increases or decreases in message traffic. Next, the predicted message traffic is compared with a preset message traffic threshold to generate multiple scheduling decisions. Differentiated scheduling decisions for message queue components can be formulated for different traffic scenarios, ensuring the targeting and diversity of scheduling decisions and avoiding the limitations that may exist with a single scheduling decision. Simultaneously, by controlling the scheduling of adding or removing message queue components on multiple servers, the message processing capacity of the target message queue cluster can be flexibly adjusted, thereby increasing the processing capacity of the target message queue cluster. Matching the predicted message traffic prevents message congestion and delays caused by insufficient processing capacity, or resource waste caused by excessive processing capacity. Then, by determining the operational data after multiple servers execute multiple scheduling decisions and filtering the target scheduling decision, the impact of different decisions on server operation can be comprehensively evaluated. The decision that best meets the preset message traffic processing requirements while ensuring stable system operation and optimal utilization of server resources is selected, avoiding server overload or resource idleness caused by blind scheduling. Finally, executing the target scheduling decision implements the optimal target scheduling scheme, achieving precise control over the message processing capacity of the target message queue cluster. This not only ensures the long-term efficiency and stability of message processing in the target message queue cluster but also reduces unnecessary hardware investment and energy consumption through reasonable resource allocation, lowering cluster operation and maintenance costs.

[0092] The message queue cluster management method provided in this disclosure can be executed by a terminal or by a chip applied to the terminal.

[0093] For example, the aforementioned terminals may include one or more of the following: mobile phones, tablets, wearable devices, in-vehicle devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, handheld computers (PDAs), and wearable devices based on augmented reality (AR) and / or virtual reality (VR) technologies. They may also include, but are not limited to, remote control devices, wearable devices, streetlights, home appliances, and other smart terminals. This disclosure does not impose specific limitations on these aspects.

[0094] Figure 5This is a flowchart illustrating another message queue cluster management method provided as an exemplary embodiment of this disclosure. Figure 5 As shown, the management methods for message queue clusters include:

[0095] S501: Obtain multiple message traffic data from the target message queue cluster at different historical time steps, and predict the message traffic for the next time step based on these multiple message traffic data to obtain the predicted message traffic for the next time step. Here, the target message queue cluster is... Figure 1 The Broker service cluster shown is 105, and different historical time steps are consecutive time steps.

[0096] In some embodiments, message traffic at different historical time steps can be monitored by a monitoring unit deployed in the target message queue cluster (such as...). Figure 1 The monitoring unit 101 shown continuously collects data. It can capture message traffic from the target message queue cluster at fixed time intervals (e.g., per second or per minute). Specific message traffic can include the number of messages processed per unit time. This continuous message traffic from different historical time steps can be input into a pre-trained target message traffic prediction model to obtain the predicted message traffic for the next time step. This target message traffic prediction model can output the predicted message traffic for the next time step through an adversarial training mechanism between the generator and discriminator, combined with the Transformer's ability to capture long sequence dependencies. Here, the target message traffic model is the target message traffic model of S201 mentioned above; the specific construction process can be found in the relevant content above.

[0097] Based on this, the embodiments of this disclosure can obtain multiple message traffic at different historical time steps of the target message queue cluster and predict the message traffic at the next time step based on this. This can help to grasp the load change trend of message processing of the target message queue cluster in advance, avoid the passive response problem caused by lack of prediction of message traffic fluctuations, provide scientific data support for subsequent scheduling decisions, and effectively reduce the system risks caused by sudden increases or decreases in message traffic.

[0098] S502 compares the predicted message traffic with the preset message traffic threshold and generates multiple scheduling decisions based on the comparison results. The target message queue cluster includes multiple servers, and each server runs at least one message queue component. The scheduling decisions are used to control the addition or removal of message queue components on at least one server.

[0099] In some embodiments, the predicted message traffic can be compared with a preset message traffic threshold set in advance through experiments or experience. Specifically, the preset message traffic threshold may include a preset capacity expansion threshold. and preset shrinkage threshold Here, the preset expansion threshold is set. This can represent the maximum traffic limit that the target message queue cluster can comfortably handle under the current cluster size, with a preset scaling-down threshold. This can represent the minimum traffic threshold at which the resource utilization of the target message queue cluster is too low under the current cluster size. Based on this, the predicted message traffic can be... respectively with and A comparison is performed to obtain the comparison results, and multiple scheduling decisions are generated based on the comparison results.

[0100] For example, the comparison results may include and ,when When this happens, the scheduling decision can be to remove message queue components from the target message queue cluster. Here, the idle message queue component or the idle message queue component with the highest idle rate can be selected for removal; when In this context, a scheduling decision could be to add a message queue component to a server. Here, the server with the highest idle time or idle rate can be selected for the message queue component based on operational data. Since the target message queue cluster comprises multiple servers, and message queue components can be added or removed from multiple servers, each operation of adding or removing a message queue component can be viewed as a scheduling decision for the target message queue cluster. Here, the highest idle rate can be defined as the highest memory idle rate or the highest CPU idle rate.

[0101] Based on this, the predicted message traffic is compared with the preset message traffic threshold to generate multiple scheduling decisions. Differentiated scheduling decisions for message queue components can be formulated for different traffic scenarios, ensuring the relevance and diversity of scheduling decisions and avoiding the limitations that may exist in a single scheduling decision. At the same time, by controlling the addition or removal of message queue components, the message processing capacity of the target message queue cluster can be flexibly adjusted so that the processing capacity of the target message queue cluster matches the predicted message traffic, preventing message congestion and delays caused by insufficient processing capacity, or resource waste caused by excessive processing capacity.

[0102] S503, for each scheduling decision, predict the running data of each server when the target message queue cluster executes the scheduling decision. Here, controlling the behavior of adding a message queue component can be considered as expanding the target message queue cluster, while the behavior of removing a message queue component can be considered as shrinking the target message queue cluster. Therefore, the scheduling decision can be considered to include expansion and shrinking decisions. The expansion decision is to add a message queue component to the target message queue cluster, and the shrinking operation is to remove a message queue component from the target message queue cluster.

[0103] In some embodiments, for each generated scheduling decision, a simulation model can first be constructed based on the current operating data of the target message queue cluster, including the CPU utilization, memory utilization, and disk I / O throughput of each server. Then, the parameters of the simulation model are adjusted according to the content of the scheduling decision so that the simulation model simulates the execution of the scheduling decision, such as creating a new message queue component on server A and allocating corresponding resources in the simulation environment. Finally, based on relevant resource calculation formulas, the operating data of each server in the target message queue cluster at a future time step after the execution of the scheduling decision is calculated, thereby providing a quantitative basis for subsequent optimal decision-making. Here, the current operating data of the target message queue cluster can be monitored by a monitoring unit (such as...). Figure 1 The monitoring unit 101 shown is used to obtain the data.

[0104] S504 determines the target scheduling decision from multiple scheduling decisions based on operational data; and controls the target message queue cluster to execute the target scheduling decision.

[0105] Specifically, for any scheduling decision, the operational data of each server after executing the decision can be predicted. When the scheduling decision is to expand, the focus can be on acquiring operational data such as CPU utilization, memory usage, and disk I / O utilization after the server adds the message queue component, to determine the coordination of resource allocation. When the scheduling decision is to shrink, the focus can be on the resource idle rate after the server removes the message queue component, as well as the load changes of other servers due to load shifting, while confirming whether the basic processing capacity of the target message queue cluster meets the standard. Then, based on this operational data, a selection process is conducted: expansion decisions must ensure that server resources are neither overloaded nor idle, latency is not abnormal, and the target message queue cluster's processing capacity matches the traffic growth; while shrinking decisions must ensure that server idle rates are reasonable, no other servers are overloaded, and the cluster capacity covers the lower limit of traffic. Finally, by comparing the scheduling decisions, the one that meets message processing requirements, has the best resource utilization, and operates most stably is selected as the target scheduling decision.

[0106] Based on this, by determining the operational data after multiple servers execute multiple scheduling decisions and filtering the target scheduling decisions, we can comprehensively evaluate the impact of different decisions on the server's operating status, and select the decision that can meet the processing requirements of the preset message traffic while ensuring the stable operation of the target message queue cluster, and make the optimal use of server resources, thus avoiding server overload or resource idleness caused by blind scheduling.

[0107] As can be seen, this embodiment of the present disclosure, by first acquiring multiple message traffic data at different historical time steps of the target message queue cluster and then predicting the message traffic at the next time step based on this, can grasp the load change trend of message processing of the target message queue cluster in advance, avoiding passive response problems caused by a lack of prediction of message traffic fluctuations, providing scientific data support for subsequent scheduling decisions, and effectively reducing system risks caused by sudden increases or decreases in message traffic; then, the predicted message traffic is compared with a preset message traffic threshold to generate multiple scheduling decisions, which can formulate differentiated scheduling decisions for message queue components for different traffic scenarios, ensuring the pertinence and diversity of scheduling decisions, and avoiding the limitations that may exist in a single scheduling decision; subsequently, by predicting the target message queue cluster... When executing scheduling decisions, each server's operational data is filtered from multiple scheduling decisions to select the target scheduling decision. This allows for a comprehensive assessment of the impact of different decisions on the server's operational status, selecting the decision that, while ensuring stable system operation, meets the preset message traffic processing requirements and optimizes server resource utilization. This avoids server overload or resource idleness caused by blind scheduling. Finally, executing the target scheduling decision implements the optimal target scheduling scheme, enabling precise control over the message processing capabilities of the target message queue cluster. This not only ensures the long-term efficiency and stability of message processing in the target message queue cluster but also reduces unnecessary hardware investment and energy consumption through reasonable resource allocation, thereby lowering cluster operation and maintenance costs.

[0108] In some embodiments, the message queue component includes a first message queue component and a second message queue component. Generating multiple scheduling decisions based on the comparison results includes: generating multiple scheduling decisions to add the first message queue component and the second message queue component to the same or different servers based on the comparison results; determining a target scheduling decision from the multiple scheduling decisions based on runtime data; and executing the target scheduling decision, including: for each scheduling decision, determining the load state of each server when executing the scheduling decision based on the runtime data of each server when executing the scheduling decision; and determining the target scheduling decision from the multiple scheduling decisions based on the load state of each server when executing each scheduling decision. Here, the first message queue component can be the master broker mentioned above, and the second message queue component can be the slave broker mentioned above.

[0109] Specifically, when the predicted message traffic exceeds a preset expansion threshold, it can be determined that a set of message queue components needs to be expanded. This set of message queue components includes a first message queue component (such as the master broker mentioned above) and a second message queue component (such as the slave broker mentioned above). Based on this, multiple scheduling decisions can be generated. Each scheduling decision defines different deployment schemes for the first and second message queue components on the same or different servers in the target message queue cluster. For each scheduling decision, the operating data of each server after executing the scheduling decision can be estimated, specifically including CPU utilization, memory utilization, and disk I / O utilization. Based on this operating data, the load status of each server under different scheduling decisions is calculated. Finally, by comparing the load status of all servers under each scheduling decision, the optimal target scheduling decision is selected, thereby achieving the optimal deployment of the first and second message queue components. Here, the specific calculation process and related formulas can be found in S202, which describes the resource utilization load status of each server in the expanded target message queue cluster. Related content.

[0110] Based on this, message queue components can be specifically divided into a first message queue component and a second message queue component. Multiple scheduling decisions for the first and second message queue components across multiple servers can be generated based on the comparison results. Then, the load status of each server is calculated based on the operating data after executing each scheduling decision. Finally, the optimal target scheduling decision is selected from multiple possible scheduling decisions based on the overall cluster load status. This effectively overcomes the deficiency of traditional scheduling strategies in distinguishing the differentiated resource requirements of the first and second message queue components in a message queue cluster. By proactively predicting traffic and pre-evaluating the impact of multiple scheduling schemes on the cluster load status, fine-grained scheduling based on multi-objective optimization is achieved, significantly improving the resource utilization efficiency and system stability of the target message queue cluster during elastic scaling.

[0111] In some embodiments, determining a target scheduling decision from multiple scheduling decisions based on the load state of each server when executing each scheduling decision includes: determining the load state of the target message queue cluster when executing each scheduling decision based on the load state of each server when executing each scheduling decision; and determining the target scheduling decision from multiple scheduling decisions based on the load state of each server and the load state of the target message queue cluster when executing each scheduling decision.

[0112] Specifically, for each scheduling decision, the load status in two dimensions can be calculated based on the estimated operating data of each server: one is the load status of each server itself (assessed by calculating the variance of CPU, memory, and disk I / O utilization on the server; for details, refer to the resource utilization load status of each server in the expanded target message queue cluster in S202 above). The relevant content), and secondly, the load status of the entire target message queue cluster (assessed by calculating the variance of the utilization of all servers in the target message queue cluster across CPU, memory, and disk I / O resources; for details, please refer to the CPU load status of the target message queue cluster after expansion in S202 above). Memory load status Disk I / O resource load status (Related content). By comprehensively analyzing the load status of these two levels under each scheduling decision, a multi-objective optimization algorithm is applied (for details, please refer to the mathematical model of multi-objective load balancing in S202 above). (Related content) Select the optimal target scheduling decision from all scheduling decisions. This target scheduling decision can achieve the optimal distribution of resource load across the entire target message queue cluster while ensuring balanced resource usage on a single server.

[0113] Based on this, a two-tiered (server-level and cluster-level) load status assessment system can be established, and a multi-objective optimization method can be used for decision-making. This effectively solves the problem that traditional scheduling strategies cannot simultaneously balance local server resources and global cluster resources. It is particularly suitable for scenarios where the resource requirements of the first message queue component and the second message queue component are different. It can achieve more refined resource scheduling during elastic scaling, significantly improve the resource utilization efficiency of the target message queue cluster, avoid performance bottlenecks caused by uneven resource allocation, and thus improve the stability and reliability of the entire message queue system.

[0114] In some embodiments, when the scheduling decision is used to control the scheduling of the removed message queue component across multiple servers, the method further includes: determining the message queue component to be removed based on the scheduling decision; if there is a message processing task in the message queue component to be removed, migrating the message processing task to a message queue component other than the message queue component to be removed; and deleting the message queue component to be removed.

[0115] Specifically, when a scaling-down operation is determined based on scheduling decisions, the lightest or least critical Broker in the target message queue cluster is first selected as the message queue component to be removed. Next, it's checked whether the message queue component to be removed has any currently processing message tasks or unconsumed message queues. If so, RocketMQ's built-in message rebalancing mechanism smoothly migrates these message processing tasks to other normal Brokers in the target message queue cluster, ensuring message service continuity and data consistency. After the message migration is complete, these message queue components to be removed can be deleted, completing the scaling-down operation.

[0116] Based on this, a safe and lossless scaling-down operation can be achieved by intelligently selecting message queue components to be removed and ensuring seamless migration of message tasks. This ensures both the continuity of message services and data consistency, improves resource utilization efficiency, avoids message loss or service interruption that may result from the sudden removal of message queue components, and significantly enhances system reliability and operational experience.

[0117] In some embodiments, predicting the message traffic for the next time step based on multiple message traffic includes: inputting multiple message traffic into a target message traffic prediction model to obtain the predicted message traffic for the next time step; wherein the target message traffic prediction model includes a generator and a discriminator, the generator is built based on the Transformer architecture and is used to receive message traffic from historical time steps and generate the predicted message traffic for the next time step, and the discriminator is used to optimize the generator.

[0118] Specifically, the message traffic collected from multiple historical time steps can be input into the target message traffic prediction model for processing. This model employs a GAN-former architecture. The generator, built on a Transformer structure, uses a self-attention mechanism to capture long-term dependencies in message traffic across different historical time steps, generating the predicted message traffic for the next time step. The discriminator then distinguishes between the predicted traffic output by the generator and the actual traffic, feeding the error back to the generator through adversarial training to continuously optimize its prediction accuracy, ultimately obtaining highly accurate predicted message traffic. Here, the target message traffic prediction model is the one constructed in S201.

[0119] Based on this, by combining the long sequence modeling capabilities of Transformer with the adversarial training mechanism of GAN, the accuracy and robustness of message traffic prediction can be significantly improved. This effectively captures the complex temporal characteristics of message traffic, reduces prediction errors, and provides a reliable data foundation for subsequent elastic scaling decisions, thereby improving the response speed and decision quality of the entire resource management system.

[0120] As can be seen, this embodiment of the present disclosure, by first acquiring multiple message traffic data at different historical time steps of the target message queue cluster and then predicting the message traffic at the next time step based on this, can grasp the load change trend of the target message queue cluster's message processing in advance. This avoids the passive response problem caused by a lack of prediction of message traffic fluctuations, provides scientific data support for subsequent scheduling decisions, and effectively reduces the system risks caused by sudden increases or decreases in message traffic. Next, the predicted message traffic is compared with a preset message traffic threshold to generate multiple scheduling decisions. Differentiated scheduling decisions for message queue components can be formulated for different traffic scenarios, ensuring the targeting and diversity of scheduling decisions and avoiding the limitations that may exist with a single scheduling decision. Simultaneously, by controlling the scheduling of adding or removing message queue components on multiple servers, the message processing capacity of the target message queue cluster can be flexibly adjusted, thereby increasing the processing capacity of the target message queue cluster. Matching the predicted message traffic prevents message congestion and delays caused by insufficient processing capacity, or resource waste caused by excessive processing capacity. Then, by determining the operational data after multiple servers execute multiple scheduling decisions and filtering the target scheduling decision, the impact of different decisions on server operation can be comprehensively evaluated. The decision that best meets the preset message traffic processing requirements while ensuring stable system operation and optimal utilization of server resources is selected, avoiding server overload or resource idleness caused by blind scheduling. Finally, executing the target scheduling decision implements the optimal target scheduling scheme, achieving precise control over the message processing capacity of the target message queue cluster. This not only ensures the long-term efficiency and stability of message processing in the target message queue cluster but also reduces unnecessary hardware investment and energy consumption through reasonable resource allocation, lowering cluster operation and maintenance costs.

[0121] The foregoing primarily describes the solutions provided by the embodiments of this disclosure from the perspective of the server. It is understood that, in order to implement the above functions, the server includes the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0122] This disclosure embodiment can divide the server into functional units according to the above method example. For example, it can divide each function into separate functional modules, or it can integrate two or more functions into one management module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0123] In the case of dividing each functional module according to its corresponding functions, an exemplary embodiment of this disclosure provides a management device for a message queue cluster, which can be a server or a chip applied to a server. Figure 6 This is a schematic diagram of the structure of a message queue cluster management device provided in one embodiment of this disclosure. Figure 6 As shown, the management device 600 of the message queue cluster includes:

[0124] The acquisition module 601 is used to acquire multiple message flows of the target message queue cluster at different historical time steps, and predict the message flow of the next time step based on the multiple message flows to obtain the predicted message flow of the next time step.

[0125] The comparison module 602 is used to compare the predicted message traffic with a preset message traffic threshold and generate multiple scheduling decisions based on the comparison results. The target message queue cluster includes multiple servers, and at least one message queue component runs on each server. The scheduling decisions are used to control at least one addition or removal of a message queue component among the multiple servers.

[0126] The determining module 603 is used to predict the running data of each server when the target message queue cluster executes the scheduling decision for each of the scheduling decisions;

[0127] The execution module 604 is used to determine a target scheduling decision from multiple scheduling decisions based on the running data; and to control the target message queue cluster to execute the target scheduling decision.

[0128] In one alternative embodiment, the message queue component includes a first message queue component and a second message queue component. The comparison module 602 is further configured to generate multiple scheduling decisions based on the comparison results, adding the first message queue component and the second message queue component to at least one of the servers. The determination module 603 is further configured to, for each scheduling decision, determine the load state of each server when executing the scheduling decision based on the operating data of each server when executing the scheduling decision; and determine the target scheduling decision from the multiple scheduling decisions based on the load state of each server when executing each scheduling decision.

[0129] In an alternative embodiment, the determining module 603 is further configured to determine the load state of the target message queue cluster when each of the scheduling decisions is executed, based on the load state of each of the servers when each of the scheduling decisions is executed; and to determine the target scheduling decision from among the multiple scheduling decisions based on the load state of each of the servers when each of the scheduling decisions is executed and the load state of the target message queue cluster when each of the scheduling decisions is executed.

[0130] In an optional embodiment, the message queue cluster management device 600 further includes a migration module 605, which is used to determine the message queue component to be removed based on the scheduling decision; when there is a message processing task in the message queue component to be removed, migrate the message processing task to a message queue component other than the message queue component to be removed; and delete the message queue component to be removed.

[0131] In an optional embodiment, the comparison module 602 is further configured to, when the predicted message traffic is greater than or equal to the preset expansion threshold, use the scheduling decision to control the scheduling of newly added message queue components among the multiple servers; and when the predicted message traffic is less than or equal to the preset reduction threshold, use the scheduling decision to control the scheduling of removed message queue components among the multiple servers.

[0132] In an optional embodiment, the acquisition module 601 is further configured to input multiple message flows into a target message flow prediction model to obtain the predicted message flow for the next time step; wherein the target message flow prediction model includes a generator and a discriminator, the generator is constructed based on a self-attention model and is used to receive message flows from historical time steps and generate predicted message flows for the next time step, and the discriminator is used to optimize the generator.

[0133] This disclosure also provides an electronic device, including: at least one processor; a memory for storing at least one processor-executable instruction; wherein the at least one processor is used to execute the instruction to implement the steps of the method disclosed in this disclosure.

[0134] Figure 7 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present disclosure. Figure 7 As shown, the electronic device 700 includes at least one processor 701 and a memory 702 coupled to the processor 701, which can perform the corresponding steps in the methods disclosed in the embodiments of this disclosure.

[0135] The processor 701 described above can also be called a Central Processing Unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this embodiment can be implemented by the integrated logic circuitry in the processor 701's hardware or by software instructions. The processor 701 can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in the memory 702, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor 701 reads information from the memory 702 and, in conjunction with its hardware, completes the steps of the method described above.

[0136] Furthermore, various operations / processes according to this disclosure, implemented via software and / or firmware, can be transmitted from a storage medium or network to a computer system with a dedicated hardware architecture, for example, Figure 8 The computer system 800 shown is equipped with the programs that constitute the software. When various programs are installed, the computer system is able to perform various functions, including functions such as those mentioned above. Figure 8 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure.

[0137] Computer system 800 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0138] like Figure 8 As shown, the computer system 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the computer system 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0139] Multiple components in the computer system 800 are connected to the I / O interface 805, including: an input unit 806, an output unit 807, a storage unit 808, and a communication unit 809. The input unit 806 can be any type of device capable of inputting information into the computer system 800. The input unit 806 can receive input numerical or character information and generate key signal inputs related to user settings and / or function control of the electronic device. The output unit 807 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. The storage unit 808 may include, but is not limited to, a hard disk and an optical disk. The communication unit 809 allows the computer system 800 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, a modem, network card, infrared communication device, wireless communication transceiver, and / or chipset, such as Bluetooth™ device, WiFi device, WiMax device, cellular communication device, and / or the like.

[0140] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 802 and / or communication unit 809. In some embodiments, the computing unit 801 can be configured to perform the methods disclosed in this disclosure by any other suitable means (e.g., by means of firmware).

[0141] This disclosure also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the methods disclosed in this disclosure.

[0142] The computer-readable storage medium in this disclosure can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0143] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0144] Figure 9 This is a schematic diagram of a computer program product provided according to an embodiment of the present disclosure. Figure 9 As shown, the computer program product 900 includes a computer program 901, which, when executed by a processor, implements the methods disclosed in the embodiments of this disclosure.

[0145] In embodiments of this disclosure, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The modules, components, or units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0148] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0149] The above description is merely an illustration of some embodiments of this disclosure and the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0150] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A method for managing a message queue cluster, characterized in that, include: Obtain multiple message traffic data of the target message queue cluster at different historical time steps, and predict the message traffic for the next time step based on the multiple message traffic data to obtain the predicted message traffic for the next time step. The predicted message traffic is compared with a preset message traffic threshold, and multiple scheduling decisions are generated based on the comparison results. The target message queue cluster includes multiple servers, and at least one message queue component runs on each server. The scheduling decisions are used to control at least one server to add or remove a message queue component. For each of the scheduling decisions, predict the running data of each server when the target message queue cluster executes the scheduling decision; Based on the operational data, a target scheduling decision is determined from multiple scheduling decisions; the target message queue cluster is then controlled to execute the target scheduling decision.

2. The method according to claim 1, characterized in that, The message queue component includes a first message queue component and a second message queue component, and the step of generating multiple scheduling decisions based on the comparison result includes: Based on the comparison results, multiple scheduling decisions are generated to add the first message queue component and the second message queue component to at least one of the servers; The step of determining a target scheduling decision from multiple scheduling decisions based on the operational data and executing the target scheduling decision includes: For each scheduling decision, the load status of each server at the time of executing the scheduling decision is determined based on the operating data of each server at the time of executing the scheduling decision; The target scheduling decision is determined from the plurality of scheduling decisions based on the load status of each server when each scheduling decision is executed.

3. The method according to claim 2, characterized in that, The step of determining the target scheduling decision from a plurality of scheduling decisions based on the load state of each server when executing each scheduling decision includes: Based on the load status of each server when executing each scheduling decision, the load status of the target message queue cluster when executing each scheduling decision is determined respectively; The target scheduling decision is determined from a plurality of scheduling decisions based on the load status of each server when each scheduling decision is executed and the load status of the target message queue cluster when each scheduling decision is executed.

4. The method according to claim 1, characterized in that, The method further includes: The message queue components to be removed are determined based on the scheduling decision; If a message processing task exists in the message queue component to be removed, the message processing task will be migrated to a message queue component other than the message queue component to be removed. Delete the message queue component to be removed.

5. The method according to claim 1, characterized in that, The preset message traffic threshold includes a preset expansion threshold and a preset reduction threshold, and the method includes: When the predicted message traffic is greater than or equal to the preset expansion threshold, the scheduling decision is used to control the scheduling of the newly added message queue component among the multiple servers. When the predicted message traffic is less than or equal to the preset scaling-down threshold, the scheduling decision is used to control the scheduling of the removed message queue components among the multiple servers.

6. The method according to claim 1, characterized in that, The prediction of message traffic for the next time step based on multiple message traffic flows includes: Multiple message flows are input into a target message flow prediction model to obtain the predicted message flow for the next time step; wherein, the target message flow prediction model includes a generator and a discriminator, the generator is built based on a self-attention model and is used to receive message flows from historical time steps and generate predicted message flows for the next time step, and the discriminator is used to optimize the generator.

7. A management device for a message queue cluster, characterized in that, include: The acquisition module is used to acquire multiple message flows of the target message queue cluster at different historical time steps, and predict the message flow of the next time step based on the multiple message flows to obtain the predicted message flow of the next time step. The comparison module is used to compare the predicted message traffic with a preset message traffic threshold and generate multiple scheduling decisions based on the comparison results. The target message queue cluster includes multiple servers, and each server runs at least one message queue component. The scheduling decisions are used to control at least one server to add or remove a message queue component. A determining module is configured to predict, for each of the scheduling decisions, the running data of each server when the target message queue cluster executes the scheduling decision; An execution module is used to determine a target scheduling decision from multiple scheduling decisions based on the running data; and to control the target message queue cluster to execute the target scheduling decision.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

Images