CN113360299B

CN113360299B - Transaction processing method and related product

Info

Publication number: CN113360299B
Application number: CN202110726140.7A
Authority: CN
Inventors: 李海兵
Original assignee: Shenzhen Sensetime Technology Co Ltd
Current assignee: Shenzhen Sensetime Technology Co Ltd
Priority date: 2021-06-29
Filing date: 2021-06-29
Publication date: 2022-11-29
Anticipated expiration: 2041-06-29
Also published as: WO2023273028A1; CN113360299A

Abstract

The embodiment of the application provides a transaction processing method and a related product, wherein the transaction processing method comprises the following steps: the server side creates a first micro service; if the first micro service corresponds to at least two transactions, the at least two transactions comprise a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, a chained transaction manager is created; and processing the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager. The method and the device for the data consistency of the transaction related to the micro service can be guaranteed.

Description

Transaction processing method and related product

Technical Field

The application relates to the technical field of internet, in particular to a transaction processing method and a related product.

Background

In a micro-service developed e-commerce platform and other micro-service developed products, each micro-service is independently deployed and operated through business splitting, and the transaction related to the same micro-service may correspond to data updating operations of different data sources. How to guarantee the data consistency of the transaction related to the micro-service is an urgent problem to be solved.

Disclosure of Invention

The embodiment of the application provides a transaction processing method and a related product.

A first aspect of an embodiment of the present application provides a transaction processing method, including:

creating a first microservice;

if the first micro service corresponds to at least two transactions, the at least two transactions comprise a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, a chained transaction manager is created;

and processing the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager.

Optionally, the method further includes:

if the first micro service corresponds to at least one transaction and the at least one transaction corresponds to the same target data source, a single data source transaction manager is created;

processing, by the single data source transaction manager, the at least one transaction.

Optionally, the creating single data source transaction manager includes:

if the target data source is a default data source, a default transaction manager is configured in an annotation mode, the default transaction manager realizes the transaction support of the default data source, and the single data source transaction manager comprises the default transaction manager.

Optionally, the creating a chained transaction manager includes:

and creating a transaction manager, and setting the attribute of the transaction manager as a chain transaction manager in an annotation mode.

Optionally, before the creating of the first micro service, the method further includes:

receiving a service request initiated by a user side;

determining at least one microservice to which the business request relates, the at least one microservice comprising the first microservice.

Optionally, the at least one microservice further comprises a second microservice, and the method further comprises:

creating the second micro service, and creating a first message table or a first message set;

delivering a first message related to the service request to a first message queue, wherein the second micro-service is used for obtaining the first message from the first message queue;

judging whether a message with the same identifier as the first message exists in the first message table or the first message set or not according to the identifier of the first message;

if not, processing the first message through the second micro service;

optionally, after processing the first message, the method further includes:

and if the first message queue does not receive a message processing success confirmation message which is returned by the second micro service and aims at the first message, adopting a best effort notification strategy to notify the second micro service through the first message queue.

Optionally, after processing the first message, the method further includes:

persisting the first message into the first message table or a first message set after the first message is successfully processed.

Optionally, if there is a message with the same identifier as the first message in the first message table or the first message set, the first message is discarded.

Optionally, after the creating the first message table or the first message set, the method further includes:

defining a table name of the first message table or a set name of the first message set by an expression language.

Optionally, the method further includes:

defining an application listener through a service discovery mechanism, the application listener to configure a path for packet scanning of the first microservice.

Optionally, the creating a first microservice includes:

and realizing the dynamic configuration and registration of the first micro service through an automatic configuration mechanism.

Optionally, the method is implemented based on automatically configured pluggable components.

A second aspect of an embodiment of the present application provides a transaction processing apparatus, including:

a first creating unit configured to create a first microservice;

a second creating unit, configured to create a chained transaction manager when the first microservice corresponds to at least two transactions, where the at least two transactions include a first transaction and a second transaction, and a first data source corresponding to the first transaction and a second data source corresponding to the second transaction are different;

and the transaction processing unit is used for processing the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager.

A third aspect of embodiments of the present application provides a server comprising a processor and a memory, the memory being configured to store a computer program, the computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the step instructions as in the first aspect of embodiments of the present application.

A fourth aspect of embodiments of the present application provides a computer-readable storage medium, where the computer-readable storage medium is used to store a computer program, and the computer program makes a computer perform some or all of the steps described in the first aspect of embodiments of the present application.

A fifth aspect of embodiments of the present application provides a computer program product, wherein the computer program product comprises a computer program, and when the computer program is executed by a computer, the computer executes some or all of the steps described in the first aspect of embodiments of the present application. The computer program product may be a software installation package.

In the embodiment of the application, a server side creates a first micro service; if the first microservice corresponds to at least two transactions, the at least two transactions comprise a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, creating a chained transaction manager; and processing the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager. The method and the device for processing the transaction processing can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager, and the chain transaction manager can realize transaction support of multiple data sources, so that the first transaction and the second transaction can be successfully or failed to be executed at the same time, and the data consistency of the first transaction and the second transaction corresponding to the first micro service can be guaranteed.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a diagram of a communication connection architecture between a user side and a server side according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a transaction processing method according to an embodiment of the present application;

fig. 3 is a schematic flow chart of another transaction processing method provided in the embodiment of the present application;

fig. 4 is a schematic flowchart of another transaction processing method provided in an embodiment of the present application;

fig. 5 is a schematic flowchart of another transaction processing method provided in an embodiment of the present application;

fig. 6 is a schematic structural diagram of a transaction processing apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," and the like in the description and claims of the present application and in the above-described drawings are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements but may alternatively include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

The electronic device according to the embodiments of the present application may include a device with computing capability and communication capability, such as a mobile phone, a tablet, a personal computer, and the like. Personal computers, which may also be referred to as user computers, may include desktop computers, notebook computers, and the like. For convenience of description, the above-mentioned devices are collectively referred to as electronic devices. The user terminal is a program for providing local services for the user, and can run on the electronic equipment.

The server related to the embodiment of the application can be a server in a micro server cluster, and the server can run on the server. The server serves the user side, and the content of the service includes providing the service (such as an online ordering service, an online payment service, an online query service, and the like) to the user side, storing the user side data, and the like.

Referring to fig. 1, fig. 1 is a diagram of a communication connection architecture between a user side and a server side according to an embodiment of the present application. As shown in fig. 1, a service end 100 can be communicatively connected with at least one user end 101. The user side can directly establish communication connection with the server side, and also can establish communication connection with the server side through other equipment. The server can provide various types of services, and the client can initiate a service request to the server, wherein the service request can comprise an order placing request, a payment request, an inquiry request and the like. The server side creates a first micro service; if the first micro service corresponds to at least two transactions, the at least two transactions comprise a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, creating a chain transaction manager (chain transaction manager); and processing the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager. The method and the device for processing the transaction data can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager, and the chain transaction manager can realize transaction support of multiple data sources and guarantee that the first transaction and the second transaction are executed successfully or failed at the same time, so that the data consistency of the first transaction and the second transaction corresponding to the first micro service can be guaranteed, and the data consistency of all transactions related to one micro service is improved.

The server can provide a plurality of micro services, and the server can respond to the service request initiated by the user side to create the micro services. One service request initiated by the user terminal may involve data aggregation or data update of multiple microservices. For example, the user initiates a commodity purchase request on a mobile phone, and the data update may include: updating commodity inventory data, updating commodity information of shopping carts, updating order data and the like; the data aggregation may include: and simultaneously displaying the aggregation of the inventory information, the commodity preference information and other data on the commodity browsing interface by the user.

Microservice, a software development technology, is a variant of service-oriented architecture (SOA) that constructs applications as a set of loosely coupled services. One micro-service may implement a certain function.

A transaction refers to a unit of program execution that accesses and possibly updates various data items in a database. One microservice may correspond to one transaction or at least two transactions.

In one example, the first microservice may be an order service, and the first microservice may correspond to at least two transactions including: the method comprises the steps of commodity order information storage affairs, inventory message queue delivery affairs and shopping cart message queue delivery affairs. For example, after a user initiates a commodity purchase request on a mobile phone, an order service may be created, the order service creates an order, the order service stores order data (e.g., an order number) in a first data source (e.g., mySQL database), that is, a first transaction corresponding to the order service, stores detail data of the order (e.g., order placement time, number of placed commodities, details of purchased commodities, purchase amount, etc.) in a second data source (e.g., mongoDB database), that is, a second transaction corresponding to the order service, and the order service may further deliver a message to a message queue (e.g., a card message queue) of the inventory service, subtract the quantity of purchased commodities from the inventory (e.g., subtract inventory data by 1), deliver another message to a message queue (e.g., a card message queue) of the shopping cart service, and allow the shopping cart service to delete the commodities. The data source may include a database or a database server used by a database application.

The transactions related to the same micro service may correspond to different data sources, and if the transactions related to different data sources are implemented respectively, it is difficult to ensure data consistency of the transactions related to the same micro service because multiple transactions related to the same micro service are processed separately.

The first data source corresponding to the first transaction is different from the second data source corresponding to the second transaction, and the type of the first data source may be different from that of the second data source. The first data source corresponding to the first transaction refers to a first data source which needs to be accessed by the first transaction, and the second data source corresponding to the second transaction refers to a second data source which needs to be accessed by the second transaction.

The chain transaction manager is one of the transaction managers and can define a transaction chain, and a plurality of transactions are sequentially submitted in the chain transaction manager. For example, the first microservice corresponds to three transactions: the commodity order information storage affairs, the inventory message queue delivery affairs and the shopping cart message queue delivery affairs can be submitted in sequence. The chain transaction manager can support transaction processing of multiple types of data sources, and guarantees that three transactions corresponding to the first micro service are executed successfully or failed at the same time, so that data consistency of the three transactions corresponding to the first micro service can be guaranteed.

The data consistency of the embodiment of the application can comprise data strong consistency or data weak consistency. Data weak consistency may also be referred to as data final consistency. For the e-commerce platform, the final consistency of data is guaranteed. For example, after a user places a commodity under the e-commerce platform, the order service creates an order, if the order service is successfully executed, the inventory is subtracted by 1 by the inventory service, the shopping cart service deletes the commodity in the shopping cart of the user, the three of the successful execution of the order, the subtraction of the inventory by 1 and the deletion of the commodity in the shopping cart of the user are consistent, the data consistency is considered, the final consistency does not require that the three are completed at the same time, and only the three are needed to be consistent finally. Strong data consistency requires that the three must be completed simultaneously. If the order service is successfully executed, the inventory is not changed, or the commodity in the shopping cart of the user is not deleted, the data are considered inconsistent, and the data consistency is not satisfied.

Referring to fig. 2, fig. 2 is a flowchart illustrating a transaction processing method according to an embodiment of the present disclosure. The method is applied to the server shown in fig. 1, and as shown in fig. 2, the transaction processing method may include the following steps.

201, the server side creates a first micro service.

In the embodiment of the application, the server side can create the first micro service under the request of the user side, and can also create the micro service by itself. For example, when the user side initiates an order placing request to the server side, the server side may create a first micro service, that is, an order service; when the user terminal initiates a payment request to the server terminal, the server terminal may create a first microservice, i.e., a payment service. For another example, when the server needs to query data in the database, the server may actively create a first microservice, that is, a query service.

202, if the first micro service corresponds to at least two transactions, the at least two transactions include a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, the server creates a chained transaction manager.

In the embodiment of the application, one microservice can correspond to at least one transaction. When one microservice corresponds to at least two transactions, the data sources corresponding to the at least two transactions may be the same or different. When the data sources corresponding to the at least two transactions are different, a chain transaction manager can be created, and the at least two transactions are processed through the chain transaction manager.

For example, if the first microservice comprises an order service, the order service may correspond to an order information holding transaction, an inventory message queue delivery transaction, and a shopping cart message queue delivery transaction. The data source corresponding to the order information saving transaction can be a MySQL database, the data source corresponding to the inventory message queue delivery transaction can be a card-fielder (kafka) message queue, and the data source corresponding to the shopping cart message queue delivery transaction can be kafka.

Transactions, generally, refer to things to do or do. In computer terminology, refers to a program execution unit (unit) that accesses and possibly updates various data items in a database. Transactions are typically caused by the execution of user programs written in a high-level database manipulation language or programming language (e.g., SQL, C + +, or Java), and are delimited in the form of begin transaction and end transaction statements (or function calls). A transaction consists of an ensemble of operations performed between a transaction start (begin transaction) and a transaction end (end transaction).

The server side can establish the chained transaction manager when at least two transactions corresponding to the first microservice have transactions with different data sources. The chain transaction manager can serially connect at least two transactions, and after the at least two transactions are serially connected, the chain transaction manager can process the transactions in a unified manner, and the at least two transactions fail or succeed at the same time, so that the data consistency of the at least two transactions corresponding to the first micro service can be ensured.

Optionally, in step 202, the creating, by the server, a chain transaction manager may specifically include the following steps:

and the server side establishes a transaction manager, and sets the attribute of the transaction manager as a chain transaction manager in an annotation mode.

In the embodiment of the present application, the annotation may be understood as a special mark in the code, and the mark may be read and executed during compiling, class loading and runtime. By way of annotation, software developers can embed supplemental information in source code without changing the original code and logic. By way of annotation it is possible to decide whether to set the properties of the transaction manager depending on all data sources involved by the first microservice for at least two transactions. If all the data sources related to the at least two transactions corresponding to the first microservice include at least two different data sources, and the transaction annotation is set as a default transaction manager by default, and the default transaction manager can only realize the transaction support of the default data source, the attribute of the transaction manager needs to be reset to be the chained transaction manager, so that the chained transaction manager can realize the transaction support of the at least two different data sources. If all data sources related to at least two transactions corresponding to the first microservice are the same data source, the transaction annotation is set as a default transaction manager by default, and the attribute of the transaction manager does not need to be reset. The embodiment of the application can enable the transaction through annotation and set the type of the transaction manager.

In particular, in code, the transaction annotation may be an @ transactional annotation. The embodiment of the application can add @ Transactional annotation at the place needing transaction management. The @ Transactional annotation can be applied to interface definitions and interface methods, class definitions and public methods of classes. The @ Transactional annotation may be added at the service layer.

And 203, the server side processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager.

In this embodiment, the chained transaction manager may sequentially process a transaction corresponding to the first data source and a transaction corresponding to the second data source. In particular, the chained transaction manager may process the first transaction and the second transaction in sequence.

The chained transaction manager can implement transaction support for multiple data sources if the at least two transactions correspond to two different data sources: the created chain transaction manager can realize the transaction support of the first data source and the second data source; if the at least two transactions correspond to three different data sources: a first data source, a second data source and a third data source, the created chained transaction manager can realize the transaction support of the first data source, the second data source and the third data source, and so on.

The method and the device for processing the transaction data can process the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chain transaction manager, and the chain transaction manager can realize transaction support of multiple data sources and guarantee that the first transaction and the second transaction are executed successfully or failed at the same time, so that the data consistency of the first transaction and the second transaction corresponding to the first micro service can be guaranteed, and the data consistency of all transactions related to one micro service is guaranteed.

Referring to fig. 3, fig. 3 is a flowchart illustrating another transaction processing method according to an embodiment of the present application. Fig. 3 is further optimized based on fig. 2, and as shown in fig. 3, the transaction processing method may include the following steps.

301, the server creates a first microservice.

302, if the first microservice corresponds to at least two transactions, the at least two transactions include a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, the server creates a chained transaction manager.

303, the server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

The specific implementation of steps 301 to 303 may refer to steps 201 to 203 shown in fig. 2, which is not described herein again.

304, if the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source, the server creates a single data source transaction manager.

The single data source transaction manager can realize the transaction support of one data source. If at least one transaction corresponds to the same target data source and is a default data source, the service end configures a default transaction manager in an annotation mode, and the default transaction manager can realize the transaction support of the default data source. If at least one transaction corresponds to the same target data source and is not the default data source, the server sets the attribute of the transaction manager as a target transaction manager supporting the target data source through the transaction annotation, and the target transaction manager can realize the transaction support of the target data source.

Optionally, in step 304, the server creates a single data source transaction manager, which specifically includes the following steps:

if the target data source is a default data source, a default transaction manager is configured in an annotation mode, the default transaction manager realizes the transaction support of the default data source, and the single data source transaction manager comprises the default transaction manager. The method and the device for processing the data source enable the transaction through the annotation under the condition that the target data source is related to the default data source, and determine that the type of the transaction manager is the default transaction manager.

In the embodiment of the application, if the target data source is associated with the default data source, the attribute of the transaction manager does not need to be reset, the default transaction manager is directly configured in an annotation mode, the default transaction manager can realize the transaction support of the default data source, and the default transaction manager belongs to the single-data-source transaction manager.

305, the server processes at least one transaction through the single data source transaction manager.

In the embodiment of the application, the single-data-source transaction manager can process a plurality of transactions of the same data source at the same time, and the plurality of transactions can be processed at the same time. The transaction of the embodiment of the application can be a transaction of data updating.

Referring to fig. 4, fig. 4 is a flowchart illustrating another transaction processing method according to an embodiment of the present application. Fig. 4 is further optimized based on fig. 2, and as shown in fig. 4, the transaction processing method may include the following steps.

401, the server receives a service request initiated by the user.

In the embodiment of the present application, the service request may include an order placing request, a payment request, an inquiry request, and the like.

The server determines at least one microservice to which the service request relates, the at least one microservice comprising a first microservice, 402.

In the embodiment of the application, the micro-services related to different service requests are different. For example, the order request may relate to order service, inventory service, shopping cart service, etc., and the order request may relate to more micro-services; the query request may only involve a query service, with fewer micro-services involved. The corresponding relation between the service request and the number and type of the micro-services can be stored in the server in advance, and different service requests can correspond to different numbers of micro-services and different types of micro-services.

The method and the device for creating the micro services can determine which micro services are created and the number of the created micro services according to the number and the types of the micro services related to the service request initiated by the user, can not occupy redundant micro service resources, can not cause the service request to be processed due to few micro services, can flexibly create the micro services, and can better realize the service request initiated by the user side.

403, the server creates a first microservice.

404, if the first microservice corresponds to at least two transactions, the at least two transactions include a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, the server creates a chained transaction manager.

And 405, the server side processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

The specific implementation of steps 403 to 405 may refer to steps 201 to 203 shown in fig. 2, which is not described herein again.

Referring to fig. 5, fig. 5 is a schematic flowchart illustrating another transaction processing method according to an embodiment of the present disclosure. Fig. 5 is further optimized based on fig. 4, and as shown in fig. 5, the transaction processing method may include the following steps.

And 501, the server receives a service request initiated by the user terminal.

502, the service end determines at least two micro services involved in the service request, wherein the at least two micro services include a first micro service and a second micro service.

503, the server creates a first micro service and a second micro service, and creates a first message table or a first message set.

In the embodiment of the present application, if one service request relates to at least two microservices, the at least two microservices may be created simultaneously, or the at least two microservices may be created separately. The first message table or the first message set may be created in a data source corresponding to the second micro service, and the second micro service may process the first message, and after the processing is successful, the first message may be persisted to the first message table. Different files may be defined in different databases to hold messages. For example, a message table can be created in the MySQL database to store messages, and a message set can be created in the MongoDB database to store messages.

Optionally, in step 502, the server creates the first microservice, which may specifically include the following steps:

In the embodiment of the application, the micro-service can be dynamically created according to the annotation enabling condition and the attribute value, and the created effective micro-service is registered in the container, so that the dynamic configuration and registration of the micro-service are realized. For example, when a micro service is created, a preset component may read a configuration file (for example, properties or yml configuration) of a resource file, if an Enable class of the micro service is configured in the configuration file, the Enable annotation starts automatic configuration, and according to an attribute value of the Enable annotation, configuration and registration of the relevant micro service are performed, so as to implement creation of the micro service. Since the Enable condition and attribute value of the Enable annotation can be set by a developer, the microservice can be dynamically created according to project requirements. If the startup class in the configuration file for which the microservice is configured does not use the Enable annotation, the microservice may be created according to a default configuration. The container of the embodiments of the present application may be a Spring container. And 504, the server side delivers a first message related to the service request to the first message queue, and the second micro-service is used for obtaining the first message from the first message queue.

In the embodiment of the present application, the message queue is a container for storing messages in the transmission process of the messages. The message may be very simple, such as containing only text strings, or more complex, such as possibly containing embedded objects. A topic (topic) for consumption by a second microservice (consumer) may be created for the first message queue, the second microservice may pull a first message from the first message queue corresponding to the topic of the second microservice, and the first message queue may also actively push the first message to the second microservice. Likewise, another topic for the third microservice (consumer) consumption may be created for the first message queue.

The message queue has an asynchronous decoupling function, and the message queue is used for message transmission in the embodiment of the application, so that the throughput of the interface can be greatly improved, and the purpose of traffic peak clipping is achieved.

Asynchronous: the transaction of the first micro service and the transaction of the second micro service do not need to be executed synchronously, and the first micro service can deliver other messages to other message queues after delivering the first message to the first message queue in a message queue mode without waiting for the processing result of the second micro service on the first message, so that the throughput of the interface can be greatly improved.

Decoupling: assume that the first microservice and the second microservice are two classes, respectively. If the first microservice were to directly invoke a method of the second microservice, the first microservice would be dependent (i.e., coupled) to the second microservice. The first microservice may be affected if the code of the second microservice changes in the future. If a message queue is adopted, the first micro service and the second micro service are both dependent on the message queue, and the first micro service and the second micro service are not directly dependent on each other, so that the coupling is correspondingly reduced.

The first message related to the service request may be generated by the first micro service, and the server may generate the first message by the first micro service. For example, if the business request is an order placing request, the first micro service is an order service, the second micro service is an inventory service, and a first message related to the business request may be generated by the order service, where the first message may include an order number, commodity details (for example, the quantity of the commodity, the model number of the commodity, etc.), and the like. After the second microservice obtains the first message, the inventory quantity of the corresponding commodity model in the commodity details can be subtracted by the commodity quantity in the commodity details according to the commodity details contained in the first message.

Optionally, the at least two microservices may include a first microservice, a second microservice, and a third microservice. The server side can generate a third message through the first micro service, and the third message is delivered to the second message queue, and the third micro service is used for obtaining the third message from the second message queue.

A topic may be created for consumption by a third microservice (consumer) for the second message queue, the third microservice may pull a third message from the second message queue, and the second message queue may actively push the third message to the third microservice.

The third message may be generated by the first micro service, and the server may generate the third message by the first micro service. For example, if the business request is a place order request, the first microservice is an order service, the second microservice is an inventory service, and the third microservice is a shopping cart service, the third message may include an order number. After the third microservice obtains the third message, the goods corresponding to the order number in the shopping cart can be removed from the shopping cart according to the order number contained in the third message.

And 505, the server judges whether a message with the same identifier as the first message exists in the first message table or the first message set according to the identifier of the first message.

And 506, if the first message does not exist, the server side processes the first message through the second micro service.

Optionally, after performing step 506, the following steps may also be performed:

507, if the first message queue does not receive a message processing success confirmation message for the first message returned by the second microservice, the server side notifies the second microservice by adopting a best effort notification strategy through the first message queue.

In this embodiment of the present application, after the second micro service processes the first message, two processing results may be obtained: the process is successful or the process fails. If the processing is successful, the second micro service returns a message processing success confirmation message aiming at the first message to the first message queue as long as the second micro service does not have a fault. If the second micro-service fails, for example, the service is hung up or the network fails, the second micro-service cannot send the processing result to the first message queue, and the server can notify the second micro-service through the first message queue by using a best effort notification strategy, so that the final consistency of the data of the transactions corresponding to the plurality of micro-services is ensured, and the final consistency of the transactions of the plurality of data sources is ensured. If the processing fails, the second micro service returns a message processing failure message for the first message to the first message queue, and at this time, the server may also notify the second micro service by using a best effort notification policy through the first message queue, so that the second micro service processes the first message until receiving a message processing success confirmation message for the first message returned by the second micro service.

The best effort notification policy is a policy for notifying as best effort as possible. For example, the first message queue may periodically notify the second microservice, and let the second microservice return the processing result for the first message until the first message queue receives the processing result for the first message returned by the second microservice. For another example, the first message queue may notify the second microservice by using a notification policy with a period gradually increasing, and let the second microservice return the processing result for the first message until the first message queue receives the processing result for the first message returned by the second microservice. For another example, after the service is suspended and restarted or the network resumes and restarts, the second microservice may actively pull the first message from the first message queue to process the first message, and return the processing result to the first message queue.

Optionally, if the first message queue receives a processing result for the first message returned by the second micro service, the server may notify the first micro service through the first message queue, where the first micro service is used to synchronize data with the second micro service, so as to ensure consistency of transaction data of multiple micro services.

And 508, if the first micro service corresponds to at least two transactions, the at least two transactions comprise a first transaction and a second transaction, and a first data source corresponding to the first transaction is different from a second data source corresponding to the second transaction, the server creates a chained transaction manager.

509, the server processes the transaction corresponding to the first data source and the transaction corresponding to the second data source through the chained transaction manager.

The specific implementation of steps 508 to 509 may refer to steps 202 to 203, which are not described herein again.

Optionally, after step 506 is executed, the method shown in fig. 5 may further include the following steps:

and after the first message is successfully processed, the server side persists the first message into the first message table or the first message set.

In the embodiment of the present application, the service data of the service request may include data required for executing the service request. For example, if the service request is an order request, the data required for the order request may include: order data (e.g., order number), detail data of the order (e.g., time of order placement, quantity of items placed, details of items purchased, amount of money purchased, etc.).

Data persistence is the general term for converting a data model in a memory into a storage model and vice versa. For example, the first message may be stored in the first message table or the first message set by persisting the first message to the first message table or the first message set.

Optionally, the method shown in fig. 5 may further include the following steps:

and if the first message table or the first message set has the message with the same identifier as the first message, the server discards the first message.

In this embodiment of the application, the server may create a first message table in the data source corresponding to the second micro service, where the first message table is used to store messages, and each message may correspond to an identifier, where the identifier may be a Globally Unique Identifier (GUID). Since the service request may correspond to a plurality of micro-services, which may be executed in a plurality of devices of the network, each message may be tagged with a global identifier between the plurality of micro-services, which may distinguish between different messages. Illustratively, the second microservice may be an inventory service or a shopping cart service.

In the embodiment of the present application, the identifier of each message is unique, and in order to avoid that the same message is executed multiple times, whether the message is executed multiple times may be determined according to the identifier of the message. If the identifiers of the first message and the second message in the first message table are the same, the first message is placed in the first message table for the second time, and the first message is directly discarded. If the identifiers of the first message and the second message are different, the first message is placed in a first message table for the first time, the server side processes the first message through the second micro service, and after the first message is successfully processed, the server side stores the first message into the first message table through the second micro service in a persistent mode. The method and the device for checking the idempotency of the transaction message can achieve the idempotency check of the transaction message through the message table and the identifier of the message, and therefore the idempotency of the transaction message is guaranteed.

Optionally, after step 503 is executed, the following steps may also be executed:

and the server defines the table name of the first message table or the collection name of the first message set through an expression language.

In this embodiment of the application, the Expression Language may be a Spring Expression Language (Spring Expression Language, spring). The SpEL expression can realize automatic configuration of the table name or the collection name, and can flexibly define the table name or the collection name.

Optionally, an application listener is defined through a Service Provider Interface (SPI), and the application listener is configured to configure a packet scanning path of the first microservice.

In the embodiment of the application, the SPI is a service discovery mechanism provided in a Java development kit, and the SPI searches for files through a META-INF/services folder under a ClassPath path and automatically loads classes defined in the files. The SPI may define an application listener for configuring a path of packet scanning for the first microservice. And a user does not need to add a package scanning path on the starting class, so that the development difficulty of the user is reduced.

The method of the embodiment of the application can be realized through pluggable components based on automatic configuration. The component can be used in the development of Spring projects, can be used in e-commerce platforms based on micro-service development and other products of micro-service development.

In particular, the software product of the embodiments of the present application may be a pluggable component. For example, the Spring Boot start component may be quickly introduced in any Spring project, may use default configurations, or may simply configure the project as needed in a profile (e.g., properties or yml) of the project. The introduction of the component does not have any influence on the project of the component, and the configuration and registration of the related service are carried out only when the micro service starting class use enabling (Enable) annotation enables the automatic configuration (AutoConfigure) support of the message transaction component.

The development process of the component may include the following steps:

1. creating a Spring Boot Start project, and introducing relevant dependence (such as maven dependence);

2. creating a transaction message entity class, mapping the transaction message entity class to a MySQL data table and a MongoDB set, and dynamically defining a table name or a set name through a SpEL expression;

3. developing a Service (Service) for operating the MySQL data table and the MongoDB set, wherein the Service of the MongoDB can dynamically decide whether to add the updating operation to the transaction according to whether the version supports the transaction;

4. defining an Enable annotation for automatically configuring whether to be started, adding an attribute of a message persistence mode, judging whether to use a MySQL database or a MongoDB database to store transaction messages, and determining whether to register the transaction messages into a Spring container to process a Service of a MySQL message table or a Service of a MongoDB message set;

5. defining an application monitor through a Service Provider Interface (SPI) mechanism, wherein the application monitor is used for configuring a Spring packet scanning path;

6. defining transaction managers of various data sources such as MySQL, mongoDB, kafka and the like and conditions for establishing the transaction managers or not, and establishing chain transaction managers of various combinations of the data sources;

7. defining a card-fielder (kafka) message producer Service class for transaction message encapsulation and delivery, dynamically managing the registration of Service to a Spring container according to whether the Service microservice introduces kafka dependency, and deciding whether to add the message delivery operation to the transaction according to whether the kafka version supports the transaction and whether to open the transaction;

8. accurate delivery of messages is achieved through the transactional support of kafka, and the final consistency of the transaction is guaranteed through a message consumption confirmation or submission mechanism, a kafka message persistence characteristic and a message offset.

Wherein the use of the component in the project may comprise the steps of:

1. a user creates a business micro-service project and adds components;

2. configuring a table name or a default name of a set name (for example, the default name is transfer message) of transaction message persistence in a configuration file, and configuring a default transaction manager (for example, the default is MySQL);

3. adding solution on the starting class for automatically configuring and registering message persistence service;

4. executing local affairs, if the data source is associated with a default affair manager, not relating to various data sources, directly using annotations without setting attributes; if the data source is associated with other transaction managers, annotating the chained transaction manager whose attributes must be set to the components already provided;

5. if the service micro-service needs to use the card, because the default of the component does not introduce the card, the dependence related to the card needs to be added into the micro-service, and the card is injected into a card message deliverer to the service in an automatic assembly mode for delivering the card message;

6. another consumer business microservice is created, the same introduces the associated dependencies, and then a card-card message listener is created for processing the transaction message. The service (Messageservice) for message persistence and idempotent verification automatically assembled based on the component can realize idempotent judgment of the transaction message.

The component of the embodiment of the application can realize the transaction support of MySQL, mongoDB and Kafka multi-type data sources, and can dynamically create a single-data-source transaction manager and a chained transaction manager according to the dependence and the transaction opening state quoted by the project; the table name or set of the transaction message persistence can be dynamically defined by name, so that the configuration of the micro service is more flexible, each micro service can use the same database, and the persistent transaction messages of different micro services can be distinguished by different table names and set names; the method can define an application listener through an SPI mechanism to realize Spring package scanning of the micro-service, and a user does not need to add a package scanning path of the component on a starting class; the component can dynamically create Service according to the enabling condition and the attribute value of the user Enable annotation, and register the effective Service to the Spring container without registering the ineffective redundant Service; the previous versions of Kafka and MongoDB do not support the transaction, the transaction of Kafka needs to be manually started in a configuration or coding mode, and based on the component, a user does not need to repeatedly judge, and the component can dynamically manage the transaction according to the support and the starting state of the transaction of a data source; the multi-type data source transaction support and the realization of the multi-instance data source transaction consistency are integrated, and different components do not need to be developed for two scenes; the cross-service multi-data-source transaction consistency is the final consistency achieved by the best effort notification based on the Kafka message queue, compared with a rigid transaction and a compensation transaction, the throughput is greatly improved, meanwhile, the flow peak clipping under a high concurrency scene can be met, and the service stability is ensured; the automatic configuration-based component can be plugged and pulled randomly, the service microservice cannot generate influence after the component is added, additional configuration is not needed, related functions can be started only when a user starts the automatic configuration of the component actively, the automatic configuration mechanism and default configuration of the component can meet most requirements, and additional configuration is basically not needed for the user.

The above description has introduced the solution of the embodiment of the present application mainly from the perspective of the method-side implementation process. It is understood that the electronic device comprises corresponding hardware structures and/or software modules for performing the respective functions in order to realize the above-mentioned functions. Those of skill in the art will readily appreciate that the present application is capable of hardware or a combination of hardware and computer software implementing the various illustrative elements and algorithm steps described in connection with the embodiments provided herein. Whether a function is performed in hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, the server and the electronic device may be divided according to the above method examples, for example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit. It should be noted that the division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a transaction processing apparatus according to an embodiment of the present application, the transaction processing apparatus 600 is applied to a server, and the transaction processing apparatus 600 may include a first creating unit 601, a second creating unit 602, and a transaction processing unit 603, where:

a first creating unit 601, configured to create a first microservice;

a second creating unit 602, configured to create a chained transaction manager when the first microservice corresponds to at least two transactions, where the at least two transactions include a first transaction and a second transaction, and a first data source corresponding to the first transaction and a second data source corresponding to the second transaction are different;

a transaction processing unit 603, configured to process, by using the chained transaction manager, a transaction corresponding to the first data source and a transaction corresponding to the second data source.

Optionally, the second creating unit 602 is further configured to create a single data source transaction manager if the first microservice corresponds to at least one transaction, and the at least one transaction corresponds to the same target data source; processing, by the single data source transaction manager, the at least one transaction.

Optionally, the second creating unit 602 creates a single data source transaction manager, including: and under the condition that the target data source is a default data source, configuring a default transaction manager in an annotation mode, wherein the default transaction manager realizes the transaction support of the default data source, and the single-data-source transaction manager comprises the default transaction manager.

Optionally, the second creating unit 602 creates a chained transaction manager, including: and creating a transaction manager, and setting the attribute of the transaction manager as a chain transaction manager in an annotation mode.

Optionally, the transaction processing apparatus 600 may further include a receiving unit 604 and a determining unit 605.

The receiving unit 604 is configured to receive a service request initiated by a user side;

the determining unit 605 is configured to determine at least one microservice involved in the service request, where the at least one microservice includes the first microservice;

the first creating unit 601 is configured to create a first microservice after the determining unit 605 determines at least one microservice involved in the service request.

Optionally, the at least one microservice further includes a second microservice, and the transaction apparatus 600 further includes a delivery unit 606, a determination unit 609, and a message processing unit 610.

The first creating unit 601 is further configured to create the second microservice, create a first message table or a first message set after the determining unit 605 determines the at least one microservice related to the service request;

a delivery unit 606, configured to deliver a first message related to the service request to a first message queue, where the second microservice is configured to obtain the first message from the first message queue and;

the determining unit 609 is configured to determine, according to the identifier of the first message, whether a message that is the same as the identifier of the first message exists in the first message table or the first message set;

the message processing unit 610 is configured to process the first message through the second microservice if the determination result of the determining unit 609 is negative.

The transaction device 600 may further comprise a notification unit 607;

a notification unit 607, configured to notify, through the first message queue, the second microservice by using a best effort notification policy if the first message queue does not receive a message processing success confirmation message for the first message returned by the second microservice.

Optionally, the transaction processing apparatus 600 may further include a persistence unit 608.

The persistence unit 608 is configured to persist the first message into the first message table or the first message set after the first message is successfully processed.

The message processing unit 610 is configured to discard the first message if the determining unit 609 determines that the result is yes.

Optionally, the transaction processing apparatus 600 may further include a first defining unit;

the defining unit is configured to define, by an expression language, a table name of the first message table or a set name of the first message set after the first creating unit 601 creates the first message table or the first message set.

Optionally, the transaction processing apparatus 600 may further include a second defining unit;

the second defining unit is configured to define an application listener through a service discovery mechanism SPI, where the application listener is configured to configure a path of packet scanning of the first microservice.

Optionally, the first creating unit 601 creates a first microservice, including:

and realizing dynamic configuration and registration of the first microservice through an automatic configuration mechanism.

The receiving unit 604 in this embodiment may be an input/output device of a server, and the first creating unit 601, the second creating unit 602, the transaction processing unit 603, the determining unit 605, the delivery unit 606, the notification unit 607, the persistence unit 608, the determining unit 609, the message processing unit 610, the first defining unit, and the second defining unit may be processors of the server.

In the embodiment of the application, the transaction corresponding to the first data source and the transaction corresponding to the second data source can be processed through the chain transaction manager, and the chain transaction manager can realize transaction support of multiple data sources, so that the first transaction and the second transaction can be successfully or unsuccessfully executed at the same time, and the data consistency of the first transaction and the second transaction corresponding to the first micro service can be ensured.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a server according to an embodiment of the present disclosure, and as shown in fig. 7, the server 700 includes a processor 701 and a memory 702, and the processor 701 and the memory 702 may be connected to each other through a communication bus 703. The communication bus 703 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus 703 may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 7, but this is not intended to represent only one bus or type of bus. The memory 702 is used for storing a computer program comprising program instructions, and the processor 701 is configured for calling the program instructions, said program comprising instructions for performing the methods of fig. 2-5.

The processor 701 may be a general purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the above schemes.

The Memory 702 may be, but is not limited to, a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be self-contained and coupled to the processor via a bus. The memory may also be integral to the processor.

The server 700 may further include an input/output device 704, and the input/output device 704 may include an input/output device such as a radio frequency circuit and an antenna.

In the embodiment of the application, the transaction corresponding to the first data source and the transaction corresponding to the second data source can be processed through the chained transaction manager, and the chained transaction manager can realize transaction support of multiple data sources, so that the first transaction and the second transaction are guaranteed to be executed successfully or failed at the same time, and the data consistency of the first transaction and the second transaction corresponding to the first micro service can be guaranteed.

Embodiments of the present application also provide a computer-readable storage medium, where the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any one of the transaction processing methods as described in the above method embodiments.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some interfaces, devices or units, and may be an electric or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may be implemented in the form of a software program module.

The integrated units, if implemented in the form of software program modules and sold or used as stand-alone products, may be stored in a computer readable memory. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a memory, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned memory comprises: various media that can store program codes, such as a usb disk, a read-only memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Those skilled in the art will appreciate that all or part of the steps of the methods of the above embodiments may be implemented by a program, which is stored in a computer-readable memory, the memory including: flash memory disks, read-only memory, random access memory, magnetic or optical disks, and the like.

The foregoing embodiments have been described in detail, and specific examples are used herein to explain the principles and implementations of the present application, where the above description of the embodiments is only intended to help understand the method and its core ideas of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A transaction processing method implemented based on automatically configurable pluggable components, the method comprising:

receiving a service request initiated by a user side;

determining at least one micro service related to a service request according to a corresponding relation between the service request and the number and type of the micro services, wherein the at least one micro service comprises a first micro service;

creating a first microservice;

processing a first transaction corresponding to the first data source and a second transaction corresponding to the second data source through the chained transaction manager;

2. The method of claim 1, wherein creating a single data source transaction manager comprises:

3. The method of claim 1, wherein creating the chained transaction manager comprises:

4. The method of claim 1, wherein the at least one microservice further comprises a second microservice, the method further comprising:

creating the second microservice, and creating a first message table or a first message set;

judging whether a message with the same identifier as the first message exists in the first message table or the first message set according to the identifier of the first message;

and if not, processing the first message through the second micro service.

5. The method of claim 4, wherein after processing the first message, the method further comprises:

and if the first message queue does not receive a message processing success confirmation message aiming at the first message returned by the second micro service, notifying the second micro service by adopting a best effort notification strategy through the first message queue.

6. The method of claim 4, wherein after processing the first message, the method further comprises:

7. The method of claim 4, further comprising:

and if the first message table or the first message set contains the message with the same identifier as the first message, discarding the first message.

8. The method of claim 4, wherein after creating the first message table or the first message set, the method further comprises:

9. The method of claim 1, further comprising:

10. The method of claim 1, wherein creating the first microservice comprises:

11. A transaction apparatus, wherein the apparatus is implemented based on automatically configurable pluggable components, the apparatus comprising:

a receiving unit, configured to receive a service request initiated by a user side;

the determining unit is used for determining at least one micro service related to the service request according to the corresponding relation between the service request and the number and type of the micro services, wherein the at least one micro service comprises a first micro service;

a first creating unit configured to create a first microservice;

the transaction processing unit is used for processing a first transaction corresponding to the first data source and a second transaction corresponding to the second data source through the chain transaction manager;

the second creating unit is further configured to create a single data source transaction manager if the first microservice corresponds to at least one transaction and the at least one transaction corresponds to the same target data source; processing, by the single data source transaction manager, the at least one transaction.

12. A server comprising a processor and a memory, the memory for storing a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, cause the processor to carry out the method according to any one of claims 1 to 10.