Transaction message delivery processing method, device and equipment and readable storage medium

Abstract

The invention relates to a transaction message delivery processing method and device, equipment and a readable storage medium. The method comprises the steps of determining a transaction message corresponding to completion of a business event under the condition that the business event on a first business system is completed; a message header of the transaction message carries a transaction identifier associated with the business event; service operation corresponding to the service event is used as a parameter to be transmitted to the transaction message sending method; under the condition that execution of the transaction message sending method is completed, a local transaction method is executed through the message middleware, service operation is executed, a transaction identifier is obtained, the transaction identifier is stored in a newly-added transaction table, and transaction identifier storage and service operation execution are placed in the same transaction; and delivering the transaction message to a second service system isolated from the first service system if the transaction identifier exists in the newly added transaction table under the condition that the execution of the local transaction method fails. By adopting the method, the reliability of transaction message delivery can be ensured.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction message delivery processing method, device, equipment and readable storage medium. Background Art

[0002] In scenarios such as resource transfer, message delivery needs to be guaranteed to be 100% delivered, otherwise it will cause resource loss. In order to prevent resource loss caused by message loss, the distributed messaging middleware RockeMQ provides transactional messages to ensure reliable message delivery.

[0003] The distributed messaging middleware RockeMQ transactional message provides the executeLocalTransaction method and the checkLocalTransaction method. The business logic is executed in executeLocalTransaction. If the executeLocalTransaction method returns RocketMQLocalTransactionState.COMMIT, it means that the transaction has been committed, and the message can be delivered. If this method returns RocketMQLocalTransactionState.ROLLBACK, the transaction has not been committed, and the message does not need to be delivered. When the message is delivered, check whether the data of the business operation is persisted to the data in checkLocalTransaction. If it has been persisted to the data, it is determined that the message needs to be delivered.

[0004] However, with the increase in business scenarios, it is necessary to check whether the data of business operations in each business scenario is persisted in the database to deliver messages. This method makes the message check operation cumbersome and misses the adaptation of the check. Summary of the invention

[0005] Based on this, it is necessary to provide a transaction message delivery processing method, apparatus, computer equipment, computer-readable storage medium and computer program product that can simplify the back-check operation and avoid omissions in the back-check configuration in order to solve the above technical problems.

[0006] In a first aspect, the present application provides a transactional message delivery processing method, including:

[0007] When a business event is completed on the first business system, determining a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event;

[0008] Passing the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and executing the method for sending a transaction message;

[0009] When the transaction message sending method is executed, a local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in a newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction;

[0010] In the case where the local transaction execution method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0011] In one embodiment, the business operation corresponding to the business event is passed as a parameter to a method for sending a transaction message, and the method for sending a transaction message is executed, including:

[0012] Determine the business operation corresponding to the business event;

[0013] The business logic corresponding to the business operation is encapsulated into a supplier function, and the supplier function is passed as a parameter of the method for sending a transaction message, and the method for sending a transaction message is executed.

[0014] In one embodiment, when the method for sending a transaction message is executed, executing a local transaction method through a message middleware, executing the business operation and obtaining the transaction identifier, and storing the transaction identifier in a newly added transaction table includes:

[0015] When the transaction message sending method is executed, the transaction message is sent to the message middleware server, and the local transaction method is executed by the message middleware of the message middleware server, and a transaction table is added;

[0016] The transaction identifier in the message header is obtained, the transaction identifier is saved in a newly added transaction table, and a supplier acquisition method is called to execute the business operation.

[0017] In one embodiment, when the execution of the local transaction method fails, if the transaction identifier exists in the newly added transaction table, delivering the transaction message to a second business system isolated from the first business system includes:

[0018] In the case where the local transaction execution method fails, generating a transaction checkback instruction;

[0019] In response to the check back instruction, a method for checking local transactions is called to identify the newly added transaction table and determine a target field of the newly added transaction table;

[0020] The field data corresponding to the target field is extracted, and if the transaction identifier exists in the field data, the transaction message is delivered to a second business system isolated from the first business system.

[0021] In one embodiment, the method further comprises:

[0022] When the transaction message is delivered successfully, the transaction identifier is deleted from the newly added transaction table.

[0023] In one embodiment, the method further comprises:

[0024] In the case where the execution of the local transaction method is successful, determining a return result of the execution of the local transaction method;

[0025] The transaction message is delivered or deleted according to the returned result.

[0026] In a second aspect, the present application further provides a transactional message delivery processing device, including:

[0027] A first processing module is used to determine, when a business event is completed on the first business system, a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event;

[0028] A second processing module is used to pass the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and execute the method for sending a transaction message;

[0029] A third processing module is used to execute a local transaction method through a message middleware, execute the business operation and obtain the transaction identifier, and store the transaction identifier in a newly added transaction table when the transaction message sending method is executed. The transaction identifier is stored and the business operation is executed in the same transaction.

[0030] A delivery module is used to deliver the transaction message to a second business system isolated from the first business system if the local transaction execution method fails and if the transaction identifier exists in the newly added transaction table.

[0031] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0032] When a business event is completed on the first business system, determining a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event;

[0033] Passing the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and executing the method for sending a transaction message;

[0034] When the transaction message sending method is executed, a local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in a newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction;

[0035] In the case where the local transaction execution method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0036] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0037] When a business event is completed on the first business system, determining a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event;

[0038] Passing the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and executing the method for sending a transaction message;

[0039] When the transaction message sending method is executed, a local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in a newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction;

[0040] In the case where the local transaction execution method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0041] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0042] When a business event is completed on the first business system, determining a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event;

[0043] Passing the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and executing the method for sending a transaction message;

[0044] When the transaction message sending method is executed, a local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in a newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction;

[0045] In the case where the local transaction execution method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0046] The above-mentioned transactional message delivery processing method, device, computer equipment, computer-readable storage medium and computer program product, when a business event is completed on the first business system, generates a transaction identifier associated with the business event, and puts the transaction identifier in the transaction message to be delivered, passes the business operation corresponding to the business event as a parameter to the sending transaction message method, and executes the sending transaction message method; when the sending transaction message method is executed, executes the local transaction method through the message middleware, executes the business operation and obtains the transaction identifier, and stores the transaction identifier in the newly added transaction table, wherein the saving of the transaction identifier and the execution of the business operation are placed in the same transaction; when the execution of the local transaction method fails, only Determine whether the transaction identifier of this transaction message exists in the local transaction table. If the transaction identifier exists in the newly added transaction table, it means that the transaction message has not been delivered, and the transaction message can be delivered to the second business system isolated from the first business system. In this way, when checking back, you only need to determine whether the transaction table has been stored in the database, whether the data has been stored in the database, and whether the status of the data meets the preset expectations. In other words, the local transaction table is used to optimize the reliable delivery of messages, determine whether messages need to be delivered based on the local transaction table, and reduce the intrusiveness of sending MQ to the business. That is, there is no need to strongly couple with the business logic, and only need to query the transaction table. This method improves the efficiency of checking back and ensures the reliability of transaction message delivery. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0048] Figure 1 An application environment diagram of a transaction message delivery processing method in one embodiment;

[0049] Figure 2A flowchart of a transaction message delivery processing method in one embodiment;

[0050] Figure 3 is a schematic flow chart of step 208 in one embodiment;

[0051] Figure 4 It is a flowchart of a transaction message delivery processing method in another embodiment;

[0052] Figure 5 It is an application schematic diagram of a transaction message delivery processing method in one embodiment;

[0053] Figure 6 It is a structural block diagram of a transaction message delivery processing device in one embodiment;

[0054] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0056] Rocketmq is a cloud-native messaging middleware, mainly used for real-time data processing. It covers cloud, edge, and end integrated data processing scenarios, and provides message, event, and stream processing capabilities.

[0057] In payment transaction scenarios, message delivery must be guaranteed to be 100% delivered, otherwise it will cause serious problems such as asset loss. In order to prevent asset loss caused by message loss, Rocketmq provides transactional messages to ensure reliable message delivery.

[0058] In business scenarios, when using transactional messages, Rocketmq provides two methods, executeLocalTransaction and checkLocalTransaction, to execute business logic in executeLocalTransaction. If this method returns RocketMQLocalTransactionState.COMMIT, it means that the transaction has been committed, and the message can be delivered. If this method returns RocketMQLocalTransactionState.ROLLBACK, the transaction has not been committed and the message does not need to be delivered. If the application is suddenly interrupted and does not return, Rocketmq will call back checkLocalTransaction. In this method, it will check whether the data of our business operations is persisted in the data, so as to determine whether the message needs to be delivered.

[0059] However, the above delivery method has the following problems: in checkLocalTransaction, we need to check whether the data of business operations is persisted in the data. As the number of business scenarios increases, the data needs to be persisted in the corresponding business tables (for example, transactions may include collection, refund, recall, withdrawal, etc.). In this method, we need to check the tables that need to be persisted for different businesses. As the number of businesses increases, different business tables need to be checked. Then, we need to use specific identifiers to determine which business table needs to be checked, which forcibly couples the business logic. In addition, some businesses need to push messages when the state machine of the business changes. In this scenario, we need to checkLocalTransaction to determine whether the state of the table we check meets our expectations, so as to determine whether the message needs to be pushed. As the state machine of the business increases or the state flow changes, the state we expect is also changing and needs to be constantly modified, which is strongly coupled with the business logic. In addition, in checkLocalTransaction, some tables have large data, and the efficiency of the check may be slightly affected.

[0060] Since the above problems will cause the review operation to be seriously coupled with the business logic, and in order to confirm whether the message can be delivered, we need to pay attention to whether the data processed by the business logic is the data value we expect when sending the message. Therefore, in order to solve the technical problem of cumbersome message review operations and omitted adaptation of review, a new transaction table is added. When the business operation persists the data, a transaction table is saved at the same time (in the same transaction). When we review, we only need to determine whether our transaction table has been stored in the database to determine whether our data has been stored in the database. By introducing a transaction log table to record the transaction status, we can simplify the transaction review process of RocketMQ, reduce the dependence on business logic, and ensure the reliability of transaction message delivery.

[0061] The transactional message delivery processing method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the message delivery initiator 102 communicates with the message receiving terminal 104 through the network. The data storage system can store the data that the message delivery initiator 102 needs to process. The data storage system can be integrated on the message delivery initiator 102, or it can be placed on the cloud or other network servers. When the business event on the first business system is completed, the message delivery initiator 102 determines the transaction message corresponding to the completion of the business event; the message header of the transaction message carries the transaction identifier associated with the business event; the business operation corresponding to the business event is passed as a parameter to the sending transaction message method, and the sending transaction message method is executed; when the sending transaction message method is executed, the local transaction method is executed through the message middleware, the business operation is executed and the transaction identifier is obtained, and the transaction identifier is stored in the newly added transaction table, wherein the saving of the transaction identifier and the execution of the business operation are placed in the same transaction; when the execution of the local transaction method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to the second business system of the message receiving terminal 104 isolated from the first business system.

[0062] Among them, the message delivery initiator 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The message receiving end 104 can be but is not limited to various personal computers, laptops, smart phones, tablets, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car-mounted devices, projection equipment, etc.

[0063] In an exemplary embodiment, Figure 2 As shown, a transactional message delivery processing method is provided, and the method is applied to Figure 1 Taking the message delivery initiator in the example as an example, the method includes the following steps 202 to 206. Among them:

[0064] Step 202: When a business event is completed on the first business system, a transaction message corresponding to the completion of the business event is determined; a message header of the transaction message carries a transaction identifier associated with the business event.

[0065] Exemplarily, when a business event is completed on the first business system, it is necessary to call rocketmq to send the corresponding transaction message using the sendMessageInTransaction provided, generate a unique transaction identifier txId associated with the business event, and put the transaction identifier txId into the message header to be delivered.

[0066] Among them, RockeMQ (Apache RocketMQ), RocketMQ is an open source distributed message middleware that supports high throughput, high reliability message delivery, and has the characteristics of low latency. RocketMQ is suitable for large-scale message flow processing, supports publish-subscribe mode and queue mode, and is widely used in various scenarios such as big data processing, financial transactions, and log collection. The transaction message can be a notification message of the completion of a business event on the first business system. For example, after the order event on the order system is completed, this completion message needs to be delivered to the warehousing system so that the warehousing system can update the product information accordingly based on the message to keep the data consistent.

[0067] Step 204: pass the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and execute the method for sending a transaction message.

[0068] The business operation may be a business data storage operation corresponding to the business event. The parameter passed to the method for sending a transaction message may be: encapsulating the business logic corresponding to the business operation into a supplier function, and passing the supplier function as a parameter of the method for sending a transaction message, that is, abstracting the business logic into a Supplier function and passing it as a parameter of sendMessageInTransaction.

[0069] It can be understood that the two-phase commit of transactional messages: RocketMQ transactional messages use two-phase commit to ensure the atomicity of message sending and local transactions. In the first phase, the message is sent to the message service queue node Broker in the form of a "semi-transactional message" (that is, the producer sends the message to the RocketMQ server. This message is marked as "cannot be delivered yet" and is a semi-transactional message). At this time, the message is not visible to the consumer. In the second phase, based on the execution result of the local transaction, the producer submits a Commit or Rollback instruction to the Broker, and the Broker decides whether to mark the message as deliverable or delete the message. This mechanism ensures the reliable delivery of messages.

[0070] Optionally, in an exemplary embodiment, the business operation corresponding to the business event is passed as a parameter to the method for sending a transaction message, and the method for sending a transaction message is executed, including: determining the business operation corresponding to the business event; encapsulating the business logic corresponding to the business operation into a supplier function, passing the supplier function as a parameter of the method for sending a transaction message, and executing the method for sending a transaction message. That is, when RocketMQ uses sendMessageInTransaction to send a message, we generate a unique txId and put it into the header of the message to be delivered, and the business logic to be executed can be abstracted into a Supplier function and passed as a parameter of sendMessageInTransaction.

[0071] Exemplarily, the business operation corresponding to the business event is abstracted into a Supplier function and passed as a parameter of sendMessageInTransaction. After the sendMessageInTransaction method is executed, it indicates that the message has been sent to the MQ server, but the message will not be pushed to the consumer at this time.

[0072] Step 206, when the transaction message sending method is executed, the local transaction method is executed through the message middleware, the business operation is executed and the transaction identifier is obtained, and the transaction identifier is stored in the newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction.

[0073] Optionally, in an exemplary embodiment, when the execution of the method of sending a transaction message is completed, the transaction message is sent to a message middleware server, and a local transaction method is executed through the message middleware of the message middleware server, and a new transaction table is added; the transaction identifier in the message header is obtained, the transaction identifier is saved in the newly added transaction table, and the supplier acquisition method is called to execute the business operation.

[0074] That is, after the sendMessageInTransaction method is executed, it indicates that the message has been sent to the MQ server, but the message will not be pushed to the consumer at this time. RocketMQ will go back to execute the executeLocalTransaction method. ExecuteLocalTransaction will accept the message and Supplier function we delivered. In this method, you can get the txId in the message header, and you can use the same call to the supplier to get the method Supplier.get() to perform business operations. You can start a transaction, save the txId and execute business operations in the same method to ensure success or failure at the same time, so as to determine whether the message needs to be delivered.

[0075] Exemplarily, when the execution of the transaction message sending method is completed, the message middleware rocketmq goes back to execute the local transaction method executeLocalTransaction, that is, executes the local transaction method through the message middleware, executes the business operation and obtains the transaction identifier, and stores the transaction identifier in the newly added transaction table, where the newly added transaction table is a local transaction table, and the transaction identifier and the execution of the business operation are placed in the same transaction. This method ensures that the message delivery and data storage are successful or failed at the same time, so as to determine whether the message needs to be delivered.

[0076] Step 208: When the local transaction method fails to execute, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0077] It should be noted that in a distributed system, ensuring the consistency of message sending and local transactions is a challenge. If the lookback method cannot accurately reflect the business status, it may cause transaction consistency issues, such as message duplication or loss. This is especially true in high-concurrency scenarios, with frequent business logic changes and data cleanup requirements.

[0078] Exemplarily, when the execution of the local transaction method fails, the local transaction table is checked back. If the transaction identifier exists in the newly added transaction table, it indicates that the corresponding business data has been stored in the database, and the transaction message is delivered to a second business system isolated from the first business system.

[0079] The above transactional message delivery processing method generates a transaction identifier associated with the business event when the business event is completed on the first business system, and puts the transaction identifier in the transaction message to be delivered, passes the business operation corresponding to the business event as a parameter to the sending transaction message method, and executes the sending transaction message method; when the sending transaction message method is executed, the local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in the newly added transaction table, wherein the saving of the transaction identifier and the execution of the business operation are placed in the same transaction; when the execution of the local transaction method fails, it is only necessary to determine whether the local transaction table contains this transaction identifier. The transaction identifier of a transaction message. If the transaction identifier exists in the newly added transaction table, it is known that the transaction message has not been delivered, and the transaction message can be delivered to a second business system isolated from the first business system. In this way, when checking back, you only need to determine whether the transaction table has been stored in the database, whether the data has been stored in the database, and whether the data status meets the preset expectations. In other words, the local transaction table is used to optimize the reliable delivery of messages, determine whether messages need to be delivered based on the local transaction table, and reduce the intrusiveness of sending MQ to the business. That is, there is no need to strongly couple with the business logic, and only need to query the transaction table. This method improves the efficiency of checking back and ensures the reliability of transaction message delivery.

[0080] In an exemplary embodiment, Figure 3 As shown, step 208 includes steps 302 to 306 .

[0081] in:

[0082] Step 302: When the local transaction method fails to execute, a transaction backcheck instruction is generated.

[0083] Step 304, in response to the check back instruction, calling the check local transaction method, identifying the newly added transaction table, and determining the target field of the newly added transaction table.

[0084] The newly added transaction table may be a table that only includes the transaction identifier, and the target field is a field corresponding to the transaction identifier.

[0085] Step 306: extract the field data corresponding to the target field, and if the field data contains a transaction identifier, deliver the transaction message to a second business system isolated from the first business system.

[0086] In this embodiment, by introducing a transaction table to record the transaction status, the transaction review process of RocketMQ can be simplified and the dependence on business logic can be reduced. Moreover, the transaction table can be a table that only includes transaction identifiers, which improves query efficiency and ensures query reliability.

[0087] Optionally, in an exemplary embodiment, the transactional message delivery processing method further includes: when the transactional message is successfully delivered, deleting the transaction identifier from the newly added transaction table. This method does not couple the business logic when delivering transactional messages, and the transaction table can be cleaned up in the RocketMQ back-check method at the same time.

[0088] Optionally, in an exemplary embodiment, the transactional message delivery processing method further includes: when the local transaction method is executed successfully, determining the return result of executing the local transaction method; and performing delivery processing or deletion processing on the transaction message according to the return result.

[0089] For example, when the local transaction method executeLocalTransaction is executed successfully, if this method returns RocketMQLocalTransactionState.COMMIT, it means that the transaction has been committed and the message can be delivered. If this method returns RocketMQLocalTransactionState.ROLLBACK, the transaction has not been committed, the message does not need to be delivered, and it is deleted. This method can prevent asset loss caused by message loss. RocketMQ provides transactional messages to ensure reliable message delivery.

[0090] In an exemplary embodiment, Figure 4 As shown, a transactional message delivery processing method is provided, and the method is applied to Figure 1 Taking the message delivery initiator in the example as an example, the method includes the following steps 402 to 412. Among them:

[0091] Step 402: When a business event is completed on the first business system, a transaction message corresponding to the completion of the business event is determined; a message header of the transaction message carries a transaction identifier associated with the business event.

[0092] Step 404: pass the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and execute the method for sending a transaction message.

[0093] Step 406, when the transaction message sending method is executed, the local transaction method is executed through the message middleware, the business operation is executed and the transaction identifier is obtained, and the transaction identifier is stored in the newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction.

[0094] Step 408: When the local transaction method fails to execute, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

[0095] Step 410, when the local transaction method is successfully executed, determine the return result of executing the local transaction method.

[0096] Step 412: Deliver or delete the transaction message according to the returned result.

[0097] It can be understood that the specific implementation of this embodiment can be achieved through the above-mentioned limitation method, which will not be elaborated here.

[0098] The following is the application environment of the transactional message delivery processing method, such as Figure 5 As shown, it includes local transactions, MQ senders, MQ servers and MQ subscribers. When the business event is completed on the first business system, the MQ sender needs to call rocketmq to use the sendMessageInTransaction provided to send the corresponding transaction message, generate a unique transaction identifier txId associated with the business event, and put the transaction identifier txId into the message header to be delivered. The business logic to be executed is abstracted into a Supplier function and passed as a parameter of sendMessageInTransaction. When the transaction message sending method is executed, the sendMessageInTransaction method indicates that the message has been sent to the MQ server. Rocketmq then goes back to execute the executeLocalTransaction method. ExecuteLocalTransaction will accept the message and Supplier function we delivered, and store the transaction identifier in the newly added transaction table. The transaction identifier and the execution of business operations are saved in the same transaction.

[0099] In the event that the execution of the local transaction method fails, that is, no return value is received, a transaction backcheck is performed to determine whether there is a transaction identifier in the newly added transaction table. If so, the return result of executing the local transaction method is determined; based on the return result, the transaction message is delivered or deleted, that is, the transaction message is delivered to a second business system isolated from the first business system, or the transaction message is deleted.

[0100] When the local transaction method is successfully executed, the return result of the local transaction method is directly determined; and the transaction message is delivered or deleted according to the return result.

[0101] In this embodiment, compared with the prior art, the RocketMQ back-check method constantly adapts to the impact of business changes, is forcibly coupled with business logic, and business data cannot be cleaned up. It is necessary to implement RocketMQ back-checking without intrusion into the business. By adding a transaction table, when the business operation persists the data, a transaction table is saved at the same time, so that in the same transaction, when the execution fails, when back-checking, it is only necessary to determine whether the transaction table has been dropped in the library to determine whether the business data has been dropped in the library, and it is not necessary to determine whether the state of the data meets the preset expectations, and it is also not coupled with the business logic. In the RocketMQ back-checking method, the transaction table can be cleaned up at the same time, and only a small number of fields such as transaction identifiers can be controlled. The IO volume is based on the local transaction table to determine whether the message needs to be delivered and reduce the intrusion of sending MQ to the business, that is, it does not need to be strongly coupled with the business logic, and only the transaction table needs to be queried. This method improves the efficiency of back-checking and ensures the reliability of transaction message delivery. Further, when back-checking, the business logic is not coupled, and the MQ message sending is not affected when the business changes.

[0102] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0103] Based on the same inventive concept, the embodiment of the present application also provides a transactional message delivery processing device for implementing the transactional message delivery processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of the delivery processing device for one or more transactional messages provided below can refer to the limitations of the transactional message delivery processing method above, and will not be repeated here.

[0104] In an exemplary embodiment, Figure 6 As shown, a transactional message delivery processing device is provided, including: a first processing module 602, a second processing module 604, a third processing module 606 and a delivery module 608, wherein:

[0105] The first processing module 602 is used to determine a transaction message corresponding to the completion of the business event when the business event is completed on the first business system; the message header of the transaction message carries a transaction identifier associated with the business event.

[0106] The second processing module 604 is used to pass the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and execute the method for sending a transaction message.

[0107] The third processing module 606 is used to execute the local transaction method through the message middleware, execute the business operation and obtain the transaction identifier, and store the transaction identifier in the new transaction table when the transaction message sending method is completed, wherein the transaction identifier is saved and the business operation is executed in the same transaction.

[0108] The delivery module 608 is used to deliver the transaction message to a second business system isolated from the first business system if the local transaction method fails to execute and if there is a transaction identifier in the newly added transaction table.

[0109] The above-mentioned transactional message delivery processing device, when the business event is completed on the first business system, generates a transaction identifier associated with the business event, and puts the transaction identifier in the transaction message to be delivered, and passes the business operation corresponding to the business event as a parameter to the method of sending the transaction message; in the case of failure to execute the local transaction method, it is only necessary to determine whether the transaction identifier of the transaction message exists in the local transaction table. If the transaction identifier exists in the newly added transaction table, it is known that the transaction message has not been delivered, and the transaction message can be delivered to the second business system isolated from the first business system. In this way, when performing a backcheck, it is only necessary to determine whether the transaction table has been stored in the database, whether the data has been stored in the database, and whether the status of the data meets the preset expectations. In other words, the local transaction table is used to optimize the message reliability delivery, determine whether the message needs to be delivered based on the local transaction table, and reduce the intrusiveness of sending MQ to the business, that is, there is no need to be strongly coupled with the business logic, and only the transaction table needs to be queried. This method improves the backcheck efficiency and ensures the reliability of transaction message delivery.

[0110] In an exemplary embodiment, the second processing module 604 is also used to determine the business operation corresponding to the business event; encapsulate the business logic corresponding to the business operation into a supplier function, pass the supplier function as a parameter of the method of sending a transaction message, and execute the method of sending a transaction message.

[0111] In an exemplary embodiment, the third processing module 606 is also used to send the transaction message to the message middleware server when the transaction message sending method is executed, execute the local transaction method through the message middleware of the message middleware server, add a new transaction table; obtain the transaction identifier in the message header, save the transaction identifier in the newly added transaction table, and call the supplier acquisition method to execute the business operation.

[0112] In an exemplary embodiment, the delivery module 608 is also used to generate a transaction back-check instruction when the execution of the local transaction method fails; in response to the back-check instruction, call the local transaction method to identify the newly added transaction table and determine the target field of the newly added transaction table; extract the field data corresponding to the target field, and if the transaction identifier exists in the field data, deliver the transaction message to a second business system isolated from the first business system.

[0113] In an exemplary embodiment, the transactional message delivery processing device further includes a deletion module, where the deletion module is configured to delete the transaction identifier from the newly added transaction table when the transactional message is successfully delivered.

[0114] In an exemplary embodiment, the delivery module 608 is also used to determine the return result of executing the local transaction method when the local transaction method is executed successfully; and perform delivery processing or deletion processing on the transaction message according to the return result.

[0115] Each module in the transactional message delivery processing device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0116] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 7As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (Near Field Communication, NFC) or other technologies. When the computer program is executed by the processor, a method for delivering and processing transactional messages is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0117] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0118] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0119] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0120] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0121] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0122] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0123] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0124] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A transactional message delivery processing method, characterized in that: The method comprises: When a business event is completed on the first business system, determining a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event; Passing the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and executing the method for sending a transaction message; When the transaction message sending method is executed, a local transaction method is executed through the message middleware to execute the business operation and obtain the transaction identifier, and the transaction identifier is stored in a newly added transaction table, wherein the transaction identifier is saved and the business operation is executed in the same transaction; In the case where the local transaction execution method fails, if the transaction identifier exists in the newly added transaction table, the transaction message is delivered to a second business system isolated from the first business system.

2. The method according to claim 1, characterized in that The business operation corresponding to the business event is passed as a parameter to the method for sending a transaction message, and the method for sending a transaction message is executed, including: Determine the business operation corresponding to the business event; The business logic corresponding to the business operation is encapsulated into a supplier function, and the supplier function is passed as a parameter of the method for sending a transaction message, and the method for sending a transaction message is executed.

3. The method according to claim 2, characterized in that When the transaction message sending method is executed, the local transaction method is executed through the message middleware, the business operation is executed and the transaction identifier is obtained, and the transaction identifier is stored in the newly added transaction table, including: When the transaction message sending method is executed, the transaction message is sent to the message middleware server, and the local transaction method is executed by the message middleware of the message middleware server, and a transaction table is added; The transaction identifier in the message header is obtained, the transaction identifier is saved in a newly added transaction table, and a supplier acquisition method is called to execute the business operation.

4. The method according to any one of claims 1 to 3, characterized in that: In the case where the execution of the local transaction method fails, if the transaction identifier exists in the newly added transaction table, delivering the transaction message to a second business system isolated from the first business system includes: In the case where the local transaction execution method fails, generating a transaction checkback instruction; In response to the check back instruction, a method for checking local transactions is called to identify the newly added transaction table and determine a target field of the newly added transaction table; The field data corresponding to the target field is extracted, and if the transaction identifier exists in the field data, the transaction message is delivered to a second business system isolated from the first business system.

5. The method according to claim 1, characterized in that The method further comprises: When the transaction message is delivered successfully, the transaction identifier is deleted from the newly added transaction table.

6. The method according to claim 1, characterized in that The method further comprises: In the case where the execution of the local transaction method is successful, determining a return result of the execution of the local transaction method; The transaction message is delivered or deleted according to the returned result.

7. A transactional message delivery processing device, characterized in that: The device comprises: A first processing module is used to determine, when a business event is completed on the first business system, a transaction message corresponding to the completion of the business event; a message header of the transaction message carries a transaction identifier associated with the business event; A second processing module is used to pass the business operation corresponding to the business event as a parameter to the method for sending a transaction message, and execute the method for sending a transaction message; A third processing module is used to execute a local transaction method through a message middleware when the transaction message sending method is executed, execute the business operation and obtain the transaction identifier, and store the transaction identifier in a newly added transaction table, wherein the transaction identifier is stored and the business operation is executed in the same transaction; A delivery module is used to deliver the transaction message to a second business system isolated from the first business system if the local transaction execution method fails and if the transaction identifier exists in the newly added transaction table.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images