CN111198751A - Service processing method and device - Google Patents
Service processing method and device Download PDFInfo
- Publication number
- CN111198751A CN111198751A CN201811382764.6A CN201811382764A CN111198751A CN 111198751 A CN111198751 A CN 111198751A CN 201811382764 A CN201811382764 A CN 201811382764A CN 111198751 A CN111198751 A CN 111198751A
- Authority
- CN
- China
- Prior art keywords
- transaction
- state
- service
- flow
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000003672 processing method Methods 0.000 title abstract description 9
- 238000000034 method Methods 0.000 claims abstract description 95
- 238000012545 processing Methods 0.000 claims abstract description 46
- 230000008569 process Effects 0.000 claims abstract description 35
- 230000007246 mechanism Effects 0.000 claims abstract description 26
- 238000004590 computer program Methods 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000011161 development Methods 0.000 abstract description 7
- 238000010586 diagram Methods 0.000 description 17
- 238000004891 communication Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000002955 isolation Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 240000003864 Ulex europaeus Species 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 239000002253 acid Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000009545 invasion Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 231100000957 no side effect Toxicity 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a service processing method and a service processing device, and relates to the technical field of computers. One embodiment of the method comprises: performing transaction annotation on the business to state that a first flow and a second flow of the business are respectively treated as branch transactions of the distributed transaction; starting a global transaction; adding message data corresponding to the second process to a second database according to the transaction annotation; after the message data is confirmed to be added, adding the business data corresponding to the first flow to a first database according to the transaction annotation; after confirming that the business data is added, ending the transaction; and generating and sending a message according to the message data to finish the service. According to the implementation mode, the non-relational database operation in the service is treated as the branch transaction, the non-relational database operation is treated according to the 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 the complexity are reduced, and the application range is wide.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for processing a service.
Background
The transaction should have 4 attributes: atomicity (atomicity), consistency (consistency), isolation (isolation), and durability (durability). These four attributes are commonly referred to as ACID characteristics. The distributed transaction means that a participant of the transaction, a server supporting the transaction, a resource server and a transaction manager are respectively positioned on different nodes of different distributed systems. There is a "main flow and edge flow" scenario in a distributed transaction. For example, in the operation of "user registration course", the main flow is a database operation of the user registration course, and the edge flow is sending mail and short message notification. Similar situations exist in e-market scenarios, such as sending messages to other applications or writing cached data after database operations for inventory deduction are completed. The scenario of "main flow and edge flow" herein must conform to the transaction characteristics, and in the above example, if the user fails to register, but the user has sent "registered" short message and email, the user may be misunderstood, and if serious, the following may happen: the user goes to class and finds that the user does not register, so that the user runs once in a blank; if the user successfully registers but does not receive the short message or the mail, the user may miss the chance of having class and may cause a certain economic loss (class cost).
In a distributed transaction scenario of "main flow and edge flow", the main flow usually corresponds to operations of a relational database, such as MySQL, and the edge flow usually corresponds to a mail system, a short message system, a cache system, or other various non-relational database systems, which is different from a complete transaction mechanism provided by the relational database itself, and the systems corresponding to the edge flow do not provide a transaction mechanism. While the distributed transaction is composed of a plurality of local branch transactions, in the above example of "user entry course", the main flow and the edge flow correspond to two branch transactions. The edge flow often cannot provide a transaction mechanism, so that difficulty is brought to the completion of the whole distributed transaction. Such as the XA two-phase (XA distributed transaction protocol proposed by OracleTuxedo system) commit, which is a classic distributed transaction implementation, requires that all parties participating in the transaction must provide local transaction mechanisms and comply with 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 comprises the following steps: the main flow and the edge flow are packaged in a local database transaction, such as the main flow is executed first, and then the edge flow is executed. And (3) using an exception handling mechanism (try-catch method) of programming languages such as Java and the like, completing Transaction operation by using related database operation or using @ Transaction annotation, and when any one flow fails, causing the Transaction to roll back, and submitting the Transaction when all the flows are successful. The second method comprises the following steps: the main flow and the edge flow are usually treated independently, and retry (compensation) is continuously performed through a scheduling mechanism until all success is achieved. Specifically, as shown in fig. 1, a main flow task and an edge flow task are put into a scheduling system, a task (the state of the task is not executed or needs to be retried) is acquired, the task is executed, if the execution is successful, the task is deleted from the scheduling system or the state is set to be completed, and if the execution fails, the task state is set to need to be retried, and the next execution is waited.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:
first, data inconsistency may occur in some cases. For example, if the edge flow is a message, if a timeout exception occurs, a transaction is rolled back, so that the operation of the base table corresponding to the main flow does not occur (is rolled back), but the message may have been sent out, which causes a situation of data inconsistency. Since no retry is compensated for, a "permanent data inconsistency" may occur, which is not strictly useful.
In the second method, since the main flow and the edge flow are not packaged in a local transaction and are independent of each other, the data inconsistency is more likely to occur. Under the condition of no performance bottleneck or hardware and network faults, the time of data inconsistency can be very short, but under the condition of performance bottleneck or hardware and network faults, the inconsistency can be very long; due to the retry mechanism, the main flow and the edge flow are finally consistent in theory; since both the main flow and the edge flow may have retry situations, it is necessary to ensure idempotency (idempotency is that the result of one or more requests initiated by the user for the same operation is consistent, and no side effect is generated due to multiple clicks), and complexity increases for the application; a scheduling module needs to be developed, 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 one task 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, embodiments of the present invention provide a method and an apparatus for processing a service, in which a non-relational database operation and a relational database operation in a service are respectively treated as branch transactions of a distributed transaction, and the non-relational database operation is first processed according to a transaction mechanism, 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 an aspect of the embodiments of the present invention, there is provided a method for processing a service, where the service includes a first flow and a second flow, the first flow corresponds to a database operation, and the second flow corresponds to a message sending operation, the method including: performing transaction annotation on the service, and stating that the first flow and the second flow of the service are respectively processed as branch transactions of distributed transactions; starting a global transaction; determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, ending the global transaction; and generating and sending a message according to the message data in the second database to finish 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 following steps: and after the completion of the addition of the service data is confirmed, updating the transaction state of the task record from a first state to a second state.
Optionally, when the service includes a plurality of second flows, if the addition of the message data corresponding to any one of the second flows fails, the task records corresponding to all the second flows of the service are deleted.
Optionally, generating and sending a message according to the message data in the second database includes: generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed; and after the successful sending of the message is confirmed, 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; and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
Optionally, the task record includes a transaction identifier and a task identifier; the starting of the global transaction comprises: adding a global transaction record in a third database to start 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 processes 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 record with the same transaction identifier and target identifier in the second database.
Optionally, when adding a global transaction record to the third database, setting the transaction state of the global transaction record to be the first state, and after confirming that the service data addition is completed, updating the transaction state of the global transaction record to be the second state, and when confirming that the message data addition is failed, updating the transaction state of the global transaction to be the third state, so as to record the service state.
Optionally, according to the transaction annotation, determining the message data corresponding to the second flow includes: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as 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 the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a service processing apparatus, where the service includes a first flow and a second flow, the first flow corresponds to a database operation, and the second flow corresponds to a message sending operation, the apparatus including:
the annotation module is used for performing transaction annotation on the business and declaring that a first flow and a second flow of the business are respectively treated 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 process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, 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 complete the service.
Optionally, the transaction processing module is further configured to: and 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 following steps: and after the completion of the addition of the service data is confirmed, updating the transaction state of the task record from a first state to a second state.
Optionally, the transaction processing module is further configured to: when the service comprises a plurality of second flows, if the message data addition corresponding to any one of the second flows fails, deleting the task records corresponding to all the second flows of the service.
Optionally, the message sending module is further configured to: generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed; and after the successful sending of the message is confirmed, 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; and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
Optionally, the task record includes a transaction identifier and a task identifier;
the transaction processing module is further configured to: adding a global transaction record in a third database to start a global transaction; the global transaction record comprises task identifiers of a first flow and a second flow contained in the transaction identifier;
the transaction processing 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 record with the same transaction identifier and target identifier in the second database.
Optionally, the transaction processing module is further configured to:
when adding a global transaction record in a third database, setting the transaction state of the global transaction record as a first state, updating the transaction state of the global transaction record as a second state after confirming that the addition of the service data is completed, and updating the transaction state of the global transaction as a third state when confirming that the addition of the message data is failed so as to record the state of the service.
Optionally, the transaction processing module is further configured to: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine message data corresponding to the second flow;
and carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
To achieve the above object, according to still another aspect of embodiments of the present invention, there is provided an electronic apparatus including: one or more processors; 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 implement the service processing method of the embodiment of the invention.
To achieve the above object, according to an aspect of the embodiments of the present invention, there is provided a computer-readable medium on which a computer program is stored, the program implementing a service processing method of the embodiments of the present invention when executed by a processor.
One embodiment of the above invention has the following advantages or benefits: because the transaction annotation on the business is adopted, the first flow and the second flow of the business are declared to be respectively treated as branch transactions of the distributed transaction; starting a global transaction; determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, ending the global transaction; and generating and sending a message according to the message data in the second database to finish the technical means of the service, respectively processing the non-relational database operation and the relational database operation in the service as branch transactions of the distributed transaction, and processing the non-relational database operation according to a transaction mechanism and then processing the relational database operation, thereby ensuring the data consistency of the two operations, reducing the development difficulty and complexity and having wide application range.
Further effects of the above-mentioned non-conventional alternatives will be 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 diagram of a sub-flow of a business method according to another embodiment of the invention;
FIG. 3 is a schematic diagram of a sub-flow of a business method according to another embodiment of the invention;
FIG. 4-1 is a schematic diagram 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 diagram of a sub-flow of a business method according to another embodiment of the invention;
FIG. 6 is a schematic diagram of the main modules of a traffic 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 employed;
fig. 8 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as 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 a main flow of a service processing method according to an embodiment of the present invention, where the service includes a first flow and a second flow, 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 process corresponds to a relational database operation (e.g., adding records or information to a database), that is, the operation corresponding to the first process can provide a transaction mechanism, and the second process corresponds to a non-relational database (NoSQL) operation (e.g., sending a message such as a mail, a message, a WeChat, etc. to a third party or caching the message to a caching system), that is, the operation corresponding to the second process cannot provide a transaction mechanism. As shown in fig. 1, the method includes:
step S101: and performing transaction annotation on the business to state that the first flow and the second flow of the business are respectively treated as branch transactions of the distributed transaction.
Annotation (Annotation), 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 classes, interfaces, enumerations. It may be declared in front of a packet, class, field, method, local variable, method parameter, etc. to illustrate, annotate, etc. these elements. Annotations exist in the code with the '@ annotation name'.
In embodiments of the present invention, declarations of distributed transactions may be completed using an annotation mechanism. The annotation mechanism accomplishes the goal in an elegant manner without any intrusiveness into the logical implementation of the business program itself. The transaction annotation is described below with the example of "user entry lesson".
In the above example, the @ psdtxtraction annotation represents a distributed transaction including a main flow and an edge flow, wherein the second associaryprocess attribute represents a method of the edge flow, the type of the attribute is a String array (String array), which indicates that there may be a plurality of edge flows, the neededder attribute represents whether the execution of the edge flow has a precedence, and if the neededder is true, the execution order before and after the execution order is a position determination in the array respectively.
Step S102: a global transaction is started.
Step S103: and determining message data corresponding to the second process 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 (that is, 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 addresses of message recipients, specific message contents, and message sending orders. In the above example of the user registering course, the message data may include information of name, contact address, name of course, and time of day of the course of the registrant.
Step S104: and after the message data is confirmed to be added, determining the business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database. Specifically, the transaction annotation is analyzed, a logic implementation corresponding to the first flow (i.e., a logic code for implementing the first flow and required parameters) is determined, and the service data is generated according to the logic implementation corresponding to the first flow. In the above example of the user registering the course, the service data may include information such as name of the registrant, contact information, name of the course, time of the course, and cost of the course.
Step S105: and after the completion of the business data addition is confirmed, ending the global transaction (namely submitting the global transaction).
Step S106: and generating and sending a message according to the message data in the second database to finish the service.
Fig. 2, fig. 3, fig. 4-1 and fig. 4-2 are schematic diagrams of main flows of a service processing method according to another embodiment of the present invention, where the service includes a first flow and a plurality of second flows, the first flow corresponds to a database operation, and each of the second flows corresponds to a non-relational database operation. As shown in fig. 2, the method includes:
step S201: performing transaction annotation on the service, and stating that a first flow and a second flow of the service are respectively treated as branch transactions of a distributed transaction;
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 and the execution state of the task record as a first state and a non-execution state; in this embodiment, the second database may be referred to as a task database;
step S204: if the message data addition corresponding to any one of the second flows fails, 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 the addition of the message data corresponding to all the second flows is completed, determining the business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; in this embodiment, the first database may be referred to as a service database;
step S206: after the completion of the business data addition is confirmed, updating the transaction state of the global transaction record to a second state, and then updating the transaction state of the task record to the second state,
step S207: generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed;
step S208: after the message is confirmed to be 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: and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
For step S202, a task table may be created in the second database to save a task record.
In an alternative embodiment, the task table includes the following fields: task identification (such as task ID), global transaction identification (such as global transaction ID) corresponding to the task record, method information (such as subcondaryProcessContents) of the edge flow, identification of the application (such as ID of the application), task status, transaction status txstatus (the transaction status refers to the status of the edge flow transaction corresponding to the task record), and execution order; the task states include unexecuted, retried, and completed. When adding the task record of the edge flow affair 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 execute, the task state of the task record is updated 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 most recent update time lastUpdatedTime.
As a specific example, the first state may be represented by "try", the second state may be represented by "confirm", and the third state may be represented by "cancel".
In an optional embodiment, determining, according to the transaction annotation, the message data corresponding to the second flow includes: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as 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 the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
The AOP (Aspect organized Programming) refers to a technology for implementing unified maintenance of program functions by a pre-compiling mode and a running-period dynamic proxy. The steps are realized by utilizing an AOP mechanism, so that the method has no service invasion, and the service logic is isolated from the method, thereby reducing the coupling degree between the service logic and the method, improving the reusability of the method and improving the development efficiency.
Specifically, an AOP mechanism is utilized to perform surrounding notification on the @ PSDtxtransaction annotation on the register Corse method, so that enhancement logic is added before and after the register Corse method, the enhancement logic executes an edge flow transaction according to a TCC transaction mode, and after the edge flow transaction is successfully executed, a main flow transaction is executed, and finally a distributed transaction is completed. The enhancement logic firstly finds out corresponding implementation methods, namely a dosendMail method and a dosendShortMsg method, by analyzing the subcondaryProcess attribute in the @ PSDtxtransaction annotation, and then completes the execution of the edge flow transaction and main flow transaction try stages and the execution of the edge flow confirm stage according to the TCC mode. In the AOP mechanism, notification (Advice) refers to an action performed on a specific connection point of a tangent plane. Surround notification (Around) refers to a method that surrounds a nexus notification and that performs customization before and after the notified method invocation.
In the embodiment, a 'flexible transaction' is realized by taking the idea of the TCC mode as a reference, but the main process is not required to provide a confirm/cancel operation required by the TCC according to the 'resource preemption' mode, and a try/confirm/cancel operation required by the TCC corresponding to the edge process is automatically generated at the same time, so that the technical use fundamentally ensures 'business non-intrusiveness' of the whole technical scheme. Specifically, please refer to FIGS. 3, 4-1 and 4-2.
The TCC mode is a way for implementing distributed transactions, and corresponds to three operations, namely try, confirm and cancel, and the business meanings of the three operations are as follows: try: reserving service resources; confirm: confirming to execute business operation; cancel: and canceling the execution of the business operation.
FIG. 3 illustrates a distributed transaction in the try phase. In the try phase, a global transaction is started (the execution state is try), then try operation of the edge flow is completed in sequence, namely task information storage operation is completed, the operation is completed in the form of a local transaction (because the task database supports the transaction), and finally try operation of the main flow, namely operation on the service database (also completed in the form of the local transaction) is completed.
As shown in FIG. 4-1, when the try phase is successfully completed, the confirm phase is entered. The global transaction state is updated to confirm, and then the confirm operations of the edge flow are sequentially completed, namely the transaction state of the corresponding task record is updated to 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 are successful, the global transaction is ended, and the global transaction record can be deleted, so that too much occupied resources are prevented from being accumulated.
As shown in fig. 4-2, in the try phase, when any edge flow fails to execute, the cancel phase is entered. The global transaction state is firstly updated to 'cancel', and then the cancel operation of each edge flow which has been successful before is sequentially completed, that is, the task record of the corresponding edge flow in the task database is deleted, so as to complete the rollback operation. After the cancel operation is completely successful, the global transaction is ended, and the global transaction record can be deleted, so that too much occupied resources are prevented from being accumulated. It should be noted that when the main flow fails to execute in the try phase, a rollback operation is not needed (the business database is automatically rolled back), and all records of the previous successful edge flows in the task database are deleted to complete the rollback operation. In the try phase, task writing of the edge flow is operated first, N try operations (N is an integer greater than or equal to 1) are performed for N edge flows, assuming that there are 3 edge flows, the first 2 try operations are successful (i.e. two corresponding database transactions have already been submitted), and the last 1 try operation fails, and at this time, the whole is entered into cancel phase. In the cancel stage, since the first 2 writes have been successfully operated and rollback cannot be performed depending on database transactions, the method of the embodiment of the present invention needs to be configured to delete the task record of the corresponding edge flow in the task database to complete the rollback operation.
In the above process, only the edge flow may involve the rollback operation, while the main flow does not need the rollback operation because it is executed last, and the service database is automatically rolled back by mistake. The rollback operation of the edge flow is naturally idempotent in nature because a taskId can uniquely identify a taskrecord. The try operation of the edge flow is to write task information into a task database, the confirm operation is to set the txStatus field of the task as 'confirm', 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. Therefore, no matter whether the edge flow or the main flow, the user does not need to provide the try/confirm/cancel operation required by TCC, and only the logic implementation of the main flow and the edge flow is needed.
Steps S208-S210 can be completed asynchronously and executed periodically, and a batch of message data corresponding to the edge flow belonging to the application is fetched according to appId for processing.
Specifically, as shown in fig. 5, the step may include:
step S501: inquiring a task table according to the appID, and determining a plurality of txstatus as confirm and status as unexecuted or retry-needed task records to form a set 1;
step S502: classifying the sets 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 set 2;
step S504: deserializing the econdamycecessContents, acquiring a method of an edge flow by using a reflection mechanism, and executing the method of the edge flow;
step S505: judging whether the execution is successful, if so, executing step S506, otherwise, executing step S507;
step S506: updating the task state of the task record to be the completed task or deleting the task record;
step S507: setting the task state of the task record to be retried;
step S508: judging whether an order requirement exists;
step S509: judging whether all task records in the set 2 are traversed: if yes, go to step S510; if not, returning to the step S504 to read the next task record in the set 2;
step S510: it is determined whether all sets 2 have been traversed.
In step S504, the content of the second metadata 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 can be represented by the following pseudo code:
by serializing the Invocation data structure (e.g., using a serialization technique such as Kryo, etc.), a byte sequence can be obtained that can be stored in a relational database (e.g., MySQL) of the VARBINARY type. The method for processing any edge flow is processed, stored after serialization, subsequently deserialized and executed according to the method, and universality of the technical scheme is guaranteed.
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 perform transaction annotation on a service, and state that a first flow and a second flow of the service are respectively handled as branch transactions of a distributed transaction;
a transaction processing module 602, configured to start a global transaction; determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, ending the global transaction;
a message sending module 603, configured to generate a message according to the message data in the second database and send the message, 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 the completion of the addition of the service data is confirmed, updating the transaction state of the task record from a first state to a 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 addition corresponding to any one of the second flows fails, deleting the task records corresponding to all the second flows of the service.
Optionally, the message sending module 603 is further configured to: generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed; and after the successful sending of the message is confirmed, 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; and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
Optionally, the task record includes a transaction identifier and a task identifier;
the transaction module 602 is further configured to: adding a global transaction record in a third database to start 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 record with the same transaction identifier and target identifier in the second database.
Optionally, the transaction processing module 602 is further configured to:
when adding a global transaction record in a third database, setting the transaction state of the global transaction record as a first state, updating the transaction state of the global transaction record as a second state after confirming that the addition of the service data is completed, and updating the transaction state of the global transaction as a third state when confirming that the addition of the message data is failed so as to record the state of the service.
Optionally, the transaction processing module is further configured to: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine message data corresponding to the second flow; and carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
In an alternative embodiment, the service processing apparatus of the embodiment of the present invention may be packaged into a Software Development Kit (SDK), which is referred to as a mode a for convenience of description; or, the service processing apparatus is packaged into a distributed transaction development kit and a transaction management module, and the transaction management module is configured to record a state of the global transaction (i.e., add a global transaction record and update a transaction state of the global transaction record). 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 task table and global transaction table. The a1 approach ensures complete isolation of individual applications. The a2 approach saves database resources, but when there are too many applications, the database connection resources can become a bottleneck. The B mode can overcome the problem of the A2 mode, because the application program accesses the transaction management module through the network, the transaction management module is deployed for a cluster and supports a plurality of application programs, the task table and the global transaction table in the B mode are only accessed by the transaction management module, and 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 do not interfere with each other, because once the service program interferes with the program according to the embodiment of the present invention, other applications are globally affected to complete the distributed transaction.
The service program refers to the SDK of the embodiment of the invention, which only needs to complete the logic of the main flow and the edge flow, and the other processes are transparently completed by the SDK of the embodiment of the invention. The SDK of the embodiment of the invention completes distributed transactions by cooperating with the transaction management module and the task database. The service program does not need to provide a task table by itself or add task related fields and develop a compensation scheduling program in a main service table, so that complete decoupling with the task table and compensation scheduling is realized, and application is simplified. The SDK of the embodiment of the invention is in charge of starting and completing the whole distributed transaction by communicating with the transaction management module in an RPC or HTTP mode. Under the coordination of the transaction management module, the SDK according to the embodiment of the present invention first completes the local transaction to the task table (the task state of the task record is not executed), and then completes the local transaction to the main service table in the main process. Here, the concept of TCC-type transaction is used for reference to realize "flexible transaction", but the main process is not required to provide confirm/cancel operation required by TCC according to the "resource pre-occupation" mode, and simultaneously try/confirm/cancel operation required by TCC corresponding to the edge process is automatically generated, and the use of this skill fundamentally ensures non-intrusiveness of the service of the technical scheme of the embodiment of the present invention.
Fig. 7 illustrates an exemplary system architecture 700 to which the distributed transaction method or distributed transaction apparatus of embodiments of the invention may be applied.
As shown in fig. 7, the system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 serves to provide a medium for communication links between the terminal devices 701, 702, 703 and the server 705. Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use the terminal devices 701, 702, 703 to interact with a server 705 over a network 704, to receive or send messages or the like. Various communication client applications, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, and the like, may be installed on the terminal devices 701, 702, and 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 smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The server 705 may be a server that provides various services, such as a background management server that supports shopping websites browsed by users using the terminal devices 701, 702, and 703. The background management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (e.g., target push information and product information) to the terminal device.
It should be noted that the distributed transaction processing method provided by 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, shown is a block diagram of a computer system 800 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments 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 in accordance with 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 necessary for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and 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. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the 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 illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 808 and/or installed from the removable medium 811. The computer program executes the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 801.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination 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 present invention, 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, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. 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 flowchart 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 described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may 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 in some cases constitute a limitation on the unit itself, and for example, the sending module may also be described as a "module that sends 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 separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:
performing transaction annotation on the service, and stating that the first flow and the second flow of the service are respectively processed as branch transactions of distributed transactions;
starting a global transaction;
determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database;
after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database;
after confirming that the service data is added completely, ending the global transaction;
and generating and sending a message according to the message data in the second database to finish the service.
According to the technical scheme of the embodiment of the invention, transaction annotation is carried out on the service so as to state that the first flow and the second flow of the service are respectively treated as branch transactions of distributed transactions; starting a global transaction; determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, ending the global transaction; and generating and sending a message according to the message data in the second database to finish the technical means of the service, respectively processing the non-relational database operation and the relational database operation in the service as branch transactions of the distributed transaction, and processing the non-relational database operation according to a transaction mechanism and then processing the relational database operation, thereby ensuring the data consistency of the two operations, reducing the development difficulty and complexity and having wide application range.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (18)
1. A method for processing a service, the service comprising a first process and a second process, the first process corresponding to relational database operations and the second process corresponding to non-relational database operations, the method comprising:
performing transaction annotation on the business to state that a first flow and a second flow of the business are respectively treated as branch transactions of the distributed transaction;
starting a global transaction;
determining message data corresponding to the second process according to the transaction annotation, and adding the message data to a second database;
after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database;
after confirming that the service data is added completely, ending the global transaction;
and generating and sending a message according to the message data in the second database to finish the service.
2. The method of claim 1, wherein adding 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 following steps: and after the completion of the addition of the service data is confirmed, updating the transaction state of the task record from a first state to a second state.
3. The method of claim 2, further comprising: when the service comprises a plurality of second flows, if the message data addition corresponding to any one of the second flows fails, deleting the task records corresponding to all the second flows of the service.
4. The method of claim 2, wherein generating and sending messages based on the message data in the second database comprises:
generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed;
and after the successful sending of the message is confirmed, updating the execution state of the task record from non-execution to successful execution.
5. The method of claim 4, further comprising:
if the message transmission fails, updating the execution state of the task record to be retried;
and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
6. The method of claim 3, wherein the task record comprises a transaction identifier and a task identifier;
the starting of the global transaction comprises: adding a global transaction record in a third database to start 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 processes 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 record with the same transaction identifier and target identifier in the second database.
7. The method of claim 6, further comprising:
when adding a global transaction record in a third database, setting the transaction state of the global transaction record as a first state, updating the transaction state of the global transaction record as a second state after confirming that the addition of the service data is completed, and updating the transaction state of the global transaction as a third state when confirming that the addition of the message data is failed so as to record the state of the service.
8. The method of claim 1, wherein determining, from the transaction annotation, message data corresponding to the second flow comprises: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as 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 the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
9. An apparatus for processing a service, the service comprising a first process and a second process, the first process corresponding to a database operation and the second process corresponding to a message sending operation, the apparatus comprising:
the annotation module is used for performing transaction annotation on the business and declaring that a first flow and a second flow of the business are respectively treated 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 process according to the transaction annotation, and adding the message data to a second database; after the message data is confirmed to be added, determining business data corresponding to the first flow according to the transaction annotation, and adding the business data to a first database; after confirming that the service data is added completely, 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 complete the service.
10. The apparatus of claim 9, wherein the transaction processing module 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 the completion of the addition of the service data is confirmed, updating the transaction state of the task record from a first state to a second state.
11. The apparatus of claim 10, the transaction processing module further to:
when the service comprises a plurality of second flows, if the message data addition corresponding to any one of the second flows fails, deleting the task records corresponding to all the second flows of the service.
12. The apparatus of claim 11, wherein the messaging module is further configured to:
generating a message and sending the message according to the task record in the second database, wherein the transaction state is a second state, and the execution state is not executed;
and after the successful sending of the message is confirmed, updating the execution state of the task record from non-execution to successful execution.
13. The apparatus of claim 12, wherein the messaging module is further configured to:
if the message transmission fails, updating the execution state of the task record to be retried;
and based on a retry mechanism, generating and sending a message by taking the transaction state as a second state and the execution state as a task record needing retry.
14. The apparatus of claim 13, wherein the task record comprises a transaction identifier and a task identifier;
the transaction processing module is further configured to: adding a global transaction record in a third database to start 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 processing 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 record with the same transaction identifier and target identifier in the second database.
15. The apparatus of claim 14, wherein the transaction processing module is further configured to:
when adding a global transaction record in a third database, setting the transaction state of the global transaction record as a first state, updating the transaction state of the global transaction record as a second state after confirming that the addition of the service data is completed, and updating the transaction state of the global transaction as a third state when confirming that the addition of the message data is failed so as to record the state of the service.
16. The apparatus of claim 9, wherein the transaction processing module is further configured to: carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine message data corresponding to the second flow;
and carrying out surrounding notification on the transaction annotation of the service according to the section-oriented programming so as to determine the service data corresponding to the first flow.
17. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.
18. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811382764.6A CN111198751B (en) | 2018-11-20 | 2018-11-20 | Service processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811382764.6A CN111198751B (en) | 2018-11-20 | 2018-11-20 | Service processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111198751A true CN111198751A (en) | 2020-05-26 |
| CN111198751B CN111198751B (en) | 2024-02-02 |
Family
ID=70746112
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811382764.6A Active CN111198751B (en) | 2018-11-20 | 2018-11-20 | Service processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111198751B (en) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111813791A (en) * | 2020-06-17 | 2020-10-23 | 上海悦易网络信息技术有限公司 | Method and equipment for distributed transaction compensation |
| CN112559140A (en) * | 2020-12-17 | 2021-03-26 | 江苏满运物流信息有限公司 | Transaction control method, system, equipment and storage medium for data consistency |
| CN112671827A (en) * | 2020-11-25 | 2021-04-16 | 紫光云技术有限公司 | Distributed transaction final consistency method |
| CN113110949A (en) * | 2021-04-29 | 2021-07-13 | 中科院计算所南京研究院 | Single-terminal multi-process coexistence processing method and device |
| CN113268471A (en) * | 2021-06-24 | 2021-08-17 | 京东科技控股股份有限公司 | Method, proxy connection pool, system, device, and medium for processing distributed transactions |
| CN113760924A (en) * | 2020-10-28 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Distributed transaction processing method and device |
| CN113761056A (en) * | 2021-04-07 | 2021-12-07 | 西安京迅递供应链科技有限公司 | Distributed service processing method, device and system |
| CN113992750A (en) * | 2020-07-10 | 2022-01-28 | 华为技术有限公司 | Global transaction coordination method, device, equipment and medium |
| WO2023273028A1 (en) * | 2021-06-29 | 2023-01-05 | 深圳市商汤科技有限公司 | Transaction processing method and related product |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030191608A1 (en) * | 2001-04-30 | 2003-10-09 | Anderson Mark Stephen | Data processing and observation system |
| CN102056111A (en) * | 2011-01-28 | 2011-05-11 | 东方通信股份有限公司 | System and method for realizing uniformly accessing and managing signal of value-added service platform |
| CN102073505A (en) * | 2011-01-31 | 2011-05-25 | 北京科技大学 | Service composition-oriented declarative transaction integration method and system |
| CN106775959A (en) * | 2016-12-06 | 2017-05-31 | 上海亿账通互联网科技有限公司 | Distributed transaction processing method and system |
| CN108009027A (en) * | 2017-11-23 | 2018-05-08 | 北京百度网讯科技有限公司 | Implementation method, device, equipment and the storage medium of queue message uniformity |
-
2018
- 2018-11-20 CN CN201811382764.6A patent/CN111198751B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030191608A1 (en) * | 2001-04-30 | 2003-10-09 | Anderson Mark Stephen | Data processing and observation system |
| CN102056111A (en) * | 2011-01-28 | 2011-05-11 | 东方通信股份有限公司 | System and method for realizing uniformly accessing and managing signal of value-added service platform |
| CN102073505A (en) * | 2011-01-31 | 2011-05-25 | 北京科技大学 | Service composition-oriented declarative transaction integration method and system |
| CN106775959A (en) * | 2016-12-06 | 2017-05-31 | 上海亿账通互联网科技有限公司 | Distributed transaction processing method and system |
| CN108009027A (en) * | 2017-11-23 | 2018-05-08 | 北京百度网讯科技有限公司 | Implementation method, device, equipment and the storage medium of queue message uniformity |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111813791A (en) * | 2020-06-17 | 2020-10-23 | 上海悦易网络信息技术有限公司 | Method and equipment for distributed transaction compensation |
| CN111813791B (en) * | 2020-06-17 | 2024-05-21 | 上海万物新生环保科技集团有限公司 | Distributed transaction compensation method and equipment |
| CN113992750A (en) * | 2020-07-10 | 2022-01-28 | 华为技术有限公司 | Global transaction coordination method, device, equipment and medium |
| CN113760924A (en) * | 2020-10-28 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Distributed transaction processing method and device |
| CN112671827B (en) * | 2020-11-25 | 2023-03-07 | 紫光云技术有限公司 | Distributed transaction final consistency method |
| CN112671827A (en) * | 2020-11-25 | 2021-04-16 | 紫光云技术有限公司 | Distributed transaction final consistency method |
| CN112559140A (en) * | 2020-12-17 | 2021-03-26 | 江苏满运物流信息有限公司 | Transaction control method, system, equipment and storage medium for data consistency |
| CN112559140B (en) * | 2020-12-17 | 2022-07-26 | 江苏满运物流信息有限公司 | Transaction control method, system, equipment and storage medium for data consistency |
| CN113761056A (en) * | 2021-04-07 | 2021-12-07 | 西安京迅递供应链科技有限公司 | Distributed service processing method, device and system |
| CN113110949A (en) * | 2021-04-29 | 2021-07-13 | 中科院计算所南京研究院 | Single-terminal multi-process coexistence processing method and device |
| CN113110949B (en) * | 2021-04-29 | 2023-10-13 | 中科南京信息高铁研究院 | Single-terminal multi-flow coexistence processing method and device |
| CN113268471B (en) * | 2021-06-24 | 2023-09-22 | 京东科技控股股份有限公司 | Method, proxy connection pool, system, device and medium for processing distributed transaction |
| CN113268471A (en) * | 2021-06-24 | 2021-08-17 | 京东科技控股股份有限公司 | Method, proxy connection pool, system, device, and medium for processing distributed transactions |
| WO2023273028A1 (en) * | 2021-06-29 | 2023-01-05 | 深圳市商汤科技有限公司 | Transaction processing method and related product |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111198751B (en) | 2024-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111198751B (en) | Service processing method and device | |
| CN108846753B (en) | Method and apparatus for processing data | |
| US11681683B2 (en) | Transaction compensation for single phase resources | |
| CN111309747A (en) | Data synchronization method, system and device | |
| CN111831461A (en) | Method and device for processing business process | |
| CN111126948A (en) | Processing method and device for approval process | |
| CN110109983B (en) | Method and device for operating Redis database | |
| CN113760991A (en) | Data operation method and device, electronic equipment and computer readable medium | |
| CN111881216A (en) | Data acquisition method and device based on shared template | |
| US9473561B2 (en) | Data transmission for transaction processing in a networked environment | |
| CN111309366B (en) | Method, device, medium and electronic equipment for managing registration core | |
| CN108833147B (en) | Configuration information updating method and device | |
| CN115658171A (en) | Method and system for solving dynamic refreshing of java distributed application configuration in lightweight mode | |
| CN113760924B (en) | Distributed transaction processing method and device | |
| US10831590B2 (en) | Error handling | |
| CN113553206B (en) | Data event execution method and device, electronic equipment and computer readable medium | |
| US9130881B2 (en) | Direct return to source (DRS) routing of customer information control systems (CICS) transactions | |
| WO2023273028A1 (en) | Transaction processing method and related product | |
| CN113779122A (en) | Method and apparatus for exporting data | |
| CN113347052A (en) | Method and device for counting user access data through access log | |
| US9104776B2 (en) | Efficient identity mapping with self-correction for cascaded server systems | |
| CN113448960A (en) | Method and device for importing form file | |
| CN111771191A (en) | Cross-domain inline event handler | |
| US20220191104A1 (en) | Access management for a multi-endpoint data store | |
| US8484235B2 (en) | Dynamically switching the serialization method of a data structure |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |