Method and system for constructing MQTT multi-cluster capable of being arbitrarily expanded based on controllable dynamic routing
By introducing a device management service module, an MQTT cluster IP manager, and a reverse proxy gateway, the problem of the MQTT broker project's inability to infinitely expand the cluster was solved, enabling devices to reach a specified MQTT cluster node with a single connection, thus improving the system's scalability and reliability.
Patent Information
- Application Number
- CN202411148711.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-21
- Publication Date
- 2025-01-07
AI Technical Summary
Existing MQTT broker projects cannot infinitely expand cluster capabilities. Connecting devices to multiple clusters requires custom development, which cannot be handled by existing devices. Furthermore, devices need to make two connections to connect to a specific MQTT broker, leading to increased network overhead and connection randomness issues.
The system introduces a device management service module, an MQTT cluster IP manager, a device routing storage module, and an MQTT reverse proxy gateway. These modules and gateways enable seamless device expansion and precise routing, ensuring that devices can reach the specified MQTT cluster node with a single connection. Efficient routing is achieved using hash algorithms and triple matching.
It enables seamless expansion of MQTT multiple clusters, reduces equipment modification and network pressure, ensures connection reliability and data consistency, and improves user experience.
Smart Images

Figure CN119276868A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of communication technology, and in particular to a construction method and system for arbitrarily extending MQTT multi-clusters based on controllable dynamic routing. Background Art
[0002] Currently, IoT applications have become a new growth point after the Internet, and the lightweight, simple, and open features of the MQTT protocol make MQTT an important protocol in the IoT protocol. Currently, many IoT devices are connected to MQTT brokers through the MQTT protocol, and then receive device reported data through applications connected to these MQTT brokers, and remotely manage and control these devices. In the entire application chain, the ability of MQTT broker is also the most important link, and correspondingly many MQTT broker open source or closed source projects have also emerged, including relatively professional projects such as mosquitto, emqx, hiveMQ, VerneMQ, and projects with MQTT broker capabilities such as ActiveMQ and rabbitMQ.
[0003] Some of these MQTT broker projects support clustering capabilities, while others do not. However, even for projects that support clustering capabilities, the cluster carrying capacity cannot be increased by infinitely increasing the number of nodes in a single cluster. If multiple independent EMQ X clusters are simply placed behind the same TCP load balancer and the same domain name or IP is exposed to the outside world, the cluster to which the MQTT client connects will be random. When other clients need to communicate with this client, they need to first determine the cluster to which it belongs.
[0004] To solve this problem, the industry has also developed some technologies. For example, the technology used in CN114615277A is: the device connects to the default cluster for the first time, and the default cluster sends the cluster information of the secondary connection. The device receives the information, disconnects from the default cluster, and uses the received information to reconnect to the specified cluster. However, this method has two problems: (1) The device needs to be customized and developed specifically for this capability, which is powerless for existing devices that do not support this function; (2) The device needs to connect twice to connect to the specified MQTT broker, which increases network overhead and pressure. Summary of the invention
[0005] In view of the above-mentioned technical deficiencies, the technical problem to be solved by the present invention is to provide a construction method and system for arbitrarily expanding MQTT multi-clusters based on controllable dynamic routing, aiming to solve the problems that the cluster capabilities of the current MQTT broker project cannot be infinitely expanded, the device connection to the MQTT broker multi-cluster requires customized development, and the existing devices cannot be processed. The device needs to connect twice to connect to the specified MQTT broker, and the use of TCP load balancing causes the random nodes of the cluster connected to the MQTT client to be random.
[0006] In order to solve the above technical problems, the present invention adopts the following technical solution: The present invention provides a construction system for arbitrarily expanding MQTT multi-cluster based on controllable dynamic routing, including:
[0007] The device management service module is used to assign a MQTT cluster to a device and write the MQTT cluster information to which the device belongs into the device routing storage module;
[0008] MQTT cluster IP manager, used to manage and maintain the MQTT cluster list and the node IP list of each MQTT cluster, and write this information into the device routing storage module;
[0009] The device routing storage module is used to store information from the device management service module and the MQTT cluster IP manager;
[0010] The MQTT reverse proxy gateway is used as a unified entry point for device access. When a device is connected, it parses the connection request message and reads the MQTT cluster to which the device should be connected in the device routing storage module. It also proxies the device's connection request and forwards it to the correct MQTT cluster node.
[0011] Furthermore, a TCP load balancing gateway is used as the MQTT reverse proxy gateway.
[0012] Furthermore, the MQTT cluster information to which the device belongs includes: a route from the device to a specified MQTT cluster, and a route from the device to a specific node in the specified MQTT cluster.
[0013] Furthermore, managing and maintaining the MQTT cluster list and the node IP list of each MQTT cluster, and writing this information into the device routing storage module includes:
[0014] Configure the new EMQX Cluster name and access URL;
[0015] Read MQTT cluster information from each EMQX Cluster regularly;
[0016] Parse the IP information of each node in the MQTT cluster;
[0017] Write the IP information of each node in the MQTT cluster into the device routing storage module.
[0018] Further, after receiving a TCP message at a specific port, the MQTT reverse proxy gateway determines whether it is an MQTT connection request message;
[0019] If so, parse the username-password-client id triple in the MQTT connection request message, and assign the MQTT cluster to which the device belongs based on the device that matches the partial information or combined information of the triple;
[0020] If the device is connected for the first time, the device is assigned to connect to one of the nodes in the MQTT cluster to which it belongs.
[0021] If the device is not connecting for the first time and the original node is still in the MQTT cluster to which it belongs, connect to the original node.
[0022] Furthermore, when the device is connected, parsing the connection request message and reading the MQTT cluster to which the device should be connected in the device routing storage module, and proxying the device's connection request and forwarding it to the correct MQTT cluster node include:
[0023] 11) The device connects to the MQTT reverse proxy gateway;
[0024] 12) MQTT reverse proxy gateway custom plug-in handles new connection access;
[0025] 13) According to the MQTT protocol connection request, read the first byte of the message from the data transmission interface;
[0026] 14) Determine whether the first byte meets the MQTT connection request message characteristics;
[0027] If the MQTT connection request message characteristics are not met, exit;
[0028] If the MQTT connection request message characteristics are met, read the remaining bytes of the connection request message;
[0029] 15) Calculate the remaining length according to the remaining length bytes;
[0030] 16) The length of the complete connection request message read from the data transmission interface is 1 + the number of bytes of the remaining bytes + the number of bytes of the remaining length;
[0031] 17) Parse the length of the client ID of the MQTT connection and obtain the client ID;
[0032] 18) parse the connection identifier 1st + remaining bytes + 8 bytes flag from the connection request message;
[0033] 19) Parse the flag in step 18) to determine whether the will flag willflag is enabled;
[0034] If so, parse the will subject length and obtain the will subject;
[0035] If not, parse the username length of the MQTT connection to obtain the username;
[0036] 20) Parse the will payload length and obtain the will payload;
[0037] 21) Parse the password length and client ID length of the MQTT connection and obtain the password and client ID;
[0038] 22) According to the username-password-client id triple, read the precise route of the device from the device route storage module and obtain the MQTT cluster name to which the device belongs;
[0039] 23)According to the name of the MQTT cluster to which the device belongs, obtain the IP addresses of all nodes in the MQTT cluster;
[0040] 24) Determine whether the device precise routing has value;
[0041] If the device precise routing has a value, execute step 28);
[0042] If the device precise routing has no value, execute step 25);
[0043] 25) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value;
[0044] 26) Write the correspondence between the username-password-client id triple and the node ip into the device routing storage module;
[0045] 27) forward the connection request message to the node IP obtained in step 25) and end;
[0046] 28) Determine whether the node IP of the precise routing is in the node IP obtained in step 23) to prevent the node IP from changing;
[0047] If it is in the node IP obtained in step 23), execute step 27);
[0048] If it is not in the node IP obtained in step 23), execute step 29);
[0049] 29) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value;
[0050] 30) The node IP that matches the hash value obtained in step 29) of the username-password-client ID triple mapping is written into the device routing storage module, and step 27) is executed.
[0051] Furthermore, the process of the cloud sending control instructions to the device includes:
[0052] Select the device to send the command;
[0053] Find the MQTT cluster to which the device belongs;
[0054] Find the corresponding channel service according to the MQTT cluster to which the device belongs;
[0055] Send instructions to the corresponding channel service.
[0056] The construction method of arbitrarily extending MQTT multi-cluster based on controllable dynamic routing includes:
[0057] Allocate the MQTT cluster to which the device belongs to through the device management service module and write the MQTT cluster information to which the device belongs into the device routing storage module;
[0058] Manage and maintain the MQTT cluster list and the node IP list of each MQTT cluster through the MQTT cluster IP manager, and write this information into the device routing storage module;
[0059] The MQTT reverse proxy gateway is used as a unified entry point for device access. When the device is connected, it parses the connection request message and reads the MQTT cluster that the device should connect to in the device routing storage module, and proxies the device's connection request and forwards it to the correct MQTT cluster node.
[0060] The beneficial effects of the present invention are:
[0061] 1. The present invention introduces the MQTT reverse proxy gateway to achieve seamless expansion of device access, quickly store strategies to reduce pressure, ensure high-performance access, and optimize resource usage.
[0062] 2. The device of the present invention does not need to be modified, and can directly reach the specified MQTT cluster node with one connection. The adhesion feature maintains data timing, improves user experience, and reduces migration costs.
[0063] 3. The present invention utilizes the plug-in capability of the MQTT reverse proxy gateway, customizes the routing logic of the MQTT protocol, implements precise cluster node allocation based on triples, solves the random allocation problem, and ensures connection reliability and data consistency. BRIEF DESCRIPTION OF THE DRAWINGS
[0064] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0065] Figure 1 The overall architecture diagram of the system for building MQTT multiple clusters that can be arbitrarily expanded based on controllable dynamic routing provided in an embodiment of the present invention.
[0066] Figure 2 This is a diagram of the existing architecture in Example 3 of the present invention.
[0067] Figure 3 FIG. 2 is a diagram of the existing architecture in Example 3 of the present invention. DETAILED DESCRIPTION
[0068] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0069] Example 1
[0070] like Figure 1 As shown, the present invention provides a construction system for arbitrarily expanding MQTT multi-cluster based on controllable dynamic routing, characterized in that it includes:
[0071] The device management service module, as shown in Table 1, is used to assign a device to a belonging MQTT cluster according to a business relationship, and write the MQTT cluster information to which the device belongs into the device routing storage module.
[0072] Table 1: Example table of device management service module allocation data.
[0073] Device 1 Cluster A Device 2 Cluster B Device 3 Cluster B
[0074] It should be noted that the MQTT cluster information to which the device belongs includes: the route from the device to the specified MQTT cluster, the route from the device to the specific node in the specified MQTT cluster, and does not restrict the device from connecting to the specific node in this cluster.
[0075] The MQTT cluster ip manager is used to manage and maintain the MQTT cluster list and the node ip list of each MQTT cluster, and write this information into the device routing storage module. The specific steps are as follows: configure the new EMQX Cluster name and access URL; read the MQTT cluster information from each EMQX Cluster regularly; parse the ip information of each node in the MQTT cluster; write the ip information of each node in the MQTT cluster into the device routing storage module. It should be noted that:
[0076] The data in the MQTT cluster IP manager uses redis. The cluster node information data can be a list of multiple cluster names as shown in Table 2. Each entry in the list is the IP of a cluster node.
[0077] Table 2: Example table of MQTT cluster IP manager allocation data.
[0078]
[0079] The device routing storage module is used to store information from the device management service module and the MQTT cluster IP manager;
[0080] The MQTT reverse proxy gateway is used as a unified entry point for device access. When the device is connected, it parses the connection request message and reads the MQTT cluster that the device should connect to in the device routing storage module, and proxies the device's connection request and forwards it to the correct MQTT cluster node. Among them, the TCP load balancing gateway is used as the MQTT reverse proxy gateway. It should be noted that:
[0081] After receiving a TCP message at a specific port, the MQTT reverse proxy gateway determines whether it is an MQTT connection request message;
[0082] If so, parse the username-password-client id triple in the MQTT connection request message, and assign the MQTT cluster to which the device belongs based on the device that matches the partial information or combined information of the triple;
[0083] If the device is connected for the first time, the device is assigned to connect to one of the nodes in the MQTT cluster to which it belongs.
[0084] If the device is not connecting for the first time and the original node is still in the MQTT cluster to which it belongs, connect to the original node.
[0085] This embodiment takes the matt3.1.1 protocol as an example to parse the connection request message when the device is connected and read the MQTT cluster to which the device should be connected in the device routing storage module, and proxy the device's connection request and forward it to the correct MQTT cluster node, including:
[0086] 11) The device connects to the MQTT reverse proxy gateway;
[0087] 12) MQTT reverse proxy gateway custom plug-in handles new connection access;
[0088] 13) According to the MQTT protocol connection request, read the first byte of the message from the data transmission interface socket;
[0089] 14) Determine whether the first byte meets the MQTT connection request message characteristics;
[0090] If the MQTT connection request message characteristics are not met, exit;
[0091] If the MQTT connection request message characteristics are met, read the remaining bytes remainingByteNum of the connection request message;
[0092] 15) According to the remaining length bytes remainByteNum, the remaining length remainingLength is calculated as follows: (lua code calculates the remaining length
[0093] for i=1,5,1do
[0094] remainByteNum=remainByteNum+1;
[0095] data = tcpsock:peek(i+1)
[0096] len = string.byte(data,-1)
[0097] remainLength=remainLength+bit.band(len,127)*multiplier
[0098] multiplier = multiplier * 128
[0099] if bit.band(len,128)<128then
[0100] break;
[0101] end
[0102] end )
[0104] 16) The length of the complete connection request message read from the data transmission interface socket is 1 + the number of bytes of the remaining bytes + the number of bytes of the remaining length;
[0105] 17) Parse the length of the client ID of the MQTT connection and obtain the client ID;
[0106] 18) Parse the connection flag Connect Flags 1st + remaining byte remainByteNum + 8 bytes flag from the connection request message
[0107] 19) Parse the flag in step 18) to determine whether the will flag is enabled;
[0108] If yes, parse the length of the will topic and get the will topic;
[0109] If not, parse the username length of the MQTT connection to obtain the username;
[0110] 20) Parse the payload length of the will and obtain the payload;
[0111] 21) Parse the password length and client ID length of the MQTT connection and obtain the password and client ID;
[0112] 22) According to the username-password-client id triple, read the precise route of the device from the device route storage module and obtain the MQTT cluster name to which the device belongs;
[0113] 23)According to the name of the MQTT cluster to which the device belongs, obtain the IP addresses of all nodes in the MQTT cluster;
[0114] 24) Determine whether the device precise routing has value;
[0115] If the device precise routing has a value, execute step 28);
[0116] If the device precise routing has no value, execute step 25);
[0117] 25) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value;
[0118] 26) Write the correspondence between the username-password-client id triple and the node ip into the device routing storage module;
[0119] 27) forward the connection request message to the node IP obtained in step 25) and end;
[0120] 28) Determine whether the node IP of the precise routing is in the node IP obtained in step 23) to prevent the node IP from changing;
[0121] If it is in the node IP obtained in step 23), execute step 27);
[0122] If it is not in the node IP obtained in step 23), execute step 29);
[0123] 29) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value;
[0124] 30) The node IP that matches the hash value obtained in step 29) of the username-password-client ID triple mapping is written into the device routing storage module, and step 27) is executed.
[0125] The connection request message is shown in Table 3.
[0126] Table 3: Connection request message table.
[0127]
[0128] Furthermore, the process of the cloud sending control instructions to the device includes: selecting a device to send instructions; searching for the MQTT cluster to which the device belongs; finding the corresponding channel service according to the MQTT cluster to which the device belongs; and sending instructions to the corresponding channel service.
[0129] It can be seen that the present invention provides an optimized MQTT multi-cluster implementation. Since the MQTT reverse proxy gateway used, such as the load balancing based on TCP connection implemented by nginx / openresty, is a stateless service, the gateway itself can be expanded at will, and the fast storage shared by all gateways is only accessed when the device creates / connects and maintains the node IP of each MQTT cluster. Since these scenarios have retry capabilities, it can be considered that the fast storage itself is not a bottleneck. Therefore, the multi-MQTT cluster access capability based on the routing and forwarding of this MQTT reverse proxy gateway can be regarded as a large cluster with unlimited access capability; and any changes in the access point are not perceived by the device, and there is no need for the device to make any changes, and it can be connected to the platform through a normal connection; the specific MQTT cluster to which the device belongs is specified, not random; the specific node of the specific MQTT cluster to which the device is connected has an adhesion feature, that is, a specific device has been connected to an MQTT cluster node, and as long as this node is still a node of the MQTT cluster, the device will be connected to this node in the future. This adhesion feature ensures that the device connection / disconnection event and the order of reporting are consistent with the order issued by the actual MQTT cluster.
[0130] Example 2
[0131] Based on Example 1, this example also provides a method for constructing multiple MQTT clusters that can be arbitrarily expanded based on controllable dynamic routing, including:
[0132] Allocate the MQTT cluster to which the device belongs to through the device management service module and write the MQTT cluster information to which the device belongs into the device routing storage module;
[0133] Manage and maintain the MQTT cluster list and the node IP list of each MQTT cluster through the MQTT cluster IP manager, and write this information into the device routing storage module;
[0134] The MQTT reverse proxy gateway is used as a unified entry point for device access. When the device is connected, it parses the connection request message and reads the MQTT cluster that the device should connect to in the device routing storage module, and proxies the device's connection request and forwards it to the correct MQTT cluster node.
[0135] Example 3
[0136] like Figure 2 and Figure 3 As shown, based on Example 1, this example provides an analysis and comparison of a construction system for arbitrarily expanding MQTT multi-clusters based on controllable dynamic routing, and verifies and explains the technical effects used in this system.
[0137] like Figure 2 As shown in the figure, the most common architecture for projects that currently support clustering capabilities for MQTT servers has the following two problems:
[0138] (1) The configuration of an MQTT cluster is determined at the beginning. When the performance reaches a bottleneck, the expansion of the MQTT cluster configuration requires a restart, which will cause all connected devices to be disconnected and reconnected. The disconnection itself may affect the business, and the disconnected connections will be reconnected quickly, which can easily put pressure on system performance and bandwidth.
[0139] (2) The hardware configuration of an MQTT cluster has an upper limit. When the bottleneck is reached, the capacity cannot be expanded. At this time, subsequent devices can only connect to other addresses, which causes inconvenience to the production and management of the equipment.
[0140] like Figure 3 As shown, different from Figure 2 In the architecture, the device is connected to the default MQTT cluster for the first time, and the connection management determines which MQTT cluster the device is officially connected to based on business requirements. However, this architecture also has the following different problems:
[0141] (1) The device needs to be able to process the connection new address instruction issued by the connection management, and the device needs to have the ability to specifically process this instruction. However, it is very likely that this was not required at the beginning, and the existing device does not have the ability to process this instruction. The device needs to be replaced or OTA upgraded
[0142] (2) The device needs to connect to at least the default MQTT cluster for the first time. After receiving the command, it disconnects from the default MQTT cluster and then connects to other clusters, which increases network overhead.
[0143] In the system of the present invention, the cluster to which the device should connect is determined by the device management service and written into the device routing storage module, i.e., the fast storage. When the device is connected, the gateway parses the connection message to determine which device it is, directly reads the cluster to which the device should be connected in the fast storage, and the gateway proxy device's connection request is connected to the corresponding cluster. The device of the present invention is non-perceptual and can handle existing devices in the same way. The expansion of the MQTT cluster can be achieved by adding clusters, and the capacity can be flexibly expanded by simply pointing the new device route to the new cluster.
[0144] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention is described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.
Claims
1. A system for building MQTT multi-clusters that can be arbitrarily expanded based on controllable dynamic routing, characterized by: include: The device management service module is used to assign a MQTT cluster to a device and write the MQTT cluster information to which the device belongs into the device routing storage module; MQTT cluster IP manager, used to manage and maintain the MQTT cluster list and the node IP list of each MQTT cluster, and write this information into the device routing storage module; The device routing storage module is used to store information from the device management service module and the MQTT cluster IP manager; The MQTT reverse proxy gateway is used as a unified entry point for device access. When a device is connected, it parses the connection request message and reads the MQTT cluster to which the device should be connected in the device routing storage module. It also proxies the device's connection request and forwards it to the correct MQTT cluster node.
2. The system for constructing MQTT multi-clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in claim 1, characterized in that: Use TCP load balancing gateway as MQTT reverse proxy gateway.
3. The system for constructing MQTT multi-clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in claim 1, characterized in that: The MQTT cluster information to which the device belongs includes: the route from the device to the specified MQTT cluster, and the route from the device to a specific node in the specified MQTT cluster.
4. The system for constructing MQTT multi-clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in claim 2, characterized in that: Managing and maintaining the MQTT cluster list and the node IP list of each MQTT cluster, and writing this information to the device routing storage module includes: Configure the new EMQX Cluster name and access URL; Read MQTT cluster information from each EMQX Cluster regularly; Parse the IP information of each node in the MQTT cluster; Write the IP information of each node in the MQTT cluster into the device routing storage module.
5. The system for constructing MQTT multiple clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in claim 1, characterized in that: After receiving a TCP message at a specific port, the MQTT reverse proxy gateway determines whether it is an MQTT connection request message; If so, parse the username-password-client id triple in the MQTT connection request message, and assign the MQTT cluster to which the device belongs based on the device that matches the partial information or combined information of the triple; If the device is connected for the first time, the device is assigned to connect to one of the nodes in the MQTT cluster to which it belongs. If the device is not connecting for the first time and the original node is still in the MQTT cluster to which it belongs, connect to the original node.
6. The system for constructing multiple MQTT clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in any one of claims 1 or 5, characterized in that: When the device is connected, the connection request message is parsed and the MQTT cluster to which the device should be connected is read in the device routing storage module, and the device's connection request is proxied to forward it to the correct MQTT cluster node, including: 11) The device connects to the MQTT reverse proxy gateway; 12) MQTT reverse proxy gateway custom plug-in handles new connection access; 13) According to the MQTT protocol connection request, read the first byte of the message from the data transmission interface; 14) Determine whether the first byte meets the MQTT connection request message characteristics; If the MQTT connection request message characteristics are not met, exit; If the MQTT connection request message characteristics are met, read the remaining bytes of the connection request message; 15) Calculate the remaining length according to the remaining length bytes; 16) The length of the complete connection request message read from the data transmission interface is 1 + the number of bytes of the remaining bytes + the number of bytes of the remaining length; 17) Parse the length of the client ID of the MQTT connection and obtain the client ID; 18) parse the connection identifier 1st + remaining bytes + 8 bytes flag from the connection request message; 19) Parse the flag in step 18) to determine whether the will flag willflag is enabled; If so, parse the will subject length and obtain the will subject; If not, parse the username length of the MQTT connection to obtain the username; 20) Parse the will payload length and obtain the will payload; 21) Parse the password length and client ID length of the MQTT connection and obtain the password and client ID; 22) According to the username-password-client id triple, read the precise route of the device from the device route storage module and obtain the MQTT cluster name to which the device belongs; 23)According to the name of the MQTT cluster to which the device belongs, obtain the IP addresses of all nodes in the MQTT cluster; 24) Determine whether the device precise routing has value; If the device precise routing has a value, execute step 28); If the device precise routing has no value, execute step 25); 25) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value; 26) Write the correspondence between the username-password-client id triple and the node ip into the device routing storage module; 27) forward the connection request message to the node IP obtained in step 25) and end; 28) Determine whether the node IP of the precise routing is in the node IP obtained in step 23) to prevent the node IP from changing; If it is in the node IP obtained in step 23), execute step 27); If it is not in the node IP obtained in step 23), execute step 29); 29) Calculate a fixed-length hash value of the username-password-client ID triplet through a hash algorithm, and select the IP addresses of all nodes of the MQTT cluster obtained in step 23) according to the hash value; 30) The node IP that matches the hash value obtained in step 29) of the username-password-client ID triple mapping is written into the device routing storage module, and step 27) is executed.
7. The system for constructing MQTT multi-clusters based on controllable dynamic routing and capable of arbitrary expansion as claimed in claim 1, characterized in that: The process of sending control instructions from the cloud to the device includes: Select the device to send the command; Find the MQTT cluster to which the device belongs; Find the corresponding channel service according to the MQTT cluster to which the device belongs; Send instructions to the corresponding channel service.
8. A method for constructing a system based on controllable dynamic routing and capable of arbitrarily expanding MQTT multi-cluster as described in any one of claims 1 to 7, characterized in that: include: Allocate the MQTT cluster to which the device belongs to through the device management service module and write the MQTT cluster information to which the device belongs into the device routing storage module; Manage and maintain the MQTT cluster list and the node IP list of each MQTT cluster through the MQTT cluster IP manager, and write this information into the device routing storage module; The MQTT reverse proxy gateway is used as a unified entry point for device access. When the device is connected, it parses the connection request message and reads the MQTT cluster that the device should connect to in the device routing storage module, and proxies the device's connection request and forwards it to the correct MQTT cluster node.
Citation Information
Patent Citations
Multi-cluster dynamic expansion method and system based on EMQ X
CN114615277A