CN116662035A

CN116662035A - Method and device for processing transaction message of message queue

Info

Publication number: CN116662035A
Application number: CN202310722835.7A
Authority: CN
Inventors: 丁修正
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Priority date: 2023-06-19
Filing date: 2023-06-19
Publication date: 2023-08-29

Abstract

The application provides a method and a device for processing transaction information of an information queue, and relates to the technical field of information transmission. The method comprises the following steps: generating a first global transaction identifier according to the global transaction message sent by the first equipment, and sending the first global transaction identifier to the first equipment; global transaction messages include local transactions and transactions that send messages; acquiring first indication information sent by first equipment; the first indication information carries a second global transaction identifier and is used for indicating the state of the first equipment after the local transaction is executed; generating second indication information after executing the transaction for sending the message according to the second global transaction identifier, and sending the second indication information to the first equipment; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction for sending the message. The scheme of the application is that any message queue is used by a user, and the transaction message mechanism of the message queue is completely not relied on.

Description

Method and device for processing transaction message of message queue

Technical Field

The present application relates to the field of message transmission technologies, and in particular, to a method and an apparatus for processing a transaction message in a message queue.

Background

The use of message queues in distributed systems, the execution of local transactions and the sending of messages to meet the constraints of the transaction are very critical requirements. In order to ensure data consistency in a traditional distributed environment, an event record table is generally added in a local database. An event record is generated along with the local transaction. After the local transaction is completed, the event is asynchronously sent to other services, and after the other services receive the event message, the service is completed. That is, on the premise of higher data consistency requirements, both the execution of the local transaction and the transaction for sending the message need to design the constraint condition of the transaction.

To achieve execution of local transactions and messaging meeting transaction constraints, the prior art mostly employs a RocketMQ message queue or a QMQ message queue. However, the RocketMQ message queue requires that the user must send a transaction message with a RocketMQ special tag, and implements a transaction listener for the RocketMQ to check the local transaction state, if the user also uses other message queues such as Kafka or ActiveMQ, the execution of the local transaction cannot be implemented and the messaging can not meet the constraint of the transaction using the RocketMQ message queue. QMQ message queues require that the user local operations must be on a Database (DB) instance with the QMQ database, and that the local engineering needs to start the timing tasks newly and ensure a single instance execution of the timing tasks, which is relatively intrusive to the service DB and code.

Disclosure of Invention

The application aims to provide a processing method and a processing device for transaction information of a message queue, which can ensure that two actions, namely execution and messaging of a local transaction, have transaction constraint under the condition that a user uses any message queue and does not depend on a transaction information mechanism of the message queue at all and almost has no invasion to a service DB and a code.

To achieve the above object, an embodiment of the present application provides a method for processing a transaction message in a message queue, including:

generating a first global transaction identifier according to a global transaction message sent by first equipment, and sending the first global transaction identifier to the first equipment; the global transaction message comprises a local transaction and a transaction for sending the message;

acquiring first indication information sent by the first equipment; the first indication information carries a second global transaction identifier, and is used for indicating a state of the first equipment after the local transaction is executed;

generating second indication information after executing the transaction for sending the message according to the second global transaction identifier, and sending the second indication information to the first device; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message.

Optionally, generating the first global transaction identifier according to the global transaction message sent by the first device includes:

according to the global transaction message sent by the first device, the global transaction message is stored in a first preset transaction table in the MQ proxy database; the first preset transaction table at least comprises primary key information and global transaction state information;

and storing the primary key information determined in the global transaction message as a first global transaction identifier.

Optionally, generating second indication information after executing the transaction of the sending message according to the second global transaction identifier includes:

according to the second global transaction identifier, the MQ proxy module starts the transaction for sending the message and executes a first preset flow; the first preset flow is the operation needed to be executed for the MQ proxy module to save the message and update the global transaction state;

the MQ proxy module generates the second indication information after executing the transaction for sending the message.

Optionally, after generating the second indication information after executing the transaction of sending the message, the method further comprises:

determining a first execution result of the first device executing the local transaction and a second execution result of the MQ proxy module executing the transaction of the sent message according to the first indication information and the second indication information;

When the first execution result and the second execution result are successful in execution, executing submitting operation to an MQ proxy database;

and executing rollback operation on the transaction corresponding to the execution failure when at least one of the first execution result and the second execution result fails.

Optionally, after performing the commit operation to the MQ proxy database, the method further comprises:

scanning the target message which is not sent by the MQ proxy database, asynchronously sending the target message to the MQ, and asynchronously deleting the target message which has been successfully sent.

Optionally, after asynchronously sending the target message to the MQ, the method further comprises:

scanning for timeout transactions in the global transaction message;

sending alarm information to the MQ agent monitoring module; the MQ agent monitoring module is used for checking the global transaction state corresponding to the global transaction message according to the alarm information;

the timeout duration of the timeout global transaction is configured or preconfigured by the MQ proxy module.

Optionally, when the MQ proxy module performs the transaction of sending the message, the method further comprises:

inserting a message corresponding to the transaction sending the message into a second preset transaction table of the MQ proxy database;

Wherein, the message corresponding to the transaction for sending the message at least comprises: the method comprises the steps of message identification, global transaction identification, primary key information of a first preset transaction table and message content.

sending a global transaction message to a message queue MQ proxy module, and receiving a first global transaction identifier sent by the global transaction message; the global transaction message comprises a local transaction and a transaction for sending the message;

sending first indication information to the MQ proxy module; the first indication information carries a second global transaction identifier and is used for indicating a state of the first equipment after the local transaction is executed;

receiving second indication information sent by the MQ proxy module; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message;

and executing a commit or rollback operation to the first equipment database according to the first indication information and the second indication information.

Optionally, the method further comprises:

according to the first global transaction identifier, the first device starts the local transaction and executes a second preset flow; the second preset flow is an operation to be executed by the first device for executing the local transaction;

And after the first device executes the local transaction successfully, generating the first indication information.

Optionally, performing a commit or rollback operation to the first device database according to the first indication information and the second indication information, including:

when the first execution result and the second execution result are successful in execution, executing submitting operation to the first equipment database;

To achieve the above object, an embodiment of the present application provides a processing apparatus for a message queue transaction message, including:

the first processing module is used for generating a first global transaction identifier according to the global transaction message sent by the first equipment and sending the first global transaction identifier to the first equipment; the global transaction message comprises a local transaction and a transaction for sending the message;

The first acquisition module is used for acquiring first indication information sent by the first equipment; the first indication information carries a second global transaction identifier, and is used for indicating a state of the first equipment after the local transaction is executed;

the second processing module is used for generating second indication information after executing the transaction of the sending message according to the second global transaction identifier and sending the second indication information to the first equipment; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message.

the third processing module is used for sending global transaction information to the information queue MQ proxy module and receiving a first global transaction identifier sent by the global transaction information; the global transaction message comprises a local transaction and a transaction for sending the message;

the first sending module is used for sending first indication information to the MQ proxy module; the first indication information carries a second global transaction identifier and is used for indicating a state of the first equipment after the local transaction is executed;

The first receiving module is used for receiving the second indication information sent by the MQ proxy module; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message;

and the fourth processing module is used for executing the submitting or rolling-back operation to the first equipment database according to the first indication information and the second indication information.

The technical scheme of the application has the following beneficial effects:

in the embodiment of the application, a first global transaction identifier is generated according to a global transaction message sent by first equipment; receiving first indication information sent by first equipment after local transaction is executed; according to the second global transaction identifier, the second indication information is generated after the transaction for sending the message is executed, and the second indication information is sent to the first device.

Drawings

FIG. 1 is a flowchart of a method for processing a transaction message in a message queue according to an embodiment of the present application;

FIG. 2 is a flow chart of multi-terminal interaction of a processing method according to an embodiment of the present application;

FIG. 3 is a second flowchart of a method for processing a transaction message in a message queue according to an embodiment of the present application;

FIG. 4 is a block diagram of a message queue transaction message processing apparatus according to an embodiment of the present application;

fig. 5 is a second block diagram of a processing apparatus for message queue transaction messages according to an embodiment of the present application.

Detailed Description

In order to make the technical problems, technical solutions and advantages to be solved more apparent, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In various embodiments of the present application, it should be understood that the sequence numbers of the following processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Before introducing the technical scheme of the application, a brief description is given to a RocketMQ message queue or a QMQ message queue:

the RocketMQ transaction message is implemented by using the idea of Two-Phase-Commit (2 PC), and adds a compensation logic to process Two-Phase timeout or failure messages. The method comprises two processes, namely a normal transaction message sending and submitting process and a transaction message compensating process, and is explained in detail as follows:

(1) A transaction message (half message) is sent.

(2) And executing local transaction according to the sending result (if the writing fails, the half message is invisible to the service, and the local logic is not executed).

(3) The local transaction execution succeeds or fails.

(4) Commit (Commit) or Rollback (Rollback) is performed according to the local transaction state (Commit operations generate message indexes, messages visible to consumers).

(5) For transaction messages (waiting) without Commit/Rollback, a "check back" is initiated from the server.

(6) The Producer (Producer) receives the check-back message and checks the status of the transaction against a Database (DB).

(7) The Producer receives the transaction state returned by the DB.

(8) Either Commit or Rollback is re-executed depending on the local transaction state.

QMQ transaction message is realized by adopting the idea that a local operation and a message sending operation adopt the same DB instance together and combine the local operation and the message sending operation into one DB transaction,

further, the general implementation scheme of the QMQ transaction message is further described and is also divided into two flows, namely, the sending and submitting of the transaction message and the compensation flow of the transaction message. The detailed explanation is as follows:

1) And starting the local transaction.

2) And executing the business operation.

3) Messages are inserted into a homonymous MQ database (message database).

4) Transaction commit.

5) And sending a message to the MQ according to the local transaction execution result.

6) The message is deleted if the MQ server reply is successful.

7) And the compensation task scans the non-sent message in the message database.

8) And the compensation task compensation message sends the message to the MQ compensation.

9) The compensation task deletes the message that the compensation was successful.

In summary, the RocketMQ transaction message requires that the user must send a transaction message with a RocketMQ special tag, and implements a transaction listener for the RocketMQ to review the local transaction state, and the user must force a RocketMQ dependent transaction message mechanism. If the user uses other message queues such as Kafka, activeMQ, the transaction message scheme of the RocketMQ cannot be used to realize that the two actions of executing and messaging local transactions meet the transaction constraint.

QMQ transaction messages require that the user's local operations must be on one DB instance with the QMQ database, and that the local engineering needs to start the timing tasks newly, and that the single instance execution of the timing tasks is guaranteed, with a relatively large intrusion into the business DB and code.

The application provides a processing method and a processing device for transaction information of a message queue, which can ensure that two actions, namely execution and messaging of a local transaction, have transaction constraint under the condition that a user uses any message queue and does not depend on a transaction information mechanism of the message queue completely and business DB and codes are almost non-invasive.

Referring to fig. 1, an embodiment of the present application provides a method for processing a message queue transaction message, which is applied to an MQ proxy module (MQ proxy), including:

step 11, generating a first global transaction identifier according to a global transaction message sent by a first device, and sending the first global transaction identifier to the first device; the global transaction message includes a local transaction and a transaction that sent a message.

Here, the local transaction is defined as TX1, and the transaction that sends the message is defined as TX2. The first device is preferably a production end or producer.

The present application implements both local transactions and messaging operations with transaction constraints by means of relational database XA transactions (xatransactions). The XA specification is a distributed transaction processing (DTP, distributed Transaction Processing) standard defined by the X/Open organization, and the MySQL, oracle, postgreSQL, DB and like relational databases are both natively XA-transaction-capable.

A global transaction message sent by a first device is received, the global transaction message being a message sent by a producer to MQ proxy for initiating a global Transaction (TXG). The MQ proxy may generate a first global transaction identity, represented by XID, from the TXG message. The purpose of executing local transactions and sending messages can be achieved by this XID.

Step 12, obtaining first indication information sent by the first equipment; the first indication information carries a second global transaction identifier, and is used for indicating a state of the first device after the local transaction is executed.

In the embodiment of the application, the first indication information sent by the first device is obtained, so that the fact that the producer has executed the local transaction can be determined, and the second global transaction identifier carried by the first indication information can be used for executing the transaction for sending the message subsequently.

Here, the second global transaction identifier and the first global transaction identifier are XIDs, except that the first global transaction identifier is an XID that is directly generated from a global transaction message, and the XID is subsequently sent to the producer. The second global transaction identifier is XID carried in the first indication information sent by the first device. The second global transaction identity and the first global transaction identity are the same XID.

Step 13, generating second instruction information after executing the transaction of the sending message according to the second global transaction identifier, and sending the second instruction information to the first device; the second indication information is used for indicating a state after the Message Queue (MQ) agent module executes the transaction for sending the Message.

In the embodiment of the application, according to the second global transaction identifier, executing the transaction for sending the message, generating the second indication information after executing the transaction for sending the message, and sending the second indication information to the first device. The second indication information and the first indication information set the constraint of the transaction for the execution and the messaging of the local transaction.

On the other hand, after receiving the second instruction information, the producer executes the commit operation when determining that both are in a ready-to-succeed state, i.e. executing a successful result, according to the first instruction information and the second instruction information, and otherwise executes the rollback operation.

According to the technical scheme, the execution of the local transaction and the execution of the messaging can be ensured under the condition that a user uses any message queue and does not depend on a transaction message mechanism of the message queue, wherein the execution of the local transaction and the messaging are constrained by the first indication information and the second indication information, and the security of a service interaction process is ensured.

It should be noted that MQ proxy has the functions of opening global transaction, commit or rollback global transaction, forwarding message to message queue, and timeout global transaction alarm.

Optionally, step 11 includes:

according to the global transaction message sent by the first device, storing the global transaction message in a first preset transaction table in an MQ proxy database (MQ proxy DB); the first preset transaction table at least comprises primary key information and global transaction state information;

In the embodiment of the application, a global transaction message sent by a first device (producer) is received, that is, the producer requests the MQ proxy to start a global transaction TXG before sending the message; the MQ proxy stores the global transaction TXG information in the MQ proxy DB. The producer obtains the global transaction TXG information and saves the primary key generated in the MQ proxy DB as the global transaction identifier XID.

The MQ proxy stores global transactions to the MQ proxy DB, and it may also be understood that the MQ proxy inserts a row of records into a first preset transaction table (e.g., a t_global_tx global transaction table) in the MQ proxy DB, and detailed attributes and types of the t_global_tx global transaction table are defined as shown in table 1 below.

Table 1: detailed definition of t_global_tx global transaction table in MQ proxy DB

The first preset transaction table (t_global_tx global transaction table) at least comprises primary key information and global transaction state information.

Optionally, in step 13, generating the second indication information after executing the transaction of sending the message includes:

In the embodiment of the application, the producer sends a message to the MQ proxy, carrying the second global transaction identifier, namely the attached XID parameter. According to the second global transaction identifier, the MQ proxy opens a transaction TX2 for sending the message and executes a first preset flow; that is, a first execution SQL procedure is executed that saves the message for the MQ proxy and the operations that need to be performed to update the global transaction state. After executing the transaction TX2 for sending the message, a second indication is generated.

Accordingly, the producer may determine to subsequently perform a commit operation or a rollback operation according to the second indication message.

Optionally, in step 13, after generating the second indication information after executing the transaction for sending the message, the method provided by the present application further includes:

In the embodiment of the application, the execution results of the first indication information and the second indication information, namely the first execution result and the second execution result, are determined, and if the first execution result and the second execution result are both successful in execution, the commit operation is executed to the MQ proxy DB; and if at least one of the first execution result and the second execution result is the execution failure, executing rollback operation on the transaction corresponding to the execution failure. That is, when the first execution result is that the execution fails, a rollback request is sent to the producer, and the producer is requested to perform a rollback operation on the TX1 transaction; and when the second execution result is that the execution fails, performing a rollback operation to the MQ proxy DB. Through the constraint conditions, the safety of transaction interaction can be improved, and subsequent occurrence is prevented.

It should be noted that, when TX1 or TX2 is in the ready state (ready), the corresponding transaction PREPARE is successful, which means that the execution is successful, it is determined that the commit operation can be performed, otherwise, the rollback operation is performed.

Since the commit or rollback request is sent to the producer, there is a possibility that the producer will hang up and fail because of a timeout, and the retry will continue until the success. Optionally, when the MQ proxy database is abnormal, the method includes:

repeatedly executing submitting or rollback operation to the MQ proxy database, and continuously presetting retry time length;

the preset retry time length is configured or preconfigured by the MQ proxy module; the preset retry time length is smaller than the creation time length of the global transaction corresponding to the global transaction message.

In the embodiment of the application, when the MQ proxy DB is abnormal, such as the condition of hanging up and the condition of unsuccessful, the retry is also continuously performed, the submitting or rollback operation is repeatedly performed to the MQ proxy DB, and the retry duration is continuously preset; the preset retry period here is configured or preconfigured according to the MQ proxy. If the preset retry time is set to 1 hour, the method is carried out until the retry time is 1 hour later. For the global transaction TXG for which retry has been stopped, specifically, the global transaction creation time is longer than a preset retry time, for example, the preset retry time is 1 hour, the creation time exceeds 2 hours, 3 hours, and so on, and the creation time is also determined according to MQ proxy configuration and is longer than the preset retry time.

Further, the processing may be manually interfered with for the global transaction TXG that has stopped retrying, in particular, in the case where the global transaction creation time exceeds 2 hours, 3 hours, or the like, which still fails to be processed successfully.

In the embodiment of the application, after the commit operation is executed to the MQ proxy DB, the MQ proxy scans the undelivered target message in the MQ proxy DB, and the asynchronous task sends the target message to the MQ and asynchronously deletes the target message which has been successfully sent. The application only uses the basic function of sending the message to the message queue, and can ensure that the two actions of executing the local transaction and sending the message have transaction constraint under the condition that the system uses any message queue. The message sending method is realized in the MQ proxy according to the type of the message queue, so that the method is easy to adapt to any message queue, and the successful message sending and the successful message deleting are realized.

As the MQ proxy is designed to create the global transaction TXG to realize the transaction constraint on the transactions TX1 and TX2, the transaction message mechanism of the MQ is not relied on, and even if the MQ does not realize the transaction message, the MQ proxy designed by the scheme can enable the MQ to have the function of the transaction message.

In the process of sending the target message to the MQ asynchronously, it is also possible that the MQ proxy does not normally receive the response of successful receiving of the MQ, and the message is considered to be failed to be sent, or the message is sent to fail due to other reasons, so that the successfully sent message is sent repeatedly in an asynchronous task, and therefore, the consumer may be required to meet the deduplication function of the message.

Optionally, after the asynchronous sending of the target message to the MQ, the method further includes:

scanning for timeout transactions in the global transaction message;

sending alarm information to an MQ proxy monitor module (MQ proxy monitor); the MQ agent monitoring module is used for checking the global transaction state corresponding to the global transaction message according to the alarm information;

In the embodiment of the application, the overtime global transaction is scanned, the overtime time is determined according to the MQ proxy configuration, the alarm information is sent to the MQ proxy monitor, the MQ proxy monitor can check the execution state of the alarm global transaction, and if the global transaction is found to be unsuccessful in commit or rollback, the retry can be triggered manually. Here, the MQ proxy monitor has the functions of viewing global transactions for MQ proxy alarms and manually triggering retries of global transactions.

In the embodiment of the application, a message corresponding to a transaction for sending a message is inserted into a second preset transaction table (t_msg table) of the MQ proxy database, that is, a message corresponding to a transaction for sending a message is inserted into a t_msg table in the MQ proxy DB, such as a message identifier, a global transaction identifier, primary key information and message content of a first preset transaction table, which is the t_global_tx global transaction table described above. The second preset transaction table (t_msg table) is shown in table 2 below.

Table 2: detailed attributes and type definitions of the t_msg table.

The f_content attribute is the content of the message json after serialization, and the content of different message queues is different, and mainly comprises a message identifier (message id), a message header file (message topic), a message content and the like.

To further explain the processing procedure of the above method, the global transaction is defined as TXG, the local transaction is defined as TX1, the transaction for sending the message is defined as TX2, and the first device is the producer, and an interaction flow of the producer, the producer DB, the MQ proxy DB, the MQ proxy monitor, and the MQ is provided with reference to fig. 2. The detailed explanation is as follows:

1.1: before the producer sends the message, the MQ proxy is requested to open the global transaction TXG.

1.2: MQ proxy saves the global transaction TXG information into DB.

1.3: the producer obtains the global transaction TXG information and saves it into the DB generated primary key as global transaction XID.

1.4: the XID of the global transaction TXG is returned to the producer.

2.1: with XID of global transaction TXG, producer local transaction TX1 is started.

2.2: SQL is performed, where SQL is the operation that the producer local transaction TX1 needs to perform, and the number of SQL is not limited.

2.3: the local transaction TX1 is ended.

2.4: preparation local transaction TX1 waits for MQ proxy to call back to local transaction commit interface, and after XA transaction preparation succeeds, executing commit or rollback operation must succeed.

3.1: the producer sends a message to MQ proxy with the XID parameter attached.

3.2: with the XID of the global transaction TXG, MQ proxy turns on the transaction TX2 that sent the message.

3.3: SQL is executed, where SQL holds the message for the MQ proxy and the operations that need to be performed to update the global transaction state.

3.4: transaction TX2, which sent the message, is ended.

3.5: PREPARE sends transaction TX2 of the message.

3.6: the producer waits for a commit callback of MQ proxy in response to successful execution of transaction TX2 executing the send message.

4.1 to 4.6: the MQ proxy checks the status of the local transaction TX1 of the producer and the transaction TX2 of the message sent by the MQ proxy, and if both are PREPARED (the transaction PREPARED is successful), the commit operation is performed, otherwise the rollback operation is performed. Since 4.1 sends a commit/rollback request to the producer, there is a possibility that the producer will hang up and fail due to a timeout, and the retry will continue until successful. Step 4.5 may also be unsuccessful due to MQ proxy DB hanging up, and the retry may be continued until 1 hour after the retry (the retry duration is determined according to MQ proxy configuration). For the situation that the global transaction TXG that has stopped retrying, specifically, the global transaction creation time exceeds 2 hours, 3 hours, and so on (the length is also determined according to MQ proxy configuration and is greater than the retry duration) still fails to be processed successfully, step 6.1 scans out the global transaction that fails to be processed successfully to alarm, and requires manual intervention.

5.1: the asynchronous task scans for non-sent messages in the message database.

5.2: the asynchronous task sends a message to the MQ.

5.3: the asynchronous task deletes the message that was sent successfully.

6.1: the timeout global transaction is scanned and the timeout period is determined according to the MQ proxy configuration.

6.2: sending alarm information to the MQ proxy monitor, the MQ proxy monitor component can check the execution state of the global transaction of the alarm, and if the global transaction is found to be unsuccessful in commit/rollback, retry can be triggered manually.

According to the above interaction flow, the present application provides a specific embodiment, which can be applied in a mobile cloud specific service scenario, for example: in the mobile cloud hard disk ordering scene, after order service creation order is successful, a creation message needs to be sent to inform the cloud hard disk service, and then the order creation success and the creation message need to meet the constraint of a transaction, and finally, problems can be caused when any step is unsuccessful. The creation order may be considered a producer local transaction TX1 and the send message as transaction TX2 at this point. The global transaction formed by combining TX1 and TX2 is regarded as TXG, and the commit or rollback of the global transaction TXG is controlled by MQ proxy. The order service pseudocode using this scheme is as follows:

the 'createOrderAndSendMsg' method is to create an order and send a message, and is 1.1-3.6 steps of the producer in the interactive flow. The commit and rollback methods are callback interfaces provided by the producer for the MQ proxy, and commit and rollback capabilities are provided for the MQ proxy, corresponding to steps 4.1-4.4 in the interactive flow. Through the control of MQ proxy to TX1, TX2, the creation of orders and the transmission of messages are realized with transactional constraints.

In summary, the method of the present application can ensure that the two actions of executing and sending local transaction have transaction constraint under the condition that the user uses any one of the message queues and does not depend on the transaction message mechanism of the message queue.

Referring to fig. 3, an embodiment of the present application further provides a processing apparatus for a message queue transaction message, which is applied to a first device (such as a producer), and includes:

step 31, a global transaction message is sent to a message queue MQ proxy module (MQ proxy), and a first global transaction identifier sent by the global transaction message is received; the global transaction message includes a local transaction and a transaction that sent a message.

Here, the global transaction message is sent to MQ proxy in order to open the global transaction message and obtain the global transaction identification (XID) of the global transaction message.

Step 32, sending first indication information to the MQ proxy module; the first indication information carries a second global transaction identifier and is used for indicating a state of the first equipment after the local transaction is executed;

step 33, receiving second indication information sent by the MQ proxy module; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message;

And step 34, performing a commit or rollback operation to the first device database according to the first indication information and the second indication information.

In the embodiment of the application, the state of the producer after executing the local transaction is determined according to the first indication information after the producer executes the TX 1; according to the second indication information sent by the MQ proxy, determining the state that the MQ proxy has executed TX 2; and determining the states of the producer and the MQ proxy executing the transaction according to the first indication information and the second indication information, and then executing the commit or rollback operation to the first device database. According to the first indication information and the second indication information, the local transaction and the transaction item of the sent message are constrained, and the safety of subsequent interaction is improved.

Optionally, the method further comprises:

In the embodiment of the present application, according to the first global transaction identifier XID, the local transaction TX1 of the producer is started, and a second preset procedure, such as a second SQL procedure, is executed, where the second SQL is an operation that the local transaction TX1 of the producer needs to execute, and the number of the SQL is not limited. After execution is finished, the local transaction TX1 is finished, first indication information is generated, the first indication information is used for determining the state after the execution of TX1, and data support is provided for the subsequent judgment of the execution of commit or rollback operation of a producer.

Optionally, step 34 includes:

and when at least one of the first execution result and the second execution result fails to execute, executing rollback operation to the transaction corresponding to the execution failure.

In the embodiment of the application, the execution results of the first indication information and the second indication information, namely the first execution result and the second execution result, are determined, and if the first execution result and the second execution result are both successful in execution, the commit operation is executed to the MQ proxy DB; and if at least one of the first execution result and the second execution result is the execution failure, executing rollback operation to the transaction corresponding to the execution failure. If the first indication information indicates that the execution of the local transaction TX1 is successful, such as the preparation state, the local transaction commit interface is called back to the MQ proxy. If the first indication indicates that the execution of the local transaction TX1 is failed, the producer locally executes the rollback operation. And when the second execution result is that the execution fails, performing a rollback operation to the MQ proxy DB. Through the constraint conditions, the safety of transaction interaction can be improved, and subsequent occurrence is prevented.

In the embodiment of the application, the processing steps mainly relate to the interaction process of the producer and the MQ proxy, namely, how the producer executes local transactions according to the XID and constrains global transactions according to the first indication information and the second indication information, so that a user can use any message queue and the transaction message mechanism of the message queue is completely independent.

Referring to fig. 4, an embodiment of the present application provides a processing apparatus for a message queue transaction message, including:

the first processing module 41 is configured to generate a first global transaction identifier according to a global transaction message sent by a first device, and send the first global transaction identifier to the first device; the global transaction message comprises a local transaction and a transaction for sending the message;

a first obtaining module 42, configured to obtain first indication information sent by the first device; the first indication information carries a second global transaction identifier, and is used for indicating a state of the first equipment after the local transaction is executed;

A second processing module 43, configured to generate second instruction information after executing the transaction for sending the message according to the second global transaction identifier, and send the second instruction information to the first device; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message.

Optionally, the first processing module 41 includes:

the first processing unit is used for storing the global transaction message in a first preset transaction table in the MQ proxy database according to the global transaction message sent by the first device; the first preset transaction table at least comprises primary key information and global transaction state information;

and the second processing unit is used for storing the primary key information determined in the global transaction message as a first global transaction identifier.

Optionally, the second processing module 43 includes:

the third processing unit is used for starting the transaction for sending the message according to the second global transaction identifier and executing a first preset flow by the MQ proxy module; the first preset flow is the operation needed to be executed for the MQ proxy module to save the message and update the global transaction state;

And the fourth processing unit is used for generating the second indication information after the MQ proxy module executes the transaction for sending the message.

Optionally, the above processing device for message queue transaction message further includes:

the first determining module is used for determining a first execution result of the first device executing the local transaction and a second execution result of the MQ proxy module executing the transaction of the sent message according to the first indication information and the second indication information;

the fifth processing module is used for executing submitting operation to the MQ proxy database when the first execution result and the second execution result are successful in execution;

and the sixth processing module is used for executing rollback operation on the transaction corresponding to the execution failure when at least one of the first execution result and the second execution result fails.

and a seventh processing module, configured to scan the target message that is not sent by the MQ proxy database, asynchronously send the target message to the MQ, and asynchronously delete the target message that has been successfully sent.

An eighth processing module, configured to scan for a timeout transaction in the global transaction message;

a ninth processing module, configured to send alarm information to the MQ agent monitoring module; the MQ agent monitoring module is used for checking the global transaction state corresponding to the global transaction message according to the alarm information;

a tenth processing module, configured to repeatedly perform a commit or rollback operation to the MQ proxy database, and continuously preset retry duration;

Optionally, the second processing module 43 includes:

a fifth processing unit, configured to insert, into a second preset transaction table of the MQ proxy database, a message corresponding to the transaction that sends the message;

The implementation embodiments of the method for processing the transaction message of the message queue are applicable to the embodiment of the device for processing the transaction message of the message queue, and the same technical effects can be achieved.

Referring to fig. 5, an embodiment of the present application provides a processing apparatus for a message queue transaction message, including:

the third processing module 51 is configured to send a global transaction message to the message queue MQ proxy module, and receive a first global transaction identifier sent by the global transaction message; the global transaction message comprises a local transaction and a transaction for sending the message;

a first sending module 52, configured to send first indication information to the MQ proxy module; the first indication information carries a second global transaction identifier and is used for indicating a state of the first equipment after the local transaction is executed;

a first receiving module 53, configured to receive the second indication information sent by the MQ proxy module; the second indication information is used for indicating the state of the message queue MQ proxy module after executing the transaction of the sent message;

and a fourth processing module 54, configured to perform a commit or rollback operation to the first device database according to the first indication information and the second indication information.

an eleventh processing module, configured to, according to the first global transaction identifier, enable the local transaction by the first device, and execute a second preset flow; the second preset flow is an operation to be executed by the first device for executing the local transaction;

Optionally, the fourth processing module 54 includes:

a sixth processing unit, configured to determine, according to the first indication information and the second indication information, a first execution result of the first device to execute a local transaction, and a second execution result of the MQ proxy module to execute the transaction that sends the message;

a seventh processing unit, configured to execute a commit operation to the first device database when the first execution result and the second execution result are both successful;

and the eighth processing unit is used for executing rollback operation to the transaction corresponding to the execution failure when at least one of the first execution result and the second execution result fails.

The readable storage medium of the embodiment of the present application stores a program or an instruction, where the program or the instruction implements steps in a method for processing a transaction message of a message queue as described above when being executed by a processor, and the same technical effects can be achieved, and for avoiding repetition, a detailed description is omitted herein.

The processor is a processor in the method for processing the message queue transaction message in the above embodiment. The readable storage medium includes a computer readable storage medium such as a Read-Only Memory (ROM), a random access Memory (Random Access Memory RAM), a magnetic disk or an optical disk.

In an embodiment of the application, the modules may be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different bits which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Likewise, operational data may be identified within modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices.

Where a module may be implemented in software, taking into account the level of existing hardware technology, a module may be implemented in software, and one skilled in the art may, without regard to cost, build corresponding hardware circuitry, including conventional Very Large Scale Integration (VLSI) circuits or gate arrays, and existing semiconductors such as logic chips, transistors, or other discrete components, to achieve the corresponding functions. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

The exemplary embodiments described above are described with reference to the drawings, many different forms and embodiments are possible without departing from the spirit and teachings of the present application, and therefore, the present application should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete, and will convey the scope of the application to those skilled in the art. In the drawings, the size of the elements and relative sizes may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Unless otherwise indicated, a range of values includes the upper and lower limits of the range and any subranges therebetween.

While the foregoing is directed to the preferred embodiments of the present application, it will be appreciated by those skilled in the art that various modifications and adaptations can be made without departing from the principles of the present application, and such modifications and adaptations are intended to be comprehended within the scope of the present application.

Claims

1. A method for processing a message queue transaction message, comprising:

2. The method of claim 1, wherein generating the first global transaction identification from the global transaction message sent by the first device comprises:

3. The method of claim 1, wherein generating second indication information after executing the message-sent transaction based on the second global transaction identification comprises:

4. The method of claim 1, wherein after generating the second indication information after executing the message-sending transaction, the method further comprises:

5. The method as in claim 4, wherein after performing commit operations to the MQ proxy database, the method further comprises:

6. The method of claim 5, wherein after asynchronously sending the destination message to the MQ, the method further comprises:

scanning for timeout transactions in the global transaction message;

7. The method of claim 1, wherein the MQ proxy module, when executing the message-sending transaction, further comprises:

8. A method for processing a message queue transaction message, comprising:

9. The method of claim 8, wherein the method further comprises:

10. The method of claim 8, wherein performing a commit or rollback operation to a first device database based on the first indication information and the second indication information comprises:

and executing rollback operation to the transaction corresponding to the execution failure when at least one of the first execution result and the second execution result fails.

11. A message queue transaction message processing apparatus, comprising:

12. A message queue transaction message processing apparatus, comprising: