A solution method based on Seata, RabbitMQ integration distributed transaction and multi-tenant consumption

Abstract

The application relates to the technical field of Internet application, in particular to a solution method for integrating distributed transactions and multi-tenant consumption based on Seata and RabbitMQ, wherein a master control plays an initiator based on Seata, adopts an AT transaction mode, takes Redis as a transaction message carrier to improve high-performance transaction processing, the master control starts a global transaction, generates an XID, uniformly stores the XID into a header when a feign call is made, and each microservice is bound to the XID through a filter situation; the solution method has the beneficial effects that: the solution method for integrating distributed transactions and multi-tenant consumption based on Seata and RabbitMQ temporarily stores transaction messages in Redis and marks the transaction messages as a state of 'temporary non-deliverable', the transaction messages cannot be consumed by a consumer, after the server receives a commit or rollback response of the global transaction of Seata to the message, the message is normally delivered to a corresponding tenant queue for consumption or rollback (discarding) of the message.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of Internet application, and in particular to a solution of Seata and RabbitMQ integrated distributed transaction and multi-tenant consumption. BACKGROUND

[0002] At present, with the continuous change and rapid response of the cost control management demand of brand merchants in the fast-consumption industry, the application of small-scale, single or traditional technology cannot meet the demand change, and the micro-service architecture system generated by the application has a business middle platform as the base and provides services for the upper Saas service, and each micro-service has its own unique database; for example, the cost control system has multiple micro-services such as master control, dynamic control, account center, workflow and message service, and each micro-service sends different messages to RabbitMQ to consume business data.

[0003] In the prior art, the Seata distributed transaction and the RabbitMQ message middleware exist integration problems, which are difficult to guarantee the accuracy, efficiency, easy expansion and reduction of business code modification of the transaction, and are not conducive to guaranteeing the accuracy of business data. SUMMARY

[0004] The application aims to provide a solution of Seata and RabbitMQ integrated distributed transaction and multi-tenant consumption to solve the problems in the background technology.

[0005] To achieve the above-mentioned purpose, the application provides the following technical scheme: a solution of Seata and RabbitMQ integrated distributed transaction and multi-tenant consumption, which comprises the following steps:

[0006] The master plays the role of initiator based on Seata, adopts the AT transaction mode, and uses Redis as a transaction message carrier to improve the high-performance transaction processing.

[0007] The master starts a global transaction and generates an XID, and when calling feign, the XID is uniformly stored in the header, and each micro-service is bound to the xid through a filter.

[0008] Different exchange machines corresponding to different business messages are created, and each exchange machine corresponds to multiple queues.

[0009] Preferably, when the master plays the role of initiator based on Seata, adopts the AT transaction mode, and uses Redis as a transaction message carrier to improve the high-performance transaction processing, the method further comprises the following steps:

[0010] The information is pushed to a transaction coordinator service to realize registration of transaction messages, and global transaction information, branch transaction information and lock information are recorded to realize registration of transaction messages; the initiator related service realizes registration of transaction messages to the transaction coordinator service, registers transaction related messages and generates a business SQL to generate an undolog log and store it in a database of the participant microservice.

[0011] Preferably, the master starts a global transaction, generates an XID, and stores the XID in the header when calling feign, and when the respective microservice binds the xid through a filter, it also includes:

[0012] In terms of business, each participant sends its own message to a temporary queue according to business requirements, the temporary queue uses Redis storage, takes XID as the primary key, and stores each pushed message in a LIST object collection, including the actual queue information of MQ and the message content; once the transaction coordinator TC initiates a unified transaction submission, the message will be marked with XID, read the temporary queue data, parse it, obtain the actual queue and message content, migrate the temporary queue message data to the actual queue as the target, and migrate the data to the actual queue; after successful migration, the message in the Redis cache is uniformly deleted and cleaned; once the participant fails due to business or system errors, the transaction coordinator TC initiates a rollback of the transaction to the participant, and the message is marked with XID, and the message in the Redis temporary queue is uniformly deleted and cleaned.

[0013] Preferably, different exchanges corresponding to different business messages are created, and each exchange corresponds to multiple queues, and further includes:

[0014] The queue name adopts a business message + tenant internal code mode, and the queue realizes dynamic creation of an interface when creating a tenant; when the business message is switched from the temporary queue to the actual queue, the corresponding queue is found through the tenant internal code and the business module to realize the message pushing and migration operation, and the message server adopts dynamic consumption listening, that is, a corresponding message consumption service is established for each business message, and the corresponding business consumption operation is realized through the tenant internal code.

[0015] Compared with the prior art, the present application has the following advantages:

[0016] The application provides a solution method for integrating distributed transactions and multi-tenant consumption based on Seata and RabbitMQ, temporarily stores transaction messages in Redis and marks them as "temporary undeliverable" state, which will not be consumed by the consumer, and after the server receives the commit or rollback response of the global transaction of Seata to the message, the message will be normally delivered to the corresponding tenant queue for consumption or rollback (discard) message. It is used to solve the problem that after multiple push messages are pushed to the MQ in the distributed transaction, the transaction rollback causes redundant data on the consumer side, resulting in dirty read of data; solve the integration problem of distributed transaction Seata and message middleware RabbitMQ, which guarantees the accuracy, efficiency, easy expansion and reduction of business code modification of the transaction, and is beneficial to guarantee the accuracy of business data. BRIEF DESCRIPTION OF DRAWINGS

[0017] Fig. 1 It is a master control approval flowchart of the application;

[0018] Fig. 2 It is a transaction processing flowchart of the application;

[0019] Fig. 3 It is a master control global transaction starting flowchart of the application;

[0020] Fig. 4 It is a switch queuing schematic diagram of the application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical scheme of the application clear, complete and the advantages more clear and obvious, the embodiments of the application are further described in detail below with reference to the drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the application, not all embodiments, and are only used to explain the embodiments of the application, and do not limit the embodiments of the application. All other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0022] Embodiment one

[0023] The application provides a technical solution: a solution method for integrating distributed transactions and multi-tenant consumption based on Seata and RabbitMQ, the method comprising the following steps:

[0024] The master control plays the role of initiator based on Seata, adopts AT transaction mode, and uses Redis as transaction message carrier to improve high-performance transaction processing;

[0025] The master control starts a global transaction, generates XID, and stores XID in header when calling feign, and each microservice realizes binding of xid through filter.

[0026] Different corresponding switches are created for different service messages, and each switch corresponds to multiple queues.

[0027] Embodiment two

[0028] Please refer to Figs. 1 to 4 On the basis of embodiment one, the specific implementation manner is:

[0029] To solve the global transaction problem of master control, dynamic branch control, message and other microservices, the open source distributed transaction framework Seata is introduced, and it is also consistent with the message transaction in RabbitMQ. In order to ensure timeliness, Redis is introduced as a temporary storage of semi-message. A unified integrated development framework mode based on Spring Cloud+Seata+Redis+RabbitMQ is adopted, and four modules are responsible for their respective duties:

[0030] The master is responsible for the scheduling and control of the approval process of the fee control system. Through the feign calling mode, the integration management of dynamic branch control, workflow and message service is realized, that is, the initiator of the main transaction is realized. Dynamic branch control includes business form dynamic control, storage and integration with account center, that is, form display rules related to business are formulated, such as form structure, form basic information, item level fee type and corresponding extension attributes and extension files, sub-item fee items and extension attributes and file attributes, and column branch rules and workflow processes; Workflow is responsible for the reversal of the approval process, that is, online designation of approval process links, setting of participants, formulation of account center related business operations, branch conditions and control display of each link domain, etc.; Message service is responsible for pushing service messages to RabbitMQ, which is used to push workflow event messages, data center data messages and send short message reminder messages, etc.; The overall global distributed transaction management is based on Seata, and the storage mode of Redis is adopted to provide overall efficiency; The message service pushes the message to RabbitMQ, which adopts the temporary queue and actual queue mode, that is, when the global transaction of Seata is in the state of waiting for submission, the message service stores the message in the temporary queue of RabbitMQ, and once the main transaction is submitted, the message in the temporary queue is migrated to the actual queue of the corresponding tenant, realizing the normal consumption of the message; Once the main transaction is rolled back, the message is cleaned up and deleted from the temporary queue, ensuring the accuracy of message pushing and preventing data dirty read;

[0031] A, the master control based on Seata plays the role of initiator, which adopts the AT transaction mode and uses Redis as a transaction message carrier to improve high-performance transaction processing; the dynamic branch control, workflow and message service play the role of participants; the initiator (master control) is responsible for starting a global transaction, using the global transaction unique XID as the unique identifier of the transaction, and the feign calls received by each submodule are uniformly bound based on XID to ensure the consistency of the XID of the distributed transaction; the information is pushed to the transaction coordinator (server) to realize the registration of transaction messages, and the global transaction information, branch transaction information and lock information are recorded to realize the registration of transaction messages; the initiator related service also realizes the registration of transaction messages to the transaction coordinator (server), registers transaction related messages, and generates business SQL undolog logs and stores them in the database of the participant microservice; once the initiator and the participant microservice do not have business and system exceptions, the transaction coordinator will notify each participant, get the corresponding undolog log with XID as the identifier, and realize global transaction submission; once the initiator and the participant microservice have one party business or system exception, the transaction coordinator will notify each participant, get the corresponding undolog log with XID as the identifier, and perform cleaning and rollback operation;

[0032] B, the master control starts a global transaction and generates XID, which is uniformly stored in the header when calling feign, and each microservice is bound to xid through a filter to ensure the consistency of transaction XID, that is, to realize the transaction initiation between the initiator and the participant; in terms of business, each participant sends its own message to the temporary queue according to business needs, and the temporary queue uses Redis storage, which uses XID as the primary key, and each pushed message is uniformly stored in the LIST object collection, which contains the actual queue information, message content, etc. of MQ; once the transaction coordinator (TC) initiates unified transaction submission, the message will be marked with XID to read the temporary queue data, parse it, get the actual queue and message content, and migrate the temporary queue message data to the actual queue as the target, and after successful migration, the message in the Redis cache is uniformly deleted and cleaned; once the participant has business or system error, the transaction coordinator (TC) will initiate transaction rollback to the participant, and the message will be marked with XID to uniformly delete and clean the message in the Redis temporary queue.

[0033] C. Different corresponding switches are created for different service messages, each switch corresponds to multiple queues, that is, one queue corresponds to one tenant, the queue name adopts the service message+tenant code mode, the queue realizes the dynamic creation of the interface when the tenant is created, when the service message is switched from the temporary queue to the actual queue, the corresponding queue is found through the tenant code and the service module to realize the message pushing migration operation, the message service end adopts dynamic consumption listening, that is, a corresponding message consumption service is established for each service message, and the corresponding service consumption operation is realized through the tenant code;

[0034] When multi-tenant creation is performed, according to the existing switch, a corresponding queue is created for each tenant, when each service message is pushed from the actual queue, according to the tenant code and the corresponding service, the data is pushed into the corresponding queue to achieve the actual consumption purpose; the corresponding queue consumer is created according to the respective service port at the consumer end, all tenant queues corresponding to the service in the mq are sequentially added to the corresponding listening, that is, the corresponding message is pushed into the service switch and the corresponding queue of the tenant, and dynamic consumption is sequentially performed.

[0035] Based on Seata, global distributed transaction management of master control, workflow and dynamic branch control is realized, and on the basis of the distributed transaction, transaction processing of messages is realized through temporary queues and actual queues of messages, that is, when global transaction is uniformly submitted, the message of the temporary queue is pushed into the actual queue message of RabbitMQ according to the tenant code and the business type corresponding to the message, and the message is dynamically consumed at the consumer end. Based on Seata, global distributed transaction management is realized, and the storage mode of Redis is adopted to provide overall efficiency; the message service pushes the message to RabbitMQ, and the temporary queue and the actual queue mode are adopted, that is, when the global transaction of Seata is in the pending submission state, the message service is stored in the temporary queue of RabbitMQ, once the main transaction is submitted, the message in the temporary queue is migrated to the actual queue of the corresponding tenant, and normal consumption of the message is realized; once the main transaction is rolled back, the message is cleaned and deleted from the temporary queue, so as to ensure the accuracy of message pushing and prevent data dirty reading.

[0036] Although the embodiments of the present application have been shown and described, it can be understood by those skilled in the art that various changes, modifications, replacements and variations can be made to the embodiments without departing from the principles and spirits of the present application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1. A solution based on Seata, RabbitMQ integrated distributed transaction and multi-tenant consumption, characterized in that: The method comprises the following steps: The master controls the Seata to play the initiator, adopts the AT transaction mode, takes Redis as the transaction message carrier to improve the high-performance transaction processing; The master starts the global transaction, generates XID, uniformly stores XID into header in the feign call, and realizes the binding of xid through the filter of each micro service; Different exchanges corresponding to different business messages are created, and each exchange corresponds to multiple queues. When the master controls the Seata to play the initiator, adopts the AT transaction mode, takes Redis as the transaction message carrier to improve the high-performance transaction processing, the method further comprises the following steps: The information is pushed to the transaction coordinator service end to realize the registration of the transaction message, and the global transaction information, branch transaction information and lock information are recorded to realize the registration of the transaction message; the initiator related service realizes the registration of the transaction message to the transaction coordinator service end, registers the transaction related message, generates the business SQL undolog log and stores the log in the database of the participant micro service; When the master starts the global transaction, generates XID, uniformly stores XID into header in the feign call, and realizes the binding of xid through the filter of each micro service, the method further comprises the following steps: In the business aspect, each participant sends its own message to the temporary queue according to the business demand, the temporary queue uses Redis storage, takes XID as the primary key, and uniformly stores the pushed message in the LIST object set, including the actual queue information and message content of the MQ; once the transaction coordinator TC initiates unified transaction submission, the message is marked with XID, the temporary queue data is read and analyzed, the actual queue and message content are obtained, the message data of the temporary queue is migrated to the actual queue as the target, and the data is migrated to the actual queue; after the migration is successful, the messages in the Redis cache are uniformly deleted and cleaned; once the participant fails due to business or system error, the transaction coordinator TC initiates transaction rollback to the participant, and the messages in the Redis temporary queue are uniformly deleted and cleaned according to the XID mark; When different exchanges corresponding to different business messages are created, and each exchange corresponds to multiple queues, the method further comprises the following steps: The queue name adopts the business message+tenant internal code mode, the queue realizes the dynamic creation of the interface when the tenant is created, when the business message is switched from the temporary queue to the actual queue, the corresponding queue is found through the tenant internal code and the business module to realize the message pushing and migration operation, and the message service end adopts the dynamic consumption listening, that is, the corresponding message consumption service is established for each business message, and the corresponding business consumption operation is realized through the tenant internal code.

Images