Message center system and message queue management method thereof

Abstract

The invention discloses a message center system and a message queue management method thereof, and the method comprises the steps: S1, detecting a load condition of a message system and a node operation state, and enabling the system to select an optimal node route according to an actual condition to transmit a message to a target node; s2, the message system judges the priority of the message and judges other personalized rules of the message, the message is classified and written into a message queue, and the message queue distributes the message to a target node; s3, the monitoring system detects system changes, automatically adjusts other rule configurations of the message center, evaluates system or node performance, and reversely writes the configurations to the rule configurations of the message center; and S4, in the whole life cycle from message receiving to message distribution, a monitoring center of the message system automatically and asynchronously monitors and analyzes message traffic, system performance and performance problems. By improving message routing, queue management and real-time monitoring, a more efficient and reliable message transmission mechanism is provided for a large-scale system.

Description

Technical Field

[0001] The present invention relates to the field of message routing algorithms, and in particular to a message center system and a message queue management method thereof. Background Art

[0002] In large-scale systems, the message center plays a key role in carrying and distributing messages. Current message center systems have some challenges in message routing, queue management, and real-time monitoring, including: (1) Message Routing Challenges Complexity: As business grows and the number of message types increases, the complexity of message routing is also increasing. The system needs to accurately determine the destination address of each message and ensure that the message can be correctly delivered along the preset path.

[0003] Routing strategy selection: Different routing strategies may be suitable for different business scenarios. Improper selection may lead to inefficient message delivery or errors. The system needs to flexibly adjust the routing strategy according to actual conditions.

[0004] Load balancing: When the amount of messages is large, how to reasonably distribute the messages to different processing nodes to avoid overloading some nodes while other nodes are idle is an important challenge.

[0005] (2) Queue management challenges Queue length control: When the number of messages surges, the queue length may grow rapidly, causing message processing delays. The system needs to effectively control the queue length to ensure that messages can be processed in a timely manner.

[0006] Priority management: For messages of different importance, the system needs to set different priorities to ensure that important messages are processed first. How to reasonably set priorities and avoid priority inversion is a problem that needs to be solved.

[0007] Queue stability: During system operation, the stability of the queue is crucial to the delivery of messages. Any problems that may cause queue crashes or message loss need to be properly resolved.

[0008] (3) Real-time monitoring challenges Monitoring indicator selection: In order to fully understand the operating status of the system, it is necessary to select appropriate monitoring indicators for real-time collection and analysis. Too many monitoring indicators may lead to information redundancy and difficulty in analysis, while too few monitoring indicators may not accurately reflect the actual status of the system.

[0009] Data processing and analysis: The large amount of data generated by real-time monitoring needs to be effectively processed and analyzed to identify potential problems and bottlenecks. The complexity of data processing and analysis may lead to inaccurate or delayed analysis results.

[0010] Alarm and response: When an abnormal situation is found, the system needs to issue an alarm in time and take corresponding response measures. How to set a reasonable alarm threshold and how to ensure the accuracy and timeliness of the alarm is a problem that needs to be solved. Summary of the invention

[0011] The present invention provides a message center system and a message queue management method thereof. The present invention provides a more efficient and reliable message transmission mechanism for a large system by improving message routing, queue management and real-time monitoring.

[0012] The technical solutions to the above technical problems are as follows: A message center system and a message queue management method thereof, after receiving a message, comprising the following steps: S1, detects the message system load and node operation status, and the system selects the optimal node route to transmit the message to the target node according to the actual situation; S2: The message system determines the message priority and other personalized rules, writes the message into the message queue after classification, and dispatches the message to the target node by the message queue; S3, the monitoring system detects system changes, automatically adjusts other rule configurations of the message center, evaluates system or node performance, and writes the configuration back to the message center rule configuration; S4, during the entire life cycle from receiving a message to dispatching it, the monitoring center of the message system automatically and asynchronously monitors and analyzes the message traffic, system performance, and performance issues, and automatically sends alarm information to ensure the stable operation of the message system.

[0013] The message routing algorithm of the present invention can quickly and accurately deliver messages to target nodes according to dynamic factors such as system load and node status; it proposes an innovative message queue management method to ensure that messages are arranged and distributed according to priority, sequence or other specific rules; it also has the ability to monitor message flows in real time to detect and solve potential performance problems; it sets message rules in the message center, and when system changes are detected, the message rules automatically adjust the configuration according to the actual situation to dynamically adjust the message dispatch in real time. By improving message routing, queue management and real-time monitoring, a more efficient and reliable message delivery mechanism is provided for large systems.

[0014] In order to solve the problems of low message transmission efficiency in traditional application systems, the inability to elevate the authority to send important messages, resulting in delays in important messages or failure to be correctly received by the recipient, the present invention provides an efficient message center system, particularly a message queue management method, which aims to improve the efficiency and reliability of message transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a structural diagram of a message center system and its message queue management method.

[0016] Figure 2 Flowchart of the message routing algorithm provided for this application.

[0017] Figure 3 Message queue management flow chart provided for this application.

[0018] Figure 4 Flowchart of the real-time monitoring mechanism provided for this application.

[0019] Figure 5 Flowchart of the adaptive optimization algorithm provided for this application. DETAILED DESCRIPTION

[0020] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0021] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0022] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the main purpose of the present disclosure.

[0023] like Figures 1 to 5 The message center system and message queue management method of the present invention, after receiving a message, include the following steps: S1, detects the message system load and node operation status, and the system selects the optimal node route to transmit the message to the target node based on the actual situation.

[0024] like Figure 2 As shown in the figure, after receiving the message, the system load is detected first. Conventional detection methods require interaction with specific nodes, such as sending requests and waiting for responses. In scenarios with high pressure, such interactions will consume more resources. If a node has been under a lot of pressure, the node will be unable to handle the query at this time. Therefore, the current solution does not adopt this interaction method, but maintains a pressure value on the gateway side and calculates the "distance" of the node, so as to realize the selection of nodes and the dispatch of messages. The specific algorithm is described as follows: The gateway detects the message system load and node operation status, calculates the distance from the gateway to the message center, and selects the best path for message delivery, including the following processes: Calculate the actual load of the target node for message dispatching.

[0025] Calculates the running status of the specified node that distributes data.

[0026] Calculate the distance from the gateway to the message center.

[0027] Choose the best path to deliver the message to the destination node.

[0028] The operation process of calculating the actual load of the target node for message dispatching and the node operation status is as follows: A counter is maintained on the gateway to calculate the actual load of the target node for each message dispatch.

[0029] The gateway can know which node each message is dispatched to and how long the request takes to return the data, thereby determining whether the designated node to which the data is dispatched is intact.

[0030] The distance calculation between the gateway and the distributed data node includes: The time from sending a request to getting a response is called distance. If it takes 1 second, it means that the distance from the gateway to the message center is 500 milliseconds.

[0031] If a node is damaged or disconnected, it will not respond, and a timeout will occur at the gateway. The gateway will then send a very small number of messages to the node, and when the response times out, add a mechanism to resend to other nodes. Once the damaged or disconnected node responds and the response distance is short, it can be determined that the node has recovered.

[0032] The process of selecting the best path to deliver the message to the target node is as follows: by calculating the distance from the gateway to the dispatched data node, setting the shortest distance first, and ensuring that the message is delivered to the target node via the best path.

[0033] 1. By judging the load through the gateway, the gateway can clearly know which node a request is sent to and how long it takes for the request to return data. Based on this, we can know whether the designated node to which the data is sent is intact and the "distance" of the node to which the data is sent. The description of "distance" here is not the physical distance, but the request distance. For example, it takes 1 second from sending a request to getting a response, so we say that the "distance" from the gateway to the message center is 500 milliseconds.

[0034] 2. Since the gateway knows how many messages have been sent to each node and how many responses each node has given, it only needs to maintain a counter in the gateway to know the actual load of each node. As the pressure on the node increases, its response speed will slow down, which is reflected in the phenomenon of increased "distance". Therefore, when the gateway sends messages, it will not send them to "further" nodes.

[0035] 3. If a specific node is damaged or disconnected, it will not be able to respond, and a timeout will occur at the gateway. The gateway will then send a very small number of messages to the node and prepare a mechanism to resend the message to other nodes when the timeout occurs (this step ensures that the message is not lost). Once the damaged or disconnected node responds and the response "distance" is very short, it can be determined that the node has recovered.

[0036] Based on the above algorithm, a specific implementation example is that node 1 currently has a load of 100 requests (the count is maintained by the gateway), and the last response time (i.e., distance) of node 1 is 300ms, then the load factor is calculated as (100K1)・(300K2 / 2).

[0037] Node 2 currently has a load of 1000 requests, and the last response time of Node 2 is 800ms. It can be seen that the current load of Node 2 is a bit large, and the load factor is (1000K1)・(800K2 / 2).

[0038] At this point, it is obvious that the next message should be sent to node 1, not node 2. Under this condition, K1 and K2 as actual configured weight parameters can be adjusted to suit actual usage.

[0039] In the above scenario, messages are continuously sent to node 1 until one moment, the accumulated request load of node 1 is 1000, and the last response time of node 1 is 1 second, which means that node 1 is "farther" than node 2, and subsequent requests will be more likely to be sent to node 2.

[0040] S2, the message system determines the message priority and other personalized rules of the message, writes it into the message queue after classification, and the message queue dispatches the message to the target node. The operation process of S2 is as follows: Message priority management is achieved through a custom script engine.

[0041] The message queue dynamically adjusts the message order according to the rules and dispatches them to the target node.

[0042] The process of implementing message priority management through a custom script engine is as follows: When a message is sent, a special field is added to the message. The special field is automatically generated by the configured rules and directly compiled into bytecode by the embedded compiler.

[0043] The message queue executes the bytecode carried by the message and sorts the messages according to the execution results, in accordance with the conventional first-in-first-out principle. It also supports dynamic adjustment of the order of messages and allows specific messages to jump the queue.

[0044] The special field code has almost no effect on the transmission of the message body over the network (the bytecode compiled by the Kotlin embedded compiler is exactly the same as the Java bytecode. The reason for using Kotlin is that Kotlin code is more concise, the cost of generating code is lower, and it is less prone to errors).

[0045] When a message is sent to the gateway, it will be given priority to enter the message queue. The implementation of the message queue is first-in-first-out, but it is not the traditional first-in-first-out. The message queue will execute the bytecode carried by the message and sort the messages according to the execution results (because the bytecode is pre-compiled, there is only execution cost on the gateway side, and the compilation cost is allocated to each node that sends the message. The execution performance of the bytecode is very high and it can be considered that it has no impact on the overall performance). For example, if the priority of the message is very urgent, the message will be placed at the front of the queue at any time. Or, after the bytecode is executed, it is learned that the recipient of the message includes an important leader, then the message will also be placed at the front of the queue to obtain a higher dispatch priority.

[0046] The implementation of the message queue complies with the conventional first-in-first-out principle, but also supports dynamic adjustment of the order of messages and allows specific messages to jump the queue.

[0047] S3, the monitoring system detects system changes, automatically adjusts other rule configurations of the message center, evaluates system or node performance, and writes the configuration back to the message center rule configuration. The operation process of S3 is as follows: Monitor the operation of the messaging system and evaluate its performance.

[0048] Set up a set of rules in the message center to adjust the message distribution according to the actual situation of the system.

[0049] The operation process of monitoring the operation of the message system and evaluating its performance is as follows: Build a message system monitoring system. For different monitoring items, the monitoring system uses different methods to collect data. The traffic is monitored by mounting a listener on the network card. The real-time performance is achieved by enabling the monitoring tool on the JVM (JVM is a specification for computing devices. It is a fictional computer that simulates various computer functions on an actual computer).

[0050] The actual operation of the system includes but is not limited to the current load of the system, the distance and load of nodes within the cluster, the number of nodes, and the damage of the nodes.

[0051] S4, during the entire life cycle from receiving a message to dispatching it, the monitoring center of the message system automatically and asynchronously monitors and analyzes the message traffic, system performance, and performance issues, and automatically sends alarm information to ensure the stable operation of the message system. The operation process of S4 is as follows: After the monitoring system collects data, it analyzes whether there is a problem with the current node performance through the data. The analysis dimensions include but are not limited to memory usage, network load, request accumulation, request response time, and 415 fuse quantity; The monitoring system monitors the message itself, including: a) Malicious message sending, such as sending a large number of repeated messages in a short period of time; b) The message contains illegal information; c) The script bytecode carried in the message contains dangerous executable content.

[0052] like Figure 4 As shown in the figure, the monitoring system is independent of the message and runs in real time. For the monitored items, the monitoring system will use different methods to collect data. For example, for traffic, the monitoring system will directly monitor the traffic of the network card and obtain relevant data by mounting a listener.

[0053] After the data is collected, an independent coroutine is used in the background to process the relevant data. These data are used to analyze whether there are any performance issues. The analysis dimensions include but are not limited to memory usage, network load, request accumulation, request response time, 415 fuse volume, etc.

[0054] From receiving a message to triggering data collection in the monitoring system, information collection is not performed every time a message is received. However, when a message is received, a mark will be written to a specific flag, and active collection will be performed only when the system is idle. The information collected by a normal listener is passive information. When the data changes, the listener notifies the program and holds the data.

[0055] Since the information carried by the message itself includes the message content and the rule script bytecode, the message itself can also be monitored. After receiving the message, in addition to writing a flag to trigger system information collection, the message itself can also be monitored, including but not limited to a) malicious message sending, such as sending a large number of repeated messages in a short period of time; b) the message content contains illegal information; c) the script bytecode carried by the message contains dangerous executable content. In order to avoid the monitoring system's too frequent operation affecting the performance of the system itself, all monitoring is performed asynchronously and will be run when the system is idle as much as possible.

[0056] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A message center system and a message queue management method thereof, characterized in that: After receiving the message, the following steps are included: S1, detects the message system load and node operation status, and the system selects the optimal node route to transmit the message to the target node according to the actual situation; S2: The message system determines the message priority and other personalized rules, writes the message into the message queue after classification, and dispatches the message to the target node by the message queue; S3, the monitoring system detects system changes, automatically adjusts other rule configurations of the message center, evaluates system or node performance, and writes the configuration back to the message center rule configuration; S4, during the entire life cycle from receiving a message to dispatching it, the monitoring center of the message system automatically and asynchronously monitors and analyzes the message traffic, system performance, and performance issues, and automatically sends alarm information to ensure the stable operation of the message system.

2. The message center system and message queue management method thereof according to claim 1, characterized in that: In S1, the gateway detects the message system load and node operation status, calculates the distance from the gateway to the message center, and selects the best path for message delivery, including the following process: Calculate the actual load of the target node to which the message is dispatched; Calculate the running status of the specified node to distribute data; Calculate the distance from the gateway to the message center; Choose the best path to deliver the message to the destination node.

3. The message center system and message queue management method thereof according to claim 2, characterized in that: The operation process of calculating the actual load of the target node for message dispatching and the node operation status is as follows: Maintain a counter on the gateway to calculate the actual load of the target node for each message dispatch; The gateway can know which node each message is dispatched to and how long the request takes to return the data, thereby determining whether the designated node to which the data is dispatched is intact.

4. The message center system and message queue management method thereof according to claim 2, characterized in that: The distance calculation between the gateway and the distributed data node includes: The time from sending a request to getting a response is called distance. If it takes 1 second, it means the distance from the gateway to the message center is 500 milliseconds. If a node is damaged or disconnected, it will not respond, and a timeout will occur at the gateway. The gateway will then send a very small number of messages to the node, and when the response times out, add a mechanism to resend to other nodes. Once the damaged or disconnected node responds and the response distance is short, it can be determined that the node has recovered.

5. The message center system and message queue management method thereof according to claim 2, characterized in that: The process of selecting the best path to deliver the message to the target node is as follows: by calculating the distance from the gateway to the dispatched data node, setting the shortest distance first, and ensuring that the message is delivered to the target node via the best path.

6. The message center system and message queue management method thereof according to claim 1, characterized in that: The operation process of S2 is: Implement message priority management through a custom script engine; The message queue dynamically adjusts the message order according to the rules and dispatches them to the target node.

7. The message center system and message queue management method thereof according to claim 6, characterized in that: The process of implementing message priority management through a custom script engine is as follows: When a message is sent, a special field is added to the message. This special field is automatically generated by the configured rules and directly compiled into bytecode by the embedded compiler. The message queue executes the bytecode carried by the message and sorts the messages according to the execution results, in accordance with the conventional first-in-first-out principle. It also supports dynamic adjustment of the order of messages and allows specific messages to jump the queue.

8. The message center system and message queue management method thereof according to claim 1, characterized in that: The operation process of S3 is as follows: Monitor the operation of the message system and evaluate its performance; Set up a set of rules in the message center to adjust the message distribution according to the actual situation of the system.

9. The message center system and message queue management method thereof according to claim 8, characterized in that: The operation process of monitoring the operation of the message system and evaluating its performance is as follows: Build a message system monitoring system. For different monitoring items, the monitoring system uses different methods to collect data. The traffic is monitored by mounting a listener to monitor the traffic of the network card. The real-time performance is achieved by enabling the monitoring tool for the JVM. The actual operation of the system includes but is not limited to the current load of the system, the distance and load of nodes within the cluster, the number of nodes, the damage of nodes, etc.

10. The message center system and message queue management method thereof according to claim 1, characterized in that: The operation process of S4 is as follows: After the monitoring system collects data, it analyzes whether there is a problem with the current node performance through the data. The analysis dimensions include but are not limited to memory usage, network load, request accumulation, request response time, and 415 fuse quantity; The monitoring system monitors the message itself, including: a) Malicious message sending, such as sending a large number of repeated messages in a short period of time; b) The message contains illegal information; c) The script bytecode carried in the message contains dangerous executable content.

Images