Message queue shunting method and system, electronic device and storage medium

Abstract

The invention relates to a message queue shunting method and system, an electronic device and a storage medium, and the message queue shunting method comprises the steps: determining a protocol specification of a message according to the message after the message sent by a message queue producer client is received; performing binary structured analysis on the message according to a protocol specification of the message to obtain core metadata of the message; matching the core metadata with a preset routing rule table, and determining a target message agent cluster of message routing; the preset routing rule table comprises a mapping relation between the core metadata and the message agent cluster; and routing the message to the target message proxy cluster. According to the message sending method and device, the message can be sent to the target message agent cluster in a targeted mode according to the core metadata of the message instead of being sent to all the message agent clusters, waste of system resources is avoided, and the utilization efficiency of the system resources is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software application, in particular to a message queue shunting method and system, an electronic device and a storage medium. BACKGROUND

[0002] With the rapid development of Internet applications, message queues, as an efficient asynchronous communication mechanism, have been widely used in large-scale distributed systems. RocketMQ is a high-availability, scalable distributed message middleware that usually adopts a cluster mode to achieve high reliability and high concurrency processing capability. To meet the high-availability requirement, RocketMQ uses a cluster architecture, which includes multiple Broker nodes. However, as the traffic continues to increase, the configurations and performance of each Broker node differ, and the system load has strong volatility, especially during business peak periods, the Broker nodes may face overload or unbalanced load, which will cause waste of system resources and affect the stability of services.

[0003] Currently, there are mainly two load balancing methods, one is that the RocketMQ producer client directly connects with the Broker node, and obtains the Broker list through the registration center for load balancing, this method lacks a flexible proxy layer and cannot dynamically adjust the connection strategy between the producer and the Broker node, resulting in low resource utilization efficiency of the system in the scene with large traffic fluctuations; the other is to use a reverse proxy server (such as Nginx) for load balancing, this method lacks intelligent routing capabilities at the protocol level and is difficult to dynamically adjust traffic routing, resulting in low resource utilization efficiency of the system. Therefore, the related art has the problem of low system resource utilization efficiency.

[0004] At present, there is no effective solution to the problem of low system resource utilization efficiency in the related art. SUMMARY

[0005] A message queue shunting method, system, electronic device and storage medium are provided in the present embodiment to solve the problem of low system resource utilization efficiency in the related art.

[0006] In a first aspect, a message queue shunting method is provided in the present embodiment, for a reverse proxy server; the method comprises:

[0007] After receiving a message sent by a message queue producer client, determining the protocol specification of the message according to the message;

[0008] According to the protocol specification of the message, performing binary structured parsing on the message to obtain core metadata of the message;

[0009] matching the core metadata with a preset routing rule table to determine a target message broker cluster for the message routing; the preset routing rule table contains a mapping relationship between the core metadata and the message broker cluster;

[0010] routing the message to the target message broker cluster.

[0011] In some embodiments, upon receiving a message sent by a message queue producer client, a protocol specification of the message is determined according to the message, including:

[0012] Upon receiving a message sent by a message queue producer client, a protocol type of the message is determined according to a protocol magic number of the message.

[0013] According to the protocol type, a protocol specification of the message is determined.

[0014] In some embodiments, according to the protocol specification of the message, the message is binary structured parsed to obtain core metadata of the message, including:

[0015] According to the protocol specification of the message, the message is binary structured parsed to obtain message header data of the message.

[0016] The message header data is binary structured parsed to obtain the core metadata of the message.

[0017] In some embodiments, the preset routing rule table is stored in a structure with the core metadata as a key and a routing rule as a value.

[0018] In some embodiments, matching the core metadata with a preset routing rule table to determine a target message broker cluster for the message routing includes:

[0019] Matching the core metadata with a preset routing rule table, according to the core metadata, a corresponding rule in the routing rule table is matched.

[0020] According to the rule, a target message broker cluster for the message routing is determined.

[0021] In a second aspect, a reverse proxy server is provided in the present embodiment, which is used to perform the message queue shunting method of the first aspect.

[0022] In some embodiments, the reverse proxy server includes a message receiving module, a message parsing module, a message routing decision module, and a message routing module.

[0023] The message receiving module is configured to determine a protocol specification of the message according to the message after receiving the message sent by the message queue producer client;

[0024] The message analyzing module is configured to perform binary structured analysis on the message according to the protocol specification of the message to obtain core metadata of the message;

[0025] The message routing decision module is configured to match the core metadata with a preset routing rule table to determine a target message broker cluster of the message routing;

[0026] The message routing module is configured to route the message to the target message broker cluster.

[0027] In a third aspect, a message queue distribution system is provided in the present embodiment, which comprises a message queue producer client, a reverse proxy server and a message broker cluster;

[0028] The message queue producer client is configured to send a message;

[0029] The reverse proxy server is configured to perform the message queue distribution method of the first aspect;

[0030] The message broker cluster is configured to receive the message.

[0031] In a fourth aspect, an electronic device is provided in the present embodiment, which comprises a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to perform the message queue distribution method of the first aspect.

[0032] In a fifth aspect, a computer readable storage medium is provided in the present embodiment, which stores a computer program, and the program is executed by a processor to implement the message queue distribution method of the first aspect.

[0033] Compared with the related art, the message queue shunting method, system, electronic device and storage medium are provided in the embodiment. The message queue shunting method in the embodiment comprises the following steps: after receiving a message sent by a message queue producer client, determining a protocol specification of the message according to the message; performing binary structured analysis on the message according to the protocol specification of the message to obtain core metadata of the message; matching the core metadata with a preset routing rule table to determine a target message broker cluster of the message routing; the preset routing rule table comprises a mapping relationship between the core metadata and the message broker cluster; and routing the message to the target message broker cluster. The message can be sent to the target message broker cluster according to the core metadata of the message, instead of being sent to all message broker clusters, so that the waste of system resources is avoided, and the utilization efficiency of system resources is improved.

[0034] The details of one or more embodiments of the present application are presented in the following drawings and description to make other features, objects and advantages of the present application more clear and easy to understand. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate the illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings:

[0036] Figure 1 is a terminal hardware structure block diagram of the message queue shunting method of the embodiment;

[0037] Figure 2 is a flowchart of the message queue shunting method of the embodiment;

[0038] Figure 3 is a reverse proxy server structure block diagram of the message queue shunting method of the embodiment;

[0039] Figure 4 is a structure block diagram of the message queue shunting system of the embodiment;

[0040] Figure 5 is a data flow conversion schematic diagram of the message queue shunting of some embodiments. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical scheme and advantages of the present application more clear, the present application is described and explained below in combination with the drawings and embodiments.

[0042] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0043] The method embodiments provided in this example can be executed on a terminal, computer, or similar electronic device with a certain computing power. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal for the message queue splitting method in this embodiment. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0044] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the message queue routing method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0046] This embodiment provides a message queue routing method for a reverse proxy server; Figure 2 This is a flowchart of the message queue splitting method in this embodiment, as follows: Figure 2 As shown, the process includes the following steps:

[0047] Step S210: After receiving a message sent by the message queue producer client, determine the message protocol specification based on the message.

[0048] The message queue producer client is the component in a distributed system responsible for sending messages to the message queue. This message queue producer client can be a RocketMQ producer client. The reverse proxy server can be an Nginx server. This protocol specification defines the message structure, message encoding method, and message transmission protocol. The message structure includes a message header and a message body; message encoding methods include text format and binary format; and message transmission protocols include Transmission Control Protocol (TCP) and Hypertext Transfer Protocol (HTTP).

[0049] Specifically, after the message queue producer client establishes a Transmission Control Protocol (TCP) connection with the reverse proxy server, the message queue producer client sends a message to the reverse proxy server. Upon receiving the message, the reverse proxy server determines the protocol specification of the message based on the received message.

[0050] Step S220: According to the message protocol specification, perform binary structured parsing on the message to obtain the core metadata of the message.

[0051] The protocol specification can be the RocketMQ protocol specification; the core metadata can include topic data length, topic data content, etc. Specifically, the reverse proxy server performs structured parsing on the raw binary data of the message according to the message protocol specification to obtain the message's core metadata. Structured parsing involves dividing the raw binary data of the message into structural parts according to the protocol specification and converting them into corresponding information. This corresponding information includes the message's core metadata.

[0052] Step S230: Match the core metadata with the preset routing rule table to determine the target message broker cluster for message routing.

[0053] The preset routing rule table contains the mapping relationship between core metadata and message broker clusters. These message broker clusters are used to store and forward messages. Specifically, the reverse proxy server matches the core metadata with the preset routing rule table to determine the target message broker cluster for message routing.

[0054] Step S240: Route the message to the target message broker cluster.

[0055] Specifically, the reverse proxy server re-injects the messages sent by the message queue producer client into the Transmission Control Protocol (TCP) data stream and routes them to the target message broker cluster, thus achieving semantic-level routing.

[0056] By employing steps S210 to S240 above, and comparing with related technologies, this application, upon receiving a message sent by a message queue producer client, determines the message's protocol specification based on the message; performs binary structured parsing of the message according to the protocol specification to obtain the message's core metadata; matches the core metadata with a preset routing rule table to determine the target message broker cluster for message routing; the preset routing rule table contains the mapping relationship between the core metadata and message broker clusters; and routes the message to the target message broker cluster. This allows the message to be sent selectively to the target message broker cluster based on its core metadata, rather than to all message broker clusters, thus avoiding waste of system resources and improving system resource utilization efficiency.

[0057] In one embodiment, after receiving a message sent by the message queue producer client, the protocol specification of the message is determined based on the message, including:

[0058] After receiving a message from the message queue producer client, the protocol type of the message is determined based on the message's protocol magic number; and the protocol specification of the message is determined based on the protocol type.

[0059] The protocol magic number, located at the beginning of the message and occupying 4 bytes, is used to identify the message's protocol type. Specifically, after receiving a message from the message queue producer client, the reverse proxy server reads the first 4 bytes of data (the protocol magic number) and matches it against a pre-defined protocol type table to determine the message's protocol type. This protocol type table contains a mapping relationship between protocol magic numbers and protocol types. For example, if the first 4 bytes of data read are 0xCAFEBABE, the protocol magic number is matched against the protocol type table, determining the message's protocol type to be RocketMQ. The message's protocol magic number can be used to determine the message's protocol specification and verify its validity. If the message's protocol magic number does not match the pre-defined protocol type table, the message is considered invalid. If the message's protocol magic number matches the pre-defined protocol type table, the message's protocol specification is determined based on the matched protocol type.

[0060] In one embodiment, the message is parsed in binary structure according to the message protocol specification to obtain the message's core metadata, including:

[0061] According to the message protocol specification, the message is parsed in binary structure to obtain the message header data; the message header data is then parsed in binary structure to obtain the core metadata of the message.

[0062] Specifically, according to the message's protocol specification, the start position and length of the message header data can be obtained. Therefore, the message can be parsed using binary structure to extract the message header data. For example, if the message's protocol specification is RocketMQ, the start position of the message header data is the 5th byte, and the following 3 bytes represent the message header data length. The message header data can then be extracted. Based on the field offsets defined in the message's protocol specification, the message header is parsed using big-endian encoding to extract core metadata fields such as the subject data length and subject data content. For example, if the message's protocol specification is RocketMQ, after extracting the message header data, binary structure parsing can be performed to obtain the message's core metadata. For instance, the first 4 bytes of the message header data represent the subject data length, and the last 4 bytes represent the subject data content. Based on the subject data length, the complete subject data content can be extracted, such as "ORDER". During the parsing process, the system parses byte-by-byte according to the field order and length defined in the protocol specification. After each field is parsed, data type verification and boundary checks are performed to ensure the accuracy and security of the parsing results. In case of anomalies such as magic number mismatch or field length exceeding the expected range, the parsing module terminates the current connection and logs errors to prevent illegal data from entering subsequent processing flows, providing reliable data protection for subsequent processes. Messages are parsed directly at the transport layer without application layer intervention, and big-endian encoding is used to ensure parsing accuracy.

[0063] In one embodiment, the preset routing rule table is stored in a structure with core metadata as the key and routing rules as the value.

[0064] Specifically, when the reverse proxy server starts, it initializes the shared memory dictionary and loads a pre-defined routing rule table. This pre-defined routing rule table is stored in a structure where core metadata is the key and routing rules are the values. For example, the routing rule corresponding to topic data is: {"ORDER"}. ":"broker_order","PAYMENT. The routing rule table supports a runtime hot update mechanism, allowing dynamic updates via the management interface when routing rules change without requiring a restart of the reverse proxy service. This routing rule table uses a wildcard pattern matching design and supports... Flexible routing rule definitions, such as "and" and "?", enable fine-grained message routing strategies based on business needs.

[0065] In one embodiment, matching core metadata with a preset routing rule table to determine the target message broker cluster for message routing includes:

[0066] The core metadata is matched against a preset routing rule table. Based on the core metadata, the corresponding rule in the routing rule table is matched. Based on the rule, the target message broker cluster for message routing is determined.

[0067] Specifically, the core metadata is matched against a pre-defined routing rule table using a topic-based rule matching algorithm. Based on the core metadata, the corresponding rule in the routing rule table is found. For example, the pre-defined routing rule table is: {"ORDER";} ":"broker_order","PAYMENT. ":"broker_payment"}, based on the core metadata of the message, such as: the subject data content is ORDER, the corresponding rule in the routing rule table is {"ORDER". The matching result is logged in real time, including the matched topic data content, routing rules, and target cluster, facilitating subsequent monitoring and analysis. This matching mechanism ensures efficient routing decisions while enabling flexible routing strategy configuration through the topic rule matching algorithm. Based on the matched routing rule, the target message broker cluster for the message route is determined. For example, if the matched routing rule is {"ORDER"}. The message routing is defined by the string "broker_order"}, thus identifying the target message broker cluster as "broker_order". Each message broker cluster defines backend server nodes and supports load balancing algorithm configuration to ensure that requests are distributed reasonably among cluster nodes. Routing is performed directly to the target message broker cluster based on the matching rules, requiring no changes to the application layer to make the routing effective, bypassing traditional application-layer proxies.

[0068] This embodiment also provides a reverse proxy server 30, such as Figure 3 As shown, the reverse proxy server 30 is used to execute the message queue routing method provided in any of the above embodiments. This reverse proxy server 30 can identify the core metadata of messages sent by message queue producer clients, and based on this core metadata and a preset routing rule table, match the corresponding routing rule to route the message to the target message broker cluster. By selectively sending messages to the target message broker cluster, instead of sending them to all message broker clusters, system resource waste is avoided, and system resource utilization efficiency is improved.

[0069] In one embodiment, the reverse proxy server 30 includes a message receiving module 301, a message parsing module 302, a message routing decision module 303, and a message routing module 304. The message receiving module 301, upon receiving a message sent by a message queue producer client, determines the protocol specification of the message based on the message. The message parsing module 302 performs binary structured parsing of the message according to the protocol specification to obtain the message's core metadata. The message routing decision module 303 matches the core metadata with a preset routing rule table to determine the target message broker cluster for message routing. The message routing module 304 routes the message to the target message broker cluster.

[0070] This embodiment also provides a message queue routing system 40, such as Figure 4 As shown, the message queue distribution system includes a message queue producer client 41, a message broker cluster 42, and a reverse proxy server 30 provided in the above embodiments. The message queue producer client 41 is used to send messages; the message broker cluster 42 is used to receive messages; and the reverse proxy server 30 is used to execute the steps in any of the above method embodiments.

[0071] In this embodiment, after receiving a message sent by the message queue producer client 41 through the reverse proxy server 30, the protocol specification of the message is determined based on the message. According to the message protocol specification, the message is parsed using binary structured parsing to obtain the core metadata of the message. The core metadata is matched with a preset routing rule table to determine the target message broker cluster 42 for message routing. The preset routing rule table contains the mapping relationship between the core metadata and the message broker cluster 42. The message is then routed to the target message broker cluster 42. This allows the message to be sent selectively to the target message broker cluster 42 based on its core metadata, rather than to all message broker clusters 42, thus avoiding waste of system resources and improving the efficiency of system resource utilization.

[0072] In one embodiment, Figure 5 These are schematic diagrams illustrating the data flow of message queue splitting in some embodiments, such as... Figure 5 As shown, the process includes the following steps:

[0073] After establishing a Transmission Control Protocol (TCP) connection with the reverse proxy server 30, the message queue producer client 41 sends a message to the reverse proxy server 30. Upon receiving the message, the reverse proxy server 30 determines the protocol type of the message based on the received message.

[0074] The reverse proxy server 30 determines the message protocol specification based on the message's protocol type. According to the message protocol specification, it reads the message header data. Then, according to the message protocol specification, it performs binary structured parsing on the message header data to extract the core metadata of the message. When packet fragmentation occurs, it performs packet fragmentation processing and waits to receive subsequent data.

[0075] The reverse proxy server 30 performs field type determination on the core metadata of the message. When the field type is determined to be topic data, the topic data is matched against the preset routing rule table, and the target message proxy cluster 42 is determined by combining this with the status information of the message proxy cluster 42 provided by the name server. If there is no corresponding matching rule in the preset routing rule table, the default load balancing algorithm is used to determine the target message proxy cluster 42.

[0076] The reverse proxy server 30 re-injects the message into the Transmission Control Protocol (TCP) data stream, keeping the field order and content of the original data unchanged, ensuring the integrity and consistency of data transmission, and routes it to the target message broker cluster 42.

[0077] During this process, the reverse proxy server 30 and the message broker cluster 42 maintain their connection through heartbeat responses.

[0078] This embodiment also provides an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0079] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0080] S1, after receiving a message sent by the message queue producer client, determines the message protocol specification based on the message;

[0081] S2, according to the message protocol specification, performs binary structured parsing of the message to obtain the core metadata of the message;

[0082] S3 matches the core metadata with the preset routing rule table to determine the target message broker cluster for message routing; the preset routing rule table contains the mapping relationship between the core metadata and the message broker cluster.

[0083] S4 routes the message to the target message broker cluster.

[0084] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0085] Furthermore, in conjunction with the message queue splitting method provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the message queue splitting methods described in the above embodiments.

[0086] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0087] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0088] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0089] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0090] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A message queue splitting method, characterized in that, For use as a reverse proxy server; the method includes: After receiving a message sent by the message queue producer client, the protocol specification of the message is determined based on the message. According to the protocol specification of the message, the message is parsed in binary structure to obtain the core metadata of the message; The core metadata is matched with a preset routing rule table to determine the target message broker cluster for the message; the preset routing rule table contains the mapping relationship between the core metadata and the message broker cluster. The message is forwarded to the target message broker cluster.

2. The message queue splitting method according to claim 1, characterized in that, Upon receiving a message from the message queue producer client, the protocol specification of the message is determined based on the message, including: After receiving a message sent by the message queue producer client, the protocol type of the message is determined according to the protocol magic number of the message; The protocol specification of the message is determined based on the protocol type.

3. The message queue splitting method according to claim 1, characterized in that, According to the protocol specification of the message, the message is parsed using binary structured parsing to obtain the core metadata of the message, including: According to the protocol specification of the message, the message is parsed in binary structure to obtain the message header data; The message header data is parsed using binary structure to obtain the core metadata of the message.

4. The message queue splitting method according to claim 1, characterized in that, The preset routing rule table is stored in a structure where the core metadata is the key and the routing rule is the value.

5. The message queue splitting method according to claim 1, characterized in that, Matching the core metadata with a preset routing rule table to determine the target message broker cluster for the message includes: The core metadata is matched with a preset routing rule table, and the corresponding rule in the routing rule table is matched according to the core metadata. Based on the rules, the target message broker cluster for the message is determined.

6. A reverse proxy server, characterized in that, Used to perform the message queue splitting method according to any one of claims 1 to 5.

7. The reverse proxy server according to claim 6, characterized in that, The reverse proxy server includes a message receiving module, a message parsing module, a message routing decision module, and a message routing module; The message receiving module is used to determine the protocol specification of the message based on the message after receiving a message sent by the message queue producer client; The message parsing module is used to perform binary structured parsing of the message according to the message's protocol specifications to obtain the message's core metadata; The message routing decision module is used to match the core metadata with a preset routing rule table to determine the target message broker cluster for the message route; The message routing module is used to route the message to the target message broker cluster.

8. A message queue routing system, characterized in that, This includes message queue producer clients, reverse proxy servers, and message broker clusters. The message queue producer client is used to send messages; The reverse proxy server is used to execute the message queue splitting method according to any one of claims 1 to 5; The message broker cluster is used to receive the messages.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the message queue splitting method according to any one of claims 1 to 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the message queue splitting method according to any one of claims 1 to 5.

Images