A message transmission method and system based on MQTT and a database

Abstract

The application discloses a message transmission method and system based on MQTT and a database, and belongs to the technical field of data communication. The method comprises an MQTT unit, Redis, a business processing unit and a relational database. The MQTT unit comprises MQTT clients arranged on nodes and an MQTT server arranged on a cloud server. The Redis is arranged on the nodes and is used for storing node permissions, storing request states, storing received information and storing feedback information. The business processing unit is arranged on the nodes and is used for processing request information or feedback information and operating the relational database. The relational database is arranged on the nodes and is used for storing data information and request processing information of the nodes. The application can solve the problems of message repetition, message conflict and message loss caused by the MQTT using the QoS0 mechanism in a distributed system.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, specifically to a message transmission method and system based on MQTT and a database. Background Technology

[0002] Thanks to the development and widespread adoption of cloud computing technology, enterprise services are increasingly being deployed in the cloud. Simultaneously, as enterprise services expand, single-point servers are gradually becoming insufficient, making distributed systems the preferred choice. For distributed systems, especially those involving edge computing, communication between edge nodes and central nodes presents a new challenge.

[0003] MQTT (Message Queuing Telemetry Transport) is a lightweight protocol based on the publish / subscribe model. Built on top of TCP / IP, MQTT's greatest advantage lies in its ability to provide real-time, reliable messaging services to connected remote devices with minimal code and limited bandwidth. As a low-overhead, low-bandwidth instant messaging protocol, it is widely used in the Internet of Things (IoT), small devices, and mobile applications.

[0004] MQTT has designed a mechanism to ensure stable message transmission, including message acknowledgment, storage, and retransmission.

[0005] This mechanism provides three different levels of QoS (Quality of Service):

[0006] QoS0, At most once;

[0007] QoS1, At least once;

[0008] QoS2, Exactly once, ensures it only happens once.

[0009] QoS is an agreement reached between the sender and receiver of a message.

[0010] QoS0 means that the Receiver can receive a message sent by the Sender at most once. The Sender makes an effort to send the message to the Receiver, and if it fails to send, no action is taken.

[0011] QoS1 means that the Receiver will receive a message sent by the Sender at least once. If the Sender fails to send a message to the Receiver, it will continue to retry until the Receiver receives the message. However, due to retransmission, the Receiver may receive duplicate messages.

[0012] QoS2 means that the Receiver guarantees to receive a message sent by the Sender exactly once. The Sender makes every effort to send the message to the Receiver, and if the sending fails, it will continue to retry until the Receiver receives the message, while ensuring that the Receiver will not receive duplicate messages due to message retransmission.

[0013] QoS2's retransmission and acknowledgment mechanisms are complex and have the highest overhead. In high-throughput applications, such as when multiple sensor devices transmit data in real time, the additional overhead of QoS2 has a significant impact. QoS0, with its low message overhead and high speed, is more suitable for such scenarios.

[0014] For QoS0, it is necessary to solve the problems of message duplication and message loss. Especially when dealing with distributed systems, where a large amount of information is transmitted between multiple nodes, a system and method that can perform message deduplication, resolve message conflicts, and handle message loss is particularly important. Summary of the Invention

[0015] The technical objective of this invention is to address the above-mentioned shortcomings by providing a message transmission method and system based on MQTT and a database, which can solve the problems of message duplication, message conflict, and message loss caused by using the QoS0 mechanism of MQTT in distributed systems; simplify the connection between distributed nodes and ensure real-time and reliable information transmission.

[0016] The technical solution adopted by this invention to solve its technical problem is:

[0017] A message transmission method based on MQTT and a database, the implementation of which includes an MQTT unit, Redis, a business processing unit, and a relational database;

[0018] The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on the cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node.

[0019] The Redis configuration is on each node to quickly cache relevant information, including storage node permissions, storage request status, storage received information and storage feedback information;

[0020] The business processing unit is configured on each node and is used to process request information or feedback information and operate on relational databases;

[0021] The relational database is configured on each node to store the node's data information and request processing information, and to persist the data and processing results, making it easier to trace back, solve, and summarize problems later.

[0022] In this method, the MQTT unit includes an MQTT client and an MQTT server for message transmission; Redis is used to store node permissions, request status, and received information; the business processing unit is used to execute the corresponding processing logic; and a relational database is used to store the node's data information and request processing information. A complete message transmission process includes request initiation and recording, request reception, recording and processing, and request information feedback and processing. This method overcomes the shortcomings of existing technologies, solves the problems of message duplication, message conflict, and message loss caused by using the QoS0 mechanism MQTT in distributed systems, simplifies the connection between distributed nodes, and ensures real-time and reliable information transmission.

[0023] Preferably, the Redis storage node permissions include the topics that each node can publish and subscribe to.

[0024] Preferably, regarding the Redis storage node permissions, when there are multiple central nodes that are synchronized with each other, in order to prevent multiple central nodes from receiving feedback information and processing it simultaneously, which could lead to subsequent conflicts, different central nodes will be responsible for one or more fixed request topics, and these will be recorded in the node permissions.

[0025] Furthermore, the specific implementation of this method is as follows:

[0026] Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers to partially resolve message conflict issues. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions.

[0027] Step 2: Data transmission and interaction occur between the two nodes. A single data transmission interaction includes initiating and recording a request, receiving, recording, and processing the request, and providing feedback and processing of the request information. Message data is transmitted via the MQTT module, cached in Redis, logically processed by the business processing module, and persisted in a relational database. The information is then fed back to the request initiator for appropriate logical processing, and the relevant information for this interaction is persisted in the relational database. This step resolves message conflicts and message duplication issues.

[0028] Step 3: Message retransmission is performed under specific circumstances to resolve message loss issues. If the requesting party does not receive a response after a waiting time t, it retransmits the request. If the maximum number of retransmissions n is reached, it indicates a network or hardware problem. In this case, no specific handling is performed; instead, the failed request information is stored in the database for backtracking and root cause investigation when other solutions are needed. The waiting time t and the maximum number of retransmissions n are set and adjusted according to specific real-world conditions.

[0029] Furthermore, step 2 specifically includes the following four parts:

[0030] Initiating a request: The node that initiates the request, i.e., the business processing module of the request initiator, organizes the message payload information, including a unique identifier composed of a topic identifier and a timestamp, and the detailed request content, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis;

[0031] Receiving a request: The node receiving the request, i.e., the MQTT client of the request recipient, receives the request information through the corresponding subscribed MQTT topic, and compares it with Redis to see if there is already a record corresponding to the unique identifier; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis.

[0032] Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, including the required return content, request execution status, and a unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, it sets the validity period of this information record in Redis to a waiting time t, after which the record expires.

[0033] Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis. In Redis, the received information is classified according to the request type and formed into an execution queue. The business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in a relational database. After the business is completed, the status of the request record in Redis is changed, the corresponding feedback information is no longer received, and the validity period of the request record is set to a waiting time t. After time t, the record becomes invalid.

[0034] This invention also claims a message transmission system based on MQTT and a database, including an MQTT unit, Redis, a business processing unit, and a relational database;

[0035] The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on the cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node.

[0036] The Redis configuration is on each node and is used to store node permissions, request status, received information and feedback information.

[0037] The business processing unit is configured on each node and is used to process request information or feedback information and operate on relational databases;

[0038] The relational database is configured on each node to store the node's data information and request processing information.

[0039] Preferably, the Redis storage node permissions include the topics that each node can publish and subscribe to.

[0040] Preferably, regarding the Redis storage node permissions, when there are multiple central nodes that are synchronized with each other, in order to prevent multiple central nodes from receiving feedback information and processing it simultaneously, which could lead to subsequent conflicts, different central nodes will be responsible for one or more fixed request topics, and these will be recorded in the node permissions.

[0041] Furthermore, the specific implementation process of this system is as follows:

[0042] Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers to partially resolve message conflict issues. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions.

[0043] Step 2: Data transmission and interaction occur between the two nodes. A single data transmission interaction includes initiating and recording a request, receiving, recording, and processing the request, and providing feedback and processing of the request information. Message data is transmitted via the MQTT module, cached in Redis, logically processed by the business processing module, and persisted in a relational database. The information is then fed back to the request initiator for appropriate logical processing, and the relevant information for this interaction is persisted in the relational database. This step resolves message conflicts and message duplication issues.

[0044] Step 3: Message retransmission is performed under specific circumstances to resolve message loss issues. If the requesting party does not receive a response after a waiting time t, it retransmits the request. If the maximum number of retransmissions n is reached, it indicates a network or hardware problem. In this case, no specific handling is performed; instead, the failed request information is stored in the database for backtracking and root cause investigation when other solutions are needed. The waiting time t and the maximum number of retransmissions n are set and adjusted according to specific real-world conditions.

[0045] Furthermore, step 2 specifically includes the following four parts:

[0046] Initiating a request: The node that initiates the request, i.e., the business processing module of the request initiator, organizes the message payload information, including a unique identifier composed of a topic identifier and a timestamp, and the detailed request content, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis;

[0047] Receiving a request: The node receiving the request, i.e., the MQTT client of the request recipient, receives the request information through the corresponding subscribed MQTT topic, and compares it with Redis to see if there is already a record corresponding to the unique identifier; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis.

[0048] Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, including the required return content, request execution status, and a unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, it sets the validity period of this information record in Redis to a waiting time t, after which the record expires.

[0049] Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis. In Redis, the received information is classified according to the request type and formed into an execution queue. The business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in a relational database. After the business is completed, the status of the request record in Redis is changed, the corresponding feedback information is no longer received, and the validity period of the request record is set to a waiting time t. After time t, the record becomes invalid.

[0050] Compared with the prior art, the message transmission method and system based on MQTT and database of the present invention have the following advantages:

[0051] This method or system utilizes the characteristics of the MQTT publish / subscribe pattern, allowing nodes to transmit multiple messages through a single connection without repeatedly establishing new connections, thus simplifying the connection between nodes. At the same time, by applying MQTT's QoS0 mode, it can ensure the real-time reliability of a large number of messages under low network and low hardware conditions, guaranteeing the reliability of communication for nodes with poor network and hardware conditions in the distributed system.

[0052] The retransmission mechanism is used to ensure a stable response to requests and prevent message loss caused by QoS0.

[0053] Use Redis to record requests to ensure the normal flow of requests and prevent conflicts between requests and responses;

[0054] By using a relational database to store request results, requests are persisted, preventing request loss and facilitating understanding of request records and subsequent processing in case of unexpected situations. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of the node structure in the message transmission method based on MQTT and database provided in the embodiments of the present invention;

[0056] Figure 2 This is a schematic diagram of the inter-node communication process in the message transmission method based on MQTT and database provided in the embodiments of the present invention;

[0057] Figure 3 This is a schematic diagram of message feedback retransmission in the message transmission method based on MQTT and database provided in the embodiments of the present invention. Detailed Implementation

[0058] The present invention will be further described below with reference to specific embodiments.

[0059] This invention provides a message transmission method based on MQTT and a database. The implementation of this method includes an MQTT unit, Redis, a business processing unit, and a relational database.

[0060] The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on a cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node.

[0061] The Redis configuration is set up on each node to quickly cache relevant information, including storage node permissions, storage request status, storage received information, and storage feedback information; node permissions mainly refer to the topics that each node can publish and subscribe to.

[0062] like Figure 1 As shown, there are sometimes multiple central nodes that synchronize with each other. To prevent multiple central nodes from receiving and processing feedback information simultaneously, which could lead to subsequent conflicts, different central nodes will be responsible for one or more fixed request topics, and this will be recorded in the node permissions.

[0063] The business processing unit is configured on each node and is used to process request information or feedback information and operate on relational databases;

[0064] The relational database is configured on each node to store the node's data information and request processing information, and to persist the data and processing results, making it easier to trace back, solve, and summarize problems later.

[0065] The specific implementation of this method is as follows:

[0066] Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers to partially resolve message conflict issues. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions.

[0067] Step 2: As Figure 2 As shown, data transmission occurs between two nodes. A single data transmission interaction includes initiating and recording a request, receiving, recording, and processing the request, and providing feedback and processing of the request information. Message data is transmitted via the MQTT module, cached in Redis, processed logically by the business processing module, persisted in a relational database, and then fed back to the request initiator for further logical processing and persistence of the relevant information in the relational database. This step resolves message conflicts and message duplication issues. This step specifically includes the following four parts:

[0068] Initiating a request: The business processing module of the node that needs to initiate the request (hereinafter referred to as the request initiator) organizes the message payload information, mainly including a unique identifier composed of a topic identifier and a timestamp, and the detailed content of the request, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis;

[0069] Receiving a request: The MQTT client of the node receiving the request (hereinafter referred to as the request receiver) receives the request information through the corresponding subscribed MQTT topic, and compares whether there is already a record corresponding to the unique identifier in Redis; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis.

[0070] Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, mainly including the content to be returned, the request execution status, and a unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, the validity period of this information record in Redis is set to a waiting time t, after which the record expires.

[0071] Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis. In Redis, the received information is classified according to the request type and formed into an execution queue. The business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in a relational database. After the business is completed, the status of the request record in Redis is changed, the corresponding feedback information is no longer received, and the validity period of the request record is set to a waiting time t. After time t, the record becomes invalid.

[0072] Step 3: As Figure 2 As shown, message retransmission is performed under specific circumstances to solve the problem of message loss. If the requesting party does not receive a response after a waiting time *t*, it retransmits the request. If the maximum number of retransmissions *n* is reached, it indicates a network or hardware problem. In this case, no specific handling is performed; instead, the failed request information is stored in the database for later troubleshooting and root cause analysis when other methods are used to resolve the issue. The waiting time *t* and the maximum number of retransmissions *n* are set and adjusted according to specific real-world conditions.

[0073] In this method, the MQTT unit includes an MQTT client and an MQTT server for message transmission; Redis is used to store node permissions, request status, and received information; the business processing unit is used to execute the corresponding processing logic; and a relational database is used to store the node's data information and request processing information. A complete message transmission process includes request initiation and recording, request reception, recording and processing, and request information feedback and processing. This method overcomes the shortcomings of existing technologies, solves the problems of message duplication, message conflict, and message loss caused by using the QoS0 mechanism MQTT in distributed systems, simplifies the connection between distributed nodes, and ensures real-time and reliable information transmission.

[0074] This invention also provides a message transmission system based on MQTT and a database, including an MQTT unit, Redis, a business processing unit, and a relational database;

[0075] The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on a cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node.

[0076] The Redis configuration is set up on each node to quickly cache relevant information, including storage node permissions, storage request status, storage received information, and storage feedback information; node permissions mainly refer to the topics that each node can publish and subscribe to.

[0077] Sometimes there are multiple central nodes that synchronize with each other. To prevent multiple central nodes from receiving and processing feedback information simultaneously, which could lead to subsequent conflicts, different central nodes will be responsible for one or more fixed request topics, and this will be recorded in the node permissions.

[0078] The business processing units are configured on each node and are the specific processing units in the system that complete business requirements and related logical processing. Their designs vary depending on the specific business requirements. They are used to process request or feedback information and to operate on relational databases.

[0079] The relational database is configured on each node to store the node's data information and request processing information, and to persist the data and processing results, making it easier to trace back, solve, and summarize problems later.

[0080] The specific implementation process of this system is as follows:

[0081] Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers to partially resolve message conflict issues. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions.

[0082] Step 2: Data transmission and interaction occur between the two nodes. A single data transmission interaction includes request initiation and recording, request reception, recording and processing, and request information feedback and processing. Message data is transmitted via the MQTT module, cached in Redis, logically processed by the business processing module, and persisted in a relational database. The information is then fed back to the request initiator for appropriate logical processing, and the relevant information for this interaction is persisted in the relational database. This step resolves message conflicts and message duplication issues. This step specifically includes the following four parts:

[0083] Initiating a request: The business processing module of the node that needs to initiate the request (hereinafter referred to as the request initiator) organizes the message payload information, mainly including a unique identifier composed of a topic identifier and a timestamp, and the detailed content of the request, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis.

[0084] Receiving a request: The MQTT client of the node receiving the request (hereinafter referred to as the request receiver) receives the request information through the corresponding subscribed MQTT topic and compares whether there is already a record corresponding to the unique identifier in Redis; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis.

[0085] Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, which mainly includes the content to be returned, the request execution status, and a unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, the validity period of this information record in Redis is set to a waiting time t, after which the record expires.

[0086] Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis. In Redis, the received information is classified according to the request type and formed into an execution queue. The business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in a relational database. After the business is completed, the status of the request record in Redis is changed, the corresponding feedback information is no longer received, and the validity period of the request record is set to a waiting time t. After time t, the record becomes invalid.

[0087] Step 3: Message retransmission is performed under specific circumstances to resolve message loss issues. If the requesting party does not receive a response after a waiting time t, it retransmits the request. If the maximum number of retransmissions n is reached, it indicates a network or hardware problem. In this case, no specific handling is performed; instead, the failed request information is stored in the database for backtracking and root cause investigation when other solutions are needed. The waiting time t and the maximum number of retransmissions n are set and adjusted according to specific real-world conditions.

[0088] Through the specific embodiments described above, those skilled in the art can easily implement the present invention. However, it should be understood that the present invention is not limited to the specific embodiments described above. Based on the disclosed embodiments, those skilled in the art can arbitrarily combine different technical features to achieve different technical solutions.

[0089] Except for the technical features described in the specification, all other technologies are known to those skilled in the art.

Claims

1. A message transmission method based on MQTT and a database, characterized in that, The implementation of this method includes an MQTT unit, Redis, a business processing unit, and a relational database; The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on the cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node. The Redis configuration is on each node and is used to store node permissions, request status, received information and feedback information. The business processing unit is configured on each node and is used to process request information or feedback information and operate on relational databases; The relational database is configured on each node to store the node's data information and request processing information; The Redis storage node permissions are recorded in the node permissions when there are multiple central nodes that are synchronized with each other. Different central nodes will be responsible for one or more fixed request topics. The specific implementation of this method is as follows: Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions. Step 2: Data transmission and interaction between the two nodes. A data transmission and interaction includes the initiation and recording of a request, the receipt, recording and processing of a request, and the feedback and processing of request information. Message data is transmitted through the MQTT module, cached in Redis, processed logically by the business processing module, persisted in a relational database, and then the information is fed back to the request initiator for corresponding logical processing and persistence of the interaction information in the relational database. Step 3: If the request initiator does not receive a response after a waiting time t after sending the request information, it will resend the request information. After the maximum number of resends n is reached, no further resend will be performed, and the failed request information will be stored in the database.

2. The message transmission method based on MQTT and a database according to claim 1, characterized in that, The Redis storage node permissions include the topics that each node can publish and subscribe to.

3. The message transmission method based on MQTT and a database according to claim 1, characterized in that, Step 2 specifically includes the following four parts: Initiating a request: The node that initiates the request, i.e., the business processing module of the request initiator, organizes the message payload information, including a unique identifier composed of a topic identifier and a timestamp, and the detailed request content, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis; Receiving a request: The node receiving the request, i.e., the MQTT client of the request recipient, receives the request information through the corresponding subscribed MQTT topic, and compares it with Redis to see if there is already a record corresponding to the unique identifier; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis. Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; Based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, including the requested return content, request execution status, and unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, the validity period of this information record in Redis is set to the waiting time t, after which the record expires. Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis; Redis classifies the received information according to the request type and forms an execution queue; the business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in the relational database. After the business is completed, change the status of the request record in Redis to stop receiving the corresponding feedback information, and set the validity period of the request record to a waiting time t. After time t, the record will become invalid.

4. A message transmission system based on MQTT and a database, characterized in that, This includes MQTT units, Redis, business processing units, and relational databases; The MQTT unit includes an MQTT client configured on each node and an MQTT server configured on the cloud server. The MQTT client is used by each node to publish and receive request / feedback information, and the MQTT server is used to forward information published by the MQTT client on each node. The Redis configuration is on each node and is used to store node permissions, request status, received information and feedback information. The business processing unit is configured on each node and is used to process request information or feedback information and operate on relational databases; The relational database is configured on each node to store the node's data information and request processing information; The Redis storage node permissions are recorded in the node permissions when there are multiple central nodes that are synchronized with each other. Different central nodes will be responsible for one or more fixed request topics. The specific implementation process of this system is as follows: Step 1: Associate requests with MQTT topics. For different requests, agree on the corresponding MQTT topics, MQTT feedback topics, and topic identifiers. Store the permissions of each node in Redis, and each node subscribes to the corresponding topic according to its permissions. Step 2: Data transmission and interaction between the two nodes. A data transmission and interaction includes the initiation and recording of a request, the receipt, recording and processing of a request, and the feedback and processing of request information. Message data is transmitted through the MQTT module, cached in Redis, processed logically by the business processing module, persisted in a relational database, and then the information is fed back to the request initiator for corresponding logical processing and persistence of the interaction information in the relational database. Step 3: If the request initiator does not receive a response after a waiting time t after sending the request information, it will resend the request information. After the maximum number of resends n is reached, no further resend will be performed, and the failed request information will be stored in the database.

5. A message transmission system based on MQTT and a database according to claim 4, characterized in that, The Redis storage node permissions include the topics that each node can publish and subscribe to.

6. A message transmission system based on MQTT and a database according to claim 4, characterized in that, Step 2 specifically includes the following four parts: Initiating a request: The node that initiates the request, i.e., the business processing module of the request initiator, organizes the message payload information, including a unique identifier composed of a topic identifier and a timestamp, and the detailed request content, and publishes the request with the corresponding MQTT topic; the request initiator adds a record of the request information and request status in its Redis; Receiving a request: The node receiving the request, i.e., the MQTT client of the request recipient, receives the request information through the corresponding subscribed MQTT topic, and compares it with Redis to see if there is already a record corresponding to the unique identifier; if there is already a corresponding record, the request information is not stored; if not, the information is stored in Redis. Request processing: The business processing unit of the request recipient retrieves the received information from Redis and parses out the specific request content; Based on the request content, the business processing unit executes the corresponding functional logic; after processing, it organizes the information into feedback information, including the requested return content, request execution status, and unique identifier; the MQTT client of the request recipient publishes the feedback with the corresponding MQTT feedback topic; at the same time, the validity period of this information record in Redis is set to the waiting time t, after which the record expires. Receiving feedback: The MQTT client of the request initiator obtains feedback information through the corresponding feedback topic and stores the information in Redis; Redis classifies the received information according to the request type and forms an execution queue; the business processing unit retrieves the information from Redis, executes the corresponding functional logic, and stores the request information and results in the relational database. After the business is completed, change the status of the request record in Redis to stop receiving the corresponding feedback information, and set the validity period of the request record to a waiting time t. After time t, the record will become invalid.

Images