CN111198751B

CN111198751B - Service processing method and device

Info

Publication number: CN111198751B
Application number: CN201811382764.6A
Authority: CN
Inventors: 张晋军; 刘海锋; 何小锋
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2018-11-20
Filing date: 2018-11-20
Publication date: 2024-02-02
Anticipated expiration: 2038-11-20
Also published as: CN111198751A

Abstract

The invention discloses a business processing method and device, and relates to the technical field of computers. One embodiment of the method comprises the following steps: transaction annotation is carried out on the business to declare that the first flow and the second flow of the business are respectively used as branch transactions of the distributed transaction to be processed; starting a global transaction; according to the transaction annotation, adding message data corresponding to the second flow to a second database; after the completion of the message data addition is confirmed, business data corresponding to the first flow are added to the first database according to the transaction annotation; after confirming that the business data addition is completed, ending the transaction; and generating and sending a message according to the message data to finish the service. According to the method, the non-relational database operation in the service is used as a branch transaction to be processed, the non-relational database operation is processed according to a transaction mechanism, and then the relational database operation is processed, so that the data consistency of the two operations is ensured, the development difficulty and the complexity are reduced, and the application range is wide.

Description

Service processing method and device

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a service processing method and apparatus.

Background

The transaction should have 4 attributes: atomicity (atom), consistency (consistency), isolation (isolation), and durability (durability). These four attributes are commonly referred to as ACID characteristics. Distributed transactions refer to the participants of the transaction, the servers supporting the transaction, the resource servers, and the transaction manager being located on different nodes of different distributed systems, respectively. There is a "main flow and edge flow" scenario in distributed transactions. For example, in the operation of "user registration course", the main flow is the database operation of the user registration course, and the edge flow is the sending of mail and short message notification. Similar situations exist in e-commerce scenes, such as after completing database operations of stock deduction, sending messages to other applications or writing cache data. The scenario of "main flow and edge flow" here must conform to the transaction characteristics, in the above example, if the user fails to register, but has sent a short message and mail of "registered" to the user, then misunderstanding may be brought to the user, and serious cases may occur: the user goes to class and finds that the user does not register yet, so that the user runs for one time; if the user registers successfully, but does not receive a short message or mail, the user may miss the opportunity to get lessons, and may cause certain economic loss (course cost) to the user.

In the distributed transaction scenario of "main flow and edge flow", the main flow often corresponds to the operation of a relational database, such as MySQL, while the edge flow often corresponds to a mail system, a short message system, a cache system, or other various non-relational database systems, unlike the relational database itself which provides a complete transaction mechanism, the system corresponding to the edge flow often does not provide a transaction mechanism. The distributed transaction is composed of a plurality of local branch transactions, and in the above example of "user entry course", the main flow and the edge flow correspond to two branch transactions. Since edge flows often fail to provide a transaction mechanism, difficulties are presented to the completion of the entire distributed transaction. In classical distributed transaction implementations such as the XA two-phase (XA distributed transaction protocol proposed by the Oracle Tuxedo System) commit, parties that are required to participate in the transaction must provide a local transaction mechanism and follow the XA specification, otherwise the XA distributed transaction cannot be completed.

In order to solve the above problems, there are generally two methods: the first method is as follows: the main flow and the edge flow are packaged in a local database transaction, for example, the main flow is executed first, and then the edge flow is executed. An exception handling mechanism (try-catch method) using a programming language such as Java, and completing the Transaction operation with an associated database operation or using @ Transaction annotation, when any one flow fails, the Transaction rollback is caused, and the Transaction is submitted when all flows succeed. The second method is as follows: the main flow and the edge flow are generally treated independently, and retries (offsets) are continuously performed through a scheduling mechanism until all succeeds. Specifically, as shown in fig. 1, a main process task and an edge process task are put into a scheduling system to obtain a task (the state of the task is not executed or needs to be retried), execute the task, if the execution is successful, the task is deleted from the dispatching system or the state is set to be completed, and if the execution is failed, the task state is set to be retried and the next execution is waited.

In the process of implementing the present invention, the inventor finds that at least the following problems exist in the prior art:

in the first method, data inconsistency occurs in some cases. For example, the edge flow is messaging, and if a timeout exception occurs, a transaction rollback may be caused, such that the library table operation of the main flow Cheng Duiying does not occur (is rolled back), but the message may have been sent out, resulting in a data inconsistency. Without retries as compensation, "permanent data inconsistencies" may occur, and in a strict sense, this approach is not usable.

In the second method, since the main flow and the edge flow are not packaged in one local transaction, the main flow and the edge flow are independent of each other, and there are many cases where data is inconsistent. The time of data inconsistency can be short under the condition of no performance bottleneck or hardware and network faults, but the inconsistency can be long under the condition of performance bottleneck or hardware and network faults; because of the retry mechanism, the main flow and the edge flow are finally consistent in theory; because retry situations may occur in both the main flow and the edge flow, idempotency needs to be ensured (idempotency is that the results of one request or multiple requests initiated by the same operation are consistent by a user, and no side effect is generated due to multiple clicks), so that the complexity of the application is increased; the development and scheduling module is required, so that the development and use cost and complexity of the application are increased; the main flow and the edge flow need to be abstracted into individual tasks and then executed. In the definition of the task, because the business logic is different, the format and the content of the task are different, and the universality is poor.

Disclosure of Invention

In view of this, an embodiment of the present invention provides a service processing method and apparatus, in which a non-relational database operation and a relational database operation in a service are respectively used as branch transactions of a distributed transaction to be processed, and the non-relational database operation is processed according to a transaction mechanism first, and then the relational database operation is processed, so that data consistency of the two operations is ensured, development difficulty and complexity are reduced, and an application range is wide.

To achieve the above object, according to one aspect of the embodiments of the present invention, there is provided a service processing method, the service including a first flow and a second flow, the first flow corresponding to a database operation, the second flow corresponding to a message sending operation, the method comprising: transaction annotation is carried out on the business, and the first flow and the second flow of the business are respectively declared to be treated as branch transactions of the distributed transaction; starting a global transaction; determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database; after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction; and generating and sending a message according to the message data in the second database so as to complete the service.

Optionally, the adding of the message data to the second database comprises: adding a task record in a second database according to the message data, and setting the transaction state of the task record as a first state and the execution state as unexecuted; the method further comprises the steps of: and after confirming that the business data addition is completed, updating the transaction state of the task record from the first state to the second state.

Optionally, when the service includes a plurality of second flows, if the message data corresponding to any one of the second flows fails to be added, the task records corresponding to all the second flows of the service are deleted.

Optionally, generating a message according to the message data in the second database and sending includes: generating and sending a message according to the task record with the transaction state in the second database being the second state and the execution state being the unexecuted task; and after confirming that the message is successfully sent, updating the execution state of the task record from non-execution to successful execution.

Optionally, the method further comprises: if the message transmission fails, updating the execution state of the task record to be retried; based on the retry mechanism, the transaction state is the second state, the execution state is the task record to be retried, and the message is generated and sent.

Optionally, the task record includes a transaction identifier and a task identifier; the opening the global transaction includes: adding a global transaction record in a third database to open a global transaction; the global transaction record comprises a transaction identifier, and task identifiers of a first flow and a second flow contained in the service; deleting the task records corresponding to all the second procedures of the service comprises the following steps: determining a transaction identifier of a second flow which fails to add message data, and taking the transaction identifier as a target identifier; and deleting the task records with the transaction identifications identical to the target identifications in the second database.

Optionally, when the third database adds a global transaction record, setting the transaction state of the global transaction record to a first state, and after confirming that the service data addition is complete, and updating the transaction state of the global transaction record to a second state, and updating the transaction state of the global transaction to a third state when the addition of the confirmation message data fails so as to record the state of the service.

Optionally, determining, according to the transaction annotation, message data corresponding to the second flow includes: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow;

According to the transaction annotation, determining the business data corresponding to the first flow comprises: and carrying out surrounding notification on transaction notes of the service according to the section-oriented programming so as to determine service data corresponding to the first procedure.

To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a service processing apparatus, the service including a first flow and a second flow, the first flow corresponding to a database operation and the second flow corresponding to a message sending operation, the apparatus comprising:

the annotation module is used for carrying out transaction annotation on the service and declaring to respectively treat the first flow and the second flow of the service as branch transactions of the distributed transaction;

the transaction processing module is used for starting a global transaction; determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database; after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction;

And the message sending module is used for generating and sending a message according to the message data in the second database so as to finish the service.

Optionally, the transaction processing module is further configured to: and adding a task record in the second database according to the message data, and setting the transaction state of the task record as a first state and the execution state as unexecuted. The method further comprises the steps of: and after confirming that the business data addition is completed, updating the transaction state of the task record from the first state to the second state.

Optionally, the transaction processing module is further configured to: when the service comprises a plurality of second flows, if the message data corresponding to any one of the second flows fails to be added, deleting task records corresponding to all the second flows of the service.

Optionally, the message sending module is further configured to: generating and sending a message according to the task record with the transaction state in the second database being the second state and the execution state being the unexecuted task; and after confirming that the message is successfully sent, updating the execution state of the task record from non-execution to successful execution.

Optionally, the message sending module is further configured to: if the message transmission fails, updating the execution state of the task record to be retried; based on the retry mechanism, the transaction state is the second state, the execution state is the task record to be retried, and the message is generated and sent.

Optionally, the task record includes a transaction identifier and a task identifier;

the transaction processing the module is also for: adding a global transaction record in a third database to open a global transaction; the global transaction record comprises task identifiers of a first flow and a second flow contained in the transaction identifier service;

the transaction module is further configured to: determining a transaction identifier of a second flow which fails to add message data, and taking the transaction identifier as a target identifier; and deleting the task records with the transaction identifications identical to the target identifications in the second database.

Optionally, the transaction processing module is further configured to:

setting the transaction state of the global transaction record as a first state when a global transaction record is added in a third database, updating the transaction state of the global transaction record as a second state after the completion of the addition of the service data is confirmed, and updating the transaction state of the global transaction as a third state when the addition of the service data is confirmed to be failed so as to record the state of the service.

Optionally, the transaction processing module is further configured to: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow;

And carrying out surrounding notification on transaction notes of the service according to the section-oriented programming so as to determine service data corresponding to the first procedure.

To achieve the above object, according to still another aspect of the embodiments of the present invention, there is provided an electronic device including: one or more processors; and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors are enabled to realize the service processing method of the embodiment of the invention.

To achieve the above object, according to one aspect of the embodiments of the present invention, there is provided a computer-readable medium having stored thereon a computer program which, when executed by a processor, implements a service processing method of the embodiments of the present invention.

One embodiment of the above invention has the following advantages or benefits: because transaction annotation is adopted for the service, the first flow and the second flow of the service are respectively treated as branch transactions of the distributed transaction; starting a global transaction; determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database; after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction; according to the information data in the second database, generating and sending information to complete the technical means of the service, the non-relational database operation and the relational database operation in the service are respectively treated as branch transactions of the distributed transaction, the non-relational database operation is treated according to a transaction mechanism, and then the relational database operation is treated, so that the data consistency of the two operations is ensured, the development difficulty and complexity are reduced, and the application range is wide.

Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a schematic diagram of a main flow of a service processing method according to an embodiment of the present invention;

FIG. 2 is a schematic illustration of a sub-flow of a business method according to another embodiment of the invention;

FIG. 3 is a schematic illustration of a sub-flow of a business method according to another embodiment of the invention;

FIG. 4-1 is a schematic illustration of a sub-flow of a business method according to another embodiment of the invention;

fig. 4-2 is a schematic diagram of a sub-flow of a business method according to another embodiment of the invention;

FIG. 5 is a schematic illustration of a sub-flow of a business method according to another embodiment of the invention;

fig. 6 is a schematic diagram of main modules of a service processing apparatus according to an embodiment of the present invention;

FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;

fig. 8 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Fig. 1 is a schematic diagram of main flows of a service processing method according to an embodiment of the present invention, where the service includes a first flow and a second flow, and in this embodiment, the first flow may also be referred to as a main flow, and the second flow may also be referred to as an edge flow. The first flow corresponds to a relational database operation (e.g., adding records or information to a database), i.e., the operation corresponding to the first flow is capable of providing a transaction mechanism, and the second flow corresponds to a non-relational database (NoSQL) operation (e.g., sending a message such as a mail, information, weChat, etc., to a third party or caching to a caching system), i.e., the operation corresponding to the second flow is incapable of providing a transaction mechanism. As shown in fig. 1, the method includes:

step S101: transaction annotation is performed on a service to declare that a first flow and a second flow of the service are respectively processed as branch transactions of a distributed transaction.

Annotation (Annoation), also called metadata, a description of the code level. It is a feature introduced by JDK1.5 and later versions, at the same level as class, interface, enumeration. It may be declared in front of packages, classes, fields, methods, local variables, method parameters, etc. to describe, annotate these elements. The annotation is present in the code under the '@ annotation name'.

In embodiments of the present invention, declarations of distributed transactions may be accomplished using an annotation mechanism. The annotation mechanism accomplishes the goal in an elegant manner, without any intrusiveness to the logical implementation of the business program itself. The transaction annotation is described below with an example of "user entry course".

In the above example, the @ psdtxttransaction notation represents a distributed transaction comprising a main flow and an edge flow, where the second attribute represents the method of the edge flow, the type of attribute is a String array (String array), which indicates that there may be multiple edge flows, the needleorder attribute represents whether the execution of the edge flow is sequential, and if needleorder is true, the execution order is determined by the respective positions in the array.

Step S102: the global transaction is started.

Step S103: and determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database. Specifically, the transaction annotation is parsed, a logic implementation corresponding to the second flow (i.e., a logic code and required parameters for implementing the second flow) is determined, and message data is generated according to the logic implementation corresponding to the second flow. The message data may include information such as contact information of the message receiver, specific message content, and message sending order. In the user entry course example described above, the message data may include information such as the name of the registrant, the contact address, the name of the course, and the time of lesson.

Step S104: after the completion of the message data addition is confirmed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database. Specifically, the transaction annotation is parsed, a logic implementation corresponding to the first flow (i.e., a logic code and required parameters for implementing the first flow) is determined, and service data is generated according to the logic implementation corresponding to the first flow. In the above example of the user registration course, the service data may include information such as a name of the registration person, a contact address, a name of the course, a time of lesson, and a cost of the course.

Step S105: after confirming that the business data addition is complete, the global transaction is ended (i.e., the global transaction is committed).

Step S106: and generating and sending a message according to the message data in the second database so as to complete the service.

Fig. 2, 3, 4-1 and 4-2 are schematic diagrams of main flows of a service processing method according to another embodiment of the present invention, the service including a first flow and a plurality of second flows, the first flow corresponding to database operations, each of the second flows corresponding to non-relational database operations. As shown in fig. 2, the method includes:

Step S201: the transaction annotation is made to the traffic, declaring to process the first flow and the second flow of the service as branch transactions of the distributed transaction respectively;

step S202: adding a global transaction record in a third database to start a global transaction, and setting the transaction state of the global transaction record as a first state; in this embodiment, the third database may be referred to as a global transaction database;

step S203: determining message data corresponding to each second flow according to the transaction annotation, adding the message data to a second database, and setting the transaction state of the task record as a first state and the execution state as unexecuted; in this embodiment, the second database may be referred to as a task database;

step S204: if the message data corresponding to any one of the second flows fails to be added, updating the transaction state of the global transaction record to a third state, and deleting the task records corresponding to all the second flows of the service;

step S205: if all the message data corresponding to the second flow are added, according to the transaction annotation, determining service data corresponding to the first procedure, and adding the service data to a first database; in this embodiment, the first database may be referred to as a service database;

Step S206: after confirming that the business data addition is completed, updating the transaction state of the global transaction record to a second state, then updating the transaction state of the task record to the second state,

step S207: generating and sending a message according to the task record with the transaction state in the second database being the second state and the execution state being the unexecuted task;

step S208: after confirming that the message is successfully sent, updating the execution state of the task record from non-execution to successful execution;

step S209: if the message transmission fails, updating the execution state of the task record to be retried;

step S210: based on the retry mechanism, the transaction state is the second state, the execution state is the task record to be retried, and the message is generated and sent.

For step S202, a task table may be created in the second database to save the task record.

In an alternative embodiment, the task table includes the following fields: task identification (e.g., task ID), global transaction identification (e.g., global transaction ID) corresponding to the task record, method information of edge flow (e.g., second Process Contents), identification of application (e.g., ID of application), task status, transaction status txstatus (transaction status refers to status of edge flow transaction corresponding to the task record), and execution order; the task state includes unexecuted, retried and completed. When a task record of the edge flow transaction is added in the task table, setting the task state of the task record as unexecuted; when the method of the edge flow corresponding to the task record fails to be executed, updating the task state of the task record to be retried; after the method of the edge flow corresponding to the task record is successfully executed, updating the task state of the task record to be completed; in other alternative embodiments, the task table may also include a task creation time createdTime and a latest update time lastUpdatedTime.

As a specific example, the first state may be denoted by "try", the second state may be denoted by "confirm", and the third state may be denoted by "cancel".

In an alternative embodiment, determining, according to the transaction annotation, message data corresponding to the second flow includes: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow; according to the transaction annotation, determining the business data corresponding to the first flow comprises: and carrying out surrounding notification on transaction notes of the service according to the section-oriented programming so as to determine service data corresponding to the first procedure.

Among them, AOP (Aspect Oriented Programming, slice-oriented programming) refers to a technology that realizes unified maintenance of program functions through a precompiled manner and a run-time dynamic proxy. The steps are realized by utilizing an AOP mechanism, so that the method is not invasive to the service, and the service logic is isolated from the method, so that the coupling degree between the service logic and the method is reduced, the reusability of the method is improved, and the development efficiency is improved.

Specifically, the AOP mechanism is utilized to carry out surrounding notification on @ PSDtxtransaction annotation on the register Coure method, so that enhancement logic is added before and after the register Coure method, the enhancement logic executes edge flow transaction according to a TCC transaction mode, after the edge flow transaction is executed successfully, main flow transaction is executed, and finally distributed transaction is completed. The enhancement logic first finds out the corresponding implementation methods of the second process attribute in the analysis @ PSDtxtransaction annotation, namely the doshendMail method and the doshendShortMsg method, and then completes the execution of the edge flow transaction and the main flow transaction try phase and the execution of the edge flow confirm phase according to the TCC mode. In the AOP mechanism, notification (address) refers to an action performed at a specific connection point of a slice. Surrounding notifications (Around) refers to surrounding a connection point notification, performing custom methods before and after the notified method call.

The embodiment realizes 'flexible transaction' by referring to the thought of a TCC mode, but does not need a main process to provide a confirm/cancel operation of a TCC requirement according to a 'resource pre-occupying' mode, and simultaneously automatically generates a try/confirm/cancel operation of the TCC requirement corresponding to an edge process, and the 'business non-invasiveness' of the whole technical scheme is basically ensured by using the skill. Specifically, please refer to fig. 3, 4-1 and 4-2.

The TCC mode is a mode of realizing distributed transaction, and corresponds to three operations, namely try, confirm and cancel, respectively, and the business meanings of the three operations are as follows: try: reserving service resources; confirm: confirming execution of business operation; cancel: and cancelling the execution of the business operation.

FIG. 3 shows a distributed transaction in the try phase. In the try phase, a global transaction is started (the execution state is try), then the try operation of the edge flow is completed in sequence, namely the task information warehousing operation is completed, the operation is completed in a local transaction mode (because the task database supports the transaction), and finally the try operation of the main flow is completed, namely the operation on the business database (also completed in a local transaction mode).

As shown in FIG. 4-1, when the try phase is completed successfully, the confirm phase is entered. Firstly, the global transaction state is updated to be confirm, and then the confirm operation of the edge flow is completed in sequence, namely, the transaction state of the corresponding task record is updated to be confirm. It is worth noting that the main flow does not require a confirm phase, so there is no corresponding confirm operation. After the edge flow transaction and the main flow transaction succeed, the global transaction is ended, and the global transaction record can be deleted so as to avoid accumulating too much occupied resources.

As shown in fig. 4-2, in the try phase, when any one of the edge flows fails to execute, the cancel phase is entered. Firstly, the global transaction state is updated to be 'cancel', and then the cancel operation of each edge flow which has succeeded before is completed in sequence, namely, the task record of the corresponding edge flow in the task database is deleted, so that the rollback operation is completed. After the cancel operation is completely successful, the global transaction is finished, and the global transaction record can be deleted so as not to accumulate too much occupied resources. It should be noted that when the execution of the main flow fails in the try stage, no rollback operation is needed (the service database will automatically rollback), and only the records of all the previous successful edge flows in the task database need to be deleted to complete the rollback operation. In the try phase, the task writing of the edge flow is firstly operated, N edge flows have N try operations (N is an integer greater than or equal to 1), 3 edge flows are assumed, the first 2 try operations succeed (namely, two corresponding database transactions are submitted), and finally 1 try operation fails, and the whole enters the cancer phase. In the cancel stage, since the first 2 writes have been successfully operated and cannot be rolled back by means of database transactions, the method of the embodiment of the present invention needs to set up to delete the task record of the corresponding edge flow in the task database to complete the rollback operation.

In the above procedure, only the edge flow may involve the rollback operation, while the main flow does not need the rollback operation, because it is performed last, and the business database will automatically rollback when an error occurs. The rollback operation of the edge flow naturally occurs idempotent because the taskId can uniquely determine a taskrecord. The try operation of the edge flow is to write the task information into the task database, the confirm operation is to set the txStatus field of the task to be 'confirm', and the cancel operation is to delete the corresponding record according to the task ID, and the three operations are automatically provided by the method of the embodiment of the invention. It follows that neither the edge flow nor the main flow needs the user to provide the try/confirm/cancel operation required by the TCC by himself, and only the logic implementation of the main flow and the edge flow needs to be provided.

Steps S208-S210 may be performed asynchronously and periodically, and process a batch of message data corresponding to the edge flow belonging to the application by appId.

In particular, as shown in fig. 5, this step may include:

step S501: inquiring a task table according to the app ID, determining that a plurality of txstatus are confirm and status is task records which are not executed or need to be retried, and forming a set 1;

Step S502: classifying the set 1 according to xid, sequencing the task records with the same xid to form a plurality of sets 2, and processing the sets 2 according to the following steps in sequence;

step S503: reading a task record in any one set 2;

step S504: performing deserialization on econdaryProcessContents, and executing a method of obtaining an edge flow by utilizing a reflection mechanism;

step S505: judging whether the execution is successful, if so, executing step S506, and if not, executing step S507;

step S506: updating the task state of the task record to be completed or deleted;

step S507: setting the task state of the task record to be retried;

step S508: judging whether order requirements exist;

step S509: judging whether all task records in the set 2 are traversed or not: if yes, go to step S510; if not, returning to step S504 to read the next task record in the set 2;

step S510: it is determined whether all sets 2 have been traversed.

For step S504, the content of the second process is obtained by using a reflection mechanism of a programming language such as Java for the method of the edge flow, and the result thereof can be expressed by the following pseudo code:

By serializing the invite data structure (e.g., using Kryo, etc. serialization techniques)) a byte sequence may be obtained that may be stored using the VARBINARY type of a relational database (e.g., mySQL). The method for any edge flow is processed, stored after serialization and executed after subsequent reverse serialization according to the method, so that the technical scheme is guaranteed to have universality.

Fig. 6 is a schematic diagram of main modules of a service processing apparatus 600 according to an embodiment of the present invention, and as shown in fig. 6, the apparatus 600 includes:

the annotation module 601 is configured to make transaction annotation on a service, and declare that a first flow and a second flow of the service are respectively used as branch transactions of a distributed transaction to be processed;

a transaction processing module 602, configured to open a global transaction; determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database; after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction;

And the message sending module 603 is configured to generate and send a message according to the message data in the second database, so as to complete the service.

Optionally, the transaction processing module 602 is further configured to: adding a task record in a second database according to the message data, and setting the transaction state of the task record as a first state and the execution state as unexecuted; and after confirming that the business data addition is completed, updating the transaction state of the task record from the first state to the second state.

Optionally, the transaction processing module 602 is further configured to: when the service comprises a plurality of second flows, if the message data corresponding to any one of the second flows fails to be added, deleting task records corresponding to all the second flows of the service.

Optionally, the message sending module 603 is further configured to: generating and sending a message according to the task record with the transaction state in the second database being the second state and the execution state being the unexecuted task; and after confirming that the message is successfully sent, updating the execution state of the task record from non-execution to successful execution.

Optionally, the message sending module 603 is further configured to: if the message transmission fails, updating the execution state of the task record to be retried; based on the retry mechanism, the transaction state is the second state, the execution state is the task record to be retried, and the message is generated and sent.

the transaction module 602 is further configured to: adding a global transaction record in a third database to open a global transaction; the global transaction record comprises a transaction identifier, and task identifiers of a first flow and a second flow contained in the service;

the transaction module 602 is further configured to: determining a transaction identifier of a second flow which fails to add message data, and taking the transaction identifier as a target identifier; and deleting the task records with the transaction identifications identical to the target identifications in the second database.

Optionally, the transaction processing module 602 is further configured to:

Optionally, the transaction processing module is further configured to: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow; and carrying out surrounding notification on transaction notes of the service according to the section-oriented programming so as to determine service data corresponding to the first procedure.

In an alternative embodiment, the service processing device of the embodiment of the present invention may be packaged as a software development kit (Software Development Kit, SDK), which will be denoted as a mode for convenience of description; or, the service processing device is packaged into a distributed transaction development tool package and a transaction management module, wherein the transaction management module is used for recording the state of the global transaction (i.e. adding the global transaction record and updating the transaction state of the global transaction record), and the mode is denoted as a mode B for convenience of description. The mode a can be divided into two modes, the mode A1 requires that the application program referencing the SDK of the embodiment of the present invention creates a task table and a global transaction table by itself, and the mode A2 requires that the application program referencing the SDK of the embodiment of the present invention shares the same set of task table and global transaction table. The A1 mode ensures the complete isolation of each application program. The A2 approach saves database resources, but when there are too many applications, the database connection resources may be a bottleneck. Whereas, the B-mode can overcome the problem of the A2-mode, because the application accesses the transaction management module via the network, the transaction management module is deployed for the cluster, and a plurality of application programs are supported, and the task table and the global transaction table in the mode B are only accessed by the transaction management module, so that only a small amount of database connection resources are needed.

In an alternative embodiment, the task database, the transaction management module and the global transaction database may be deployed on different servers to ensure isolation between the service program and the program according to the embodiment of the present invention, that is, the service program and the program according to the embodiment of the present invention will not interfere with each other, because once the service program interferes with the program according to the embodiment of the present invention, other applications will be globally affected to complete the distributed transaction.

The service program refers to the SDK of the embodiment of the invention, only the logic of the main flow and the edge flow is needed to be completed, and other functions are transparently completed by the SDK of the embodiment of the invention. The SDK of the embodiment of the invention completes the distributed transaction by cooperating with the transaction management module and the task database. The service program does not need to provide a task table or add task related fields and develop a compensation scheduling program in the main service table, so that thorough decoupling with the task table and compensation scheduling is realized, and the application is simplified. The SDK of the embodiment of the invention is responsible for starting and completing the whole distributed transaction by adopting RPC or HTTP communication with the transaction management module. Under the coordination of the transaction management module, the SDK of the embodiment of the invention firstly completes the local transaction of the task table (the task state of the task record is not executed), and then completes the local transaction of the main flow to the main service table. The flexible transaction is realized by taking the thought of the TCC type transaction into consideration, but the main process is not required to provide the confirm/cancel operation required by the TCC according to the 'resource pre-occupying' mode, and simultaneously the try/confirm/cancel operation required by the TCC corresponding to the edge process is automatically generated, so that the service non-invasiveness of the technical scheme of the embodiment of the invention is basically ensured by the use of the skill.

Fig. 7 illustrates an exemplary system architecture 700 for a distributed transaction processing method or a distributed transaction processing arrangement to which embodiments of the present invention may be applied.

As shown in fig. 7, a system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 is the medium used to provide communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may interact with the server 705 via the network 704 using the terminal devices 701, 702, 703 to receive or send messages or the like. Various communication client applications, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the terminal devices 701, 702, 703.

The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 705 may be a server providing various services, such as a background management server providing support for shopping-type websites browsed by the user using the terminal devices 701, 702, 703. The background management server can analyze and other processing on the received data such as the product information inquiry request and the like, and feed back processing results (such as target push information and product information) to the terminal equipment.

It should be noted that, the distributed transaction processing method provided in the embodiment of the present invention is generally executed by the server 705, and accordingly, the distributed transaction processing apparatus is generally disposed in the server 705.

It should be understood that the number of terminal devices, networks and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.

As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.

The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 808 including a network interface card such as a LAN card, a modem, or the like. The communication section 808 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. Removable media 811, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is mounted on the drive 810 as needed, so that the computer program read out therefrom is installed into the storage section 808 as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 808, and/or installed from the removable medium 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.

The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, it can be described as: a processor includes a sending module, an obtaining module, a determining module, and a first processing module. The names of these modules do not constitute a limitation on the unit itself in some cases, and for example, the transmitting module may also be described as "a module that transmits a picture acquisition request to a connected server".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include:

transaction annotation is carried out on the business, and the first flow and the second flow of the business are respectively declared to be treated as branch transactions of the distributed transaction;

starting a global transaction;

determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database;

after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database;

after confirming that the business data addition is completed, ending the global transaction;

and generating and sending a message according to the message data in the second database so as to complete the service.

The technical scheme of the embodiment of the invention adopts transaction annotation to the service to declare that the first flow and the second flow of the service are respectively used as branch transactions of the distributed transaction for processing; starting a global transaction; determining message data corresponding to the second flow according to the transaction annotation, and adding the message data to a second database; after confirming that the message data addition is completed, determining service data corresponding to the first flow according to the transaction annotation, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction; according to the information data in the second database, generating and sending information to complete the technical means of the service, the non-relational database operation and the relational database operation in the service are respectively treated as branch transactions of the distributed transaction, the non-relational database operation is treated according to a transaction mechanism, and then the relational database operation is treated, so that the data consistency of the two operations is ensured, the development difficulty and complexity are reduced, and the application range is wide.

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Claims

1. A method of processing a service, the service comprising a first flow and a second flow, the first flow corresponding to relational database operations and the second flow corresponding to non-relational database operations, the method comprising:

transaction annotation is carried out on the business so as to declare that the first flow and the second flow of the business are respectively used as branch transactions of the distributed transaction to be processed;

starting a global transaction;

determining a logic implementation corresponding to the second flow according to the transaction annotation, generating message data, and adding the message data to a second database;

after confirming that the message data addition is completed, determining logic implementation corresponding to the first flow according to the transaction annotation, generating service data, and adding the service data to a first database;

and generating and sending a message according to the task record of which the transaction state is the second state and the execution state is the unexecuted task data in the message data in the second database so as to finish the service.

2. The method of claim 1, wherein the adding of the message data to the second database comprises: adding a task record in a second database according to the message data, and setting the transaction state of the task record as a first state and the execution state as unexecuted;

the method further comprises the steps of: and after confirming that the business data addition is completed, updating the transaction state of the task record from the first state to the second state.

3. The method of claim 2, the method further comprising: when the service comprises a plurality of second flows, if the message data corresponding to any one of the second flows fails to be added, deleting task records corresponding to all the second flows of the service.

4. The method of claim 2, wherein generating and transmitting a message from the message data in the second database comprises:

Generating and sending a message according to the task record with the transaction state in the second database being the second state and the execution state being the unexecuted task;

and after confirming that the message is successfully sent, updating the execution state of the task record from non-execution to successful execution.

5. The method according to claim 4, wherein the method further comprises:

if the message transmission fails, updating the execution state of the task record to be retried;

based on the retry mechanism, the transaction state is the second state, the execution state is the task record to be retried, and the message is generated and sent.

6. A method according to claim 3, wherein the task record comprises a transaction identity and a task identity;

the opening the global transaction includes: adding a global transaction record in a third database to open a global transaction; the global transaction record comprises a transaction identifier, and task identifiers of a first flow and a second flow contained in the service;

deleting the task records corresponding to all the second procedures of the service comprises the following steps:

determining a transaction identifier of a second flow which fails to add message data, and taking the transaction identifier as a target identifier;

And deleting the task records with the transaction identifications identical to the target identifications in the second database.

7. The method of claim 6, wherein the method further comprises:

8. The method of claim 1, wherein determining message data corresponding to the second flow based on the transaction annotation comprises: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow;

9. A traffic processing apparatus, the traffic comprising a first flow and a second flow, the first flow corresponding to database operations and the second flow corresponding to messaging operations, the apparatus comprising:

the transaction processing module is used for starting a global transaction; determining a logic implementation corresponding to the second flow according to the transaction annotation, generating message data, and adding the message data to a second database; after confirming that the message data addition is completed, determining logic implementation corresponding to the first flow according to the transaction annotation, generating service data, and adding the service data to a first database; after confirming that the business data addition is completed, ending the global transaction;

and the message sending module is used for generating and sending a message according to the task record of which the transaction state of the message data in the second database is the second state and the execution state is the unexecuted task record so as to finish the service.

10. The apparatus of claim 9, wherein the transaction module is further to:

adding a task record in a second database according to the message data, and setting the transaction state of the task record as a first state and the execution state as unexecuted;

And after confirming that the business data addition is completed, updating the transaction state of the task record from the first state to the second state.

11. The apparatus of claim 10, the transaction module further to:

when the service comprises a plurality of second flows, if the message data corresponding to any one of the second flows fails to be added, deleting task records corresponding to all the second flows of the service.

12. The apparatus of claim 11, wherein the message sending module is further configured to:

13. The apparatus of claim 12, wherein the message sending module is further configured to:

14. The apparatus of claim 13, wherein the task record includes a transaction identification and a task identification;

the transaction module is further configured to: adding a global transaction record in a third database to open a global transaction; the global transaction record comprises a transaction identifier, and task identifiers of a first flow and a second flow contained in the service;

the transaction module is further configured to:

identifying transactions in a second database the target identifies the same task record deletion.

15. The apparatus of claim 14, wherein the transaction module is further configured to:

16. The apparatus of claim 9, wherein the transaction module is further to: performing surrounding notification on transaction notes of the service according to the section-oriented programming to determine message data corresponding to the second flow;

17. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs,

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-8.

18. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-8.