Patent Description:
The present disclosure relates to the field of computers, and specifically, to a distributed transaction processing technology.

In a process of performing a transaction such as access or modification on data items included in a computer database, transaction commit is usually completed according to established processing steps. If there is a catastrophic failure in a commit process and the foregoing established processing steps are interrupted, the commit process of the foregoing transaction needs to be resumed.

However, for a distributed transaction, since different distributed devices in a distributed system are involved, once the processing steps are interrupted, transaction processing statuses in the different distributed devices will be inconsistent, causing a problem that the accuracy of distributed transaction processing cannot be ensured.

For the foregoing problem, there is no effective solutions yet.

<CIT> describes a method for committing a distributed transaction in a distributed database system. The database system includes an interval coordinator, a plurality of database server programs, called coservers, and at least one transaction log. More than one coserver can operate on a single computer or node, and the coservers could share a transaction log. The interval coordinator sends each coserver a succession of interval messages, and each coserver flushes its associated transaction log to non-volatile storage in response. After flushing its transaction log, each coserver transmits a closure message to the interval coordinator. The coservers maintain a state which identifies the most recently received interval message. Each distributed transaction includes an owner and a non-owner, or helper. For a transaction, the owner transmits a request message to the helper identifying an operation in the distributed transaction for the coserver to execute. Upon execution of the operation, the coserver transmits a completion message to the owner with a tag identifying the most recently received interval message. After receiving said completion message, the owner transmits an eligibility message for the transaction to the interval coordinator. Then the interval coordinator writes a commit state for the transaction to stable storage. Then the interval coordinator sends the owner and helper a commit message for the transaction.

Embodiments of the present disclosure provide a method and apparatus, a storage medium, and an electronic apparatus for distributed transaction processing, to at least resolve a technical problem that the accuracy of distributed transaction processing cannot be ensured when established steps of a distributed transaction are interrupted.

A distributed transaction processing method is provided, including: obtaining, by a distributed transaction processing device, a distributed transaction processing request, the distributed transaction processing request being used for requesting to perform a processing operation on account data in N accounts, the account data in the N accounts being located in M first object database sets, the M first object database sets being included in a target database cluster, N being an integer greater than <NUM>, and M being an integer greater than <NUM>; writing, by the distributed transaction processing device, a commit log corresponding to the distributed transaction processing request to a second object database set, the commit log comprising a commit indication result being recorded and used for indicating whether the processing operation on the account data in the N accounts is committed; the second object database set being included in the target database cluster; obtaining, by the distributed transaction processing device after the distributed transaction processing device resumes distributed transaction processing, the commit log from the second object database set; and performing, by the distributed transaction processing device if the commit indication result in the commit log instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts.

A distributed transaction processing apparatus is further provided, the apparatus being configured to perform the distributed transaction processing method provided in the embodiments of the present disclosure. A storage medium is further provided, the storage medium storing a computer program, the computer program being configured to perform the foregoing distributed transaction processing method when being run.

An electronic apparatus is further provided, the electronic apparatus including a memory, a processor, and a computer program that is stored in the memory and can be run on the processor, the processor being configured to perform the foregoing distributed transaction processing method through the computer program.

A computer program product is further provided, the computer program product including an instruction, the instruction, when being run on a computer, causing the computer to perform the foregoing distributed transaction processing method.

After obtaining a distributed transaction processing request used for requesting to perform a processing operation on account data in N accounts, a distributed transaction processing device writes a commit log corresponding to the distributed transaction request to a second object database set, a commit indication result corresponding to the distributed transaction processing request being recorded in the commit log, and the commit indication result being used for indicating whether the processing operation on the account data in the N accounts is committed. The account data in the N accounts is located in M first object database sets included in a target database cluster, and the target database cluster further includes the second object database set to which the commit log is written. After resuming distributed transaction processing, the distributed transaction processing device obtains the commit log from the second object database set, and performs, if the commit indication result instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts. The commit log corresponding to the distributed transaction processing request is written to the second object database set instead of being cached locally only, so that if there is a failure during the process of distributed transaction processing, the processing operation on the account data in the N accounts is resumed by using the commit log written to the second object database set, and therefore transaction processing statuses in different distributed devices may be consistent, thereby ensuring the accuracy of distributed transaction processing, and further overcoming the problem of low accuracy of distributed transaction processing in the related art. The scope of the invention is determined by the appended independent claims.

Accompanying drawings described herein are used to provide further understanding about the present disclosure, and constitute one portion of this application. Exemplary embodiments of the present disclosure and their descriptions are used to explain the present disclosure, and do not constitute an inappropriate limitation on the present disclosure. In the accompanying drawings:.

To make a person skilled in the art better understand solutions of the present disclosure, the following clearly and completely describes the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are some of the embodiments of the present disclosure rather than all of the embodiments.

In the specification, claims, and accompanying drawings of the present disclosure, the terms "first", "second" and so on are intended to distinguish between similar objects but do not necessarily indicate a specific order or sequence. It is to be understood that data used in this way is exchangeable in a proper case, so that the embodiments of the present disclosure described herein can be implemented in another order except those shown or described herein. In addition, the terms "include", "comprise" and any other variants are intended to cover the non-exclusive inclusion. For example, a process, method, system, product, or device that includes a list of steps or units is not necessarily limited to those expressly listed steps or units, but may include other steps or units not expressly listed or inherent to such a process, method, product, or device.

According to an aspect of the embodiments of the present disclosure, a distributed transaction processing method is provided. In an optional implementation, the distributed transaction processing method provided in the embodiments of the present disclosure may be applied to, but not limited to, an environment shown in <FIG>.

User equipment <NUM> is configured to complete a human-computer interaction process with a user <NUM>. For example, the user <NUM> may perform a processing operation on account data of an account running in the user equipment <NUM> through human-computer interaction operations. The user equipment <NUM> is provided with a memory <NUM> and a processor <NUM>. The foregoing processing operation includes but is not limited to a processing operation on account data in N accounts requested by a distributed transaction processing request, the account data in the N accounts being located in M first object database sets <NUM> included in a target database cluster <NUM>. After obtaining the distributed transaction processing request, the user equipment <NUM> writes a commit log corresponding to the distributed transaction processing request to a second object database set <NUM> included in the target database cluster <NUM> through a network <NUM>, as in step S102. The foregoing commit log is used for recording a commit indication result corresponding to the distributed transaction processing request, and the commit indication result is used for indicating whether the processing operation on the account data in the N accounts is committed. The foregoing target database cluster <NUM> includes the first object database sets <NUM> and the second object database set <NUM>, the M first object database sets <NUM> are used for storing the account data in the N accounts, and the second object database set <NUM> is used for storing the foregoing commit log. After resuming distributed transaction processing, the user equipment <NUM> obtains the commit log from the second object database set, and performs, if the commit indication result in the commit log instructs that the processing operation can be committed, the processing operation requested by the foregoing distributed transaction processing request, that is, performs the processing operation on the account data in the N accounts in the M first object database sets.

After a distributed transaction processing request used for requesting to perform a processing operation on account data in N accounts is obtained, a commit log corresponding to the distributed transaction processing request is written to a second object database set, a commit indication result corresponding to the distributed transaction processing request being recorded in the commit log. The account data in the N accounts is located in M first object database sets included in a target database cluster, and the target database cluster further includes the second object database set to which the commit log is written. After distributed transaction processing is resumed, the commit log is obtained from the second object database set, and if the commit indication result in the commit log indicates commit, the processing operation is performed on the account data in the N accounts. The commit log corresponding to the distributed transaction processing request is written to the second object database set instead of being cached locally only, so that if there is a failure during the process of the distributed transaction processing, the processing operation on the account data in the N accounts is resumed by using the commit log written to the second object database set, and therefore transaction processing statuses in different distributed devices may be consistent, thereby ensuring the accuracy of distributed transaction processing, and further overcoming the problem of low accuracy of distributed transaction processing in the related art.

Optionally, the foregoing user equipment may be, but is not limited to, any hardware device that can perform distributed transaction processing, for example, a mobile phone, a tablet computer, a notebook computer, a personal computer (PC), and the like; and the foregoing network may include but is not limited to a wired network. The foregoing wired network may include but is not limited to: a wide area network, a metropolitan area network, and a local area network.

As shown in <FIG>, the foregoing distributed transaction processing method includes the following steps:
S202. Obtain a distributed transaction processing request.

The distributed transaction processing request is used for requesting to perform a processing operation on account data in N accounts, the account data in the N accounts is located in M first object database sets, the M first object database sets are included in a target database cluster, N is an integer greater than <NUM>, and M is an integer greater than <NUM>.

Write a commit log corresponding to the distributed transaction processing request to a second object database set.

A commit indication result is recorded in the commit log, the commit indication result is used for indicating whether the processing operation on the account data in the N accounts is committed, and the second object database set is included in the target database cluster.

Obtain, after distributed transaction processing is resumed, the commit log from the second object database set.

Perform, if the commit indication result in the commit log instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts.

The foregoing distributed transaction processing method is applied to, but is not limited to, a distributed transaction processing system. The distributed transaction processing system may include: a financial system that relates to distributed transaction processing such as transferring funds between a plurality of accounts (for example, transaction or payment of funds held by the accounts); and may further include: a game system that relates to distributed transaction processing such as transferring virtual resources between a plurality of accounts (for example, transfer or exchange of characters, props, and equipment held by the accounts). The foregoing description is merely an example, which is not limited in this embodiment.

After a distributed transaction processing request for performing a processing operation on account data in N accounts is obtained, the account data in the N accounts being located in M first object databases included in a target database cluster, a commit log corresponding to the distributed transaction processing request is written to a second object database set included in the target database cluster, so that the processing operation requested by the foregoing distributed transaction processing request is performed on the account data in the N accounts in the M first object database sets by using a commit indication result recorded in the commit log. In other words, the commit log corresponding to the distributed transaction processing request is written to the second object database set instead of being cached locally, so that if there is a failure during the process of distributed transaction processing, the processing operation on the account data in the N accounts may be resumed by using the commit log written to the second object database set, thereby ensuring the accuracy of distributed transaction processing.

A distributed transaction requested by the foregoing distributed transaction processing request is to perform a processing operation on account data in N accounts, the account data in the N accounts being located in a target database cluster. The target database cluster includes M first object database sets used for storing the account data in the N accounts and a second object database set to which the commit log corresponding to the foregoing distributed transaction processing request is written.

In this embodiment, the account quantity N of the N accounts involved in the distributed transaction processing request and the database set quantity M of the M first object database sets may or may not be equal. For example, if N is equal to M, it indicates that account data of each account is stored in one corresponding first object database set; if N is greater than M, it indicates that account data of at least two accounts is stored in the same first object database set; and if N is less than M, it indicates that account data of one account is stored in different first object database sets in a distributed manner.

Optionally, in this embodiment, the foregoing commit log corresponding to the distributed transaction processing request may record but not limited to, in the form of a data table, two fields associated with the distributed transaction, that is, an identifier of the distributed transaction and a commit indication result of the distributed transaction. The foregoing commit indication result includes: commit and rollback. That is, if the commit indication result indicates "commit", the corresponding processing operation requested by the distributed transaction processing request is performed on the account data of the N accounts; and if the commit indication result indicates "rollback", the distributed transaction requested by the distributed transaction processing request is rolled back, in which case the distributed transaction processing request is re-acquired, and a commit operation on the distributed transaction is prepared again.

Optionally, in this embodiment, the foregoing second object database set includes a primary database (also referred to as a primary database instance) and a standby database (also referred to as a standby database instance). Databases in the second object database set may implement strong data synchronization, that is, the primary database will be directly copied to the standby database, to avoid data loss. In this embodiment, when written to the second object database set, the foregoing commit log may be written to, but is not limited to, the primary database, and then is synchronously copied to the corresponding standby database.

Optionally, in this embodiment, if there is a failure during the process of distributed transaction processing, the process of distributed transaction processing may be resumed by using the commit log written to the foregoing second object database. Assuming there are i written commit logs, the first to the ith commit logs may be sequentially read, so identifiers of distributed transactions to be processed may be obtained according to the foregoing commit logs, and the corresponding distributed transactions are performed sequentially, thereby avoiding a condition of inconsistent distributed transaction statuses.

Description is made with reference to an example shown in <FIG>. It is assumed that the distributed transaction processing method may be applied to, but is not limited to, a distributed transaction processing architecture shown in <FIG>. The foregoing object database set may be represented by, but is not limited to, a back-end set in this architecture, and the foregoing distributed transaction processing request may be generated in, but is not limited to, a gateway in this architecture. The foregoing gateway is configured with a transaction manager (TM) which is configured to coordinate the distributed transaction requested by the foregoing distributed transaction processing request, and the foregoing back-end set is used for storing the account data associated with the distributed transaction, and is equivalent to a resource manager (RM).

In a possible implementation, as shown in <FIG>, it is assumed that the target database cluster includes three object database sets that are set1 to set3, respectively. The obtained distributed transaction requested by the distributed transaction processing request is to perform a processing operation on account data of three accounts located in two first object database sets (for example, set1 and set2), and the three accounts are account <NUM> to account <NUM>, respectively. Account data in account <NUM> and account <NUM> is stored in set1, and account data in account <NUM> is stored in set2.

For example, a gateway <NUM> serves as the distributed transaction processing device, and the gateway <NUM> obtains a distributed transaction processing request. For example, a distributed transaction requested by the distributed transaction processing request is that: account <NUM> transfers <NUM> yuan to account <NUM>, and transfers <NUM> yuan to account <NUM> at the same time. A commit log corresponding to the distributed transaction processing request is obtained, and the commit log is written to a second object database set included in the aforementioned target database cluster. Assuming that the selected second object database set is set3, then the foregoing commit log is written to set3. If a commit indication result in the commit log is "commit", <NUM> yuan is subtracted from the total asset value of account <NUM> in set3, and <NUM> yuan is added to the total asset value of each of account <NUM> and account <NUM> respectively, to complete the processing operation requested by the distributed transaction processing request.

In a possible implementation, in the case of a power failure of the gateway <NUM>, through the method provided in this embodiment, the commit log may still be obtained from set3 without relying on the commit log cached in the transaction manager TM in the gateway <NUM>, thereby avoiding a problem of low processing accuracy caused by inconsistent data statuses among distributed devices due to a failure condition.

In this embodiment provided in this application, the commit log corresponding to the distributed transaction processing request is written to the second object database set instead of being cached locally, so that if there is a failure during the process of distributed transaction processing, the processing operation on the account data in the N accounts in the M first object database sets may be resumed by using the commit log written to the second object database set, thereby ensuring the accuracy of distributed transaction processing.

In an optional solution, the writing a commit log corresponding to the distributed transaction processing request to a second object database set includes the following steps:.

In the related art, the foregoing commit log may be cached in the transaction manager TM. However, in the case of a failure of the gateway where the transaction manager TM is located, the commit log corresponding to the distributed transaction processing request that is cached locally cannot be obtained, causing the problem of transaction processing statuses in distributed devices associated with the distributed transaction.

In this embodiment, the cached commit log is written to the second object database set at the back end in a distributed storage manner, and data synchronization is performed on the commit log between the primary database and the standby database included in the second object database set, to avoid data loss, so that the commit log may be directly read in the case of a failure, and the processing operation of the distributed transaction may be resumed by using the commit log.

Optionally, in this embodiment, the foregoing commit log is recorded in the form of a data table, and each commit log of a distributed transaction is recorded in a data row in the data table. Two fields, that is, an identifier of the distributed transaction and a commit indication result of the distributed transaction are recorded in the commit log. For example, the commit log may be as shown in Table <NUM>.

In this embodiment, the commit logs recorded in each row shown in Table <NUM> may be sequentially written to the corresponding second object database set in a distributed storage manner.

Description is made with reference to the following example. As shown in <FIG>, it is assumed that the target database cluster includes ten object database sets that are set1 to set10 respectively. In a possible implementation, assuming a distributed transaction <NUM> is used to perform a processing operation on account data in account <NUM> to account <NUM>, where account data in account <NUM> and account <NUM> is stored in set1, and account data in account <NUM> is stored in set2; further assuming a distributed transaction <NUM> is used to perform a processing operation on account data in account <NUM> and account <NUM>, where account data in account <NUM> is stored in set3 and account data in account <NUM> is stored in set4; further assuming a distributed transaction <NUM> is used to perform a processing operation on account data in account <NUM> to account <NUM>, where account data in account <NUM> is stored in set5, account data in account <NUM> is stored in set6, and account data in account <NUM> is stored in set7 and set8.

In a possible implementation, assuming that the second object database set is configured as the first of the plurality of first object database sets associated with each distributed transaction, then write results of the commit logs shown in Table <NUM> are as follows: the commit log of the distributed transaction <NUM> will be written to set1, the commit log of the distributed transaction <NUM> will be written to set3, and the commit log of the distributed transaction <NUM> will be written to set5.

In this embodiment provided in this application, the cached commit log is written to the corresponding second object database set in a distributed storage manner, and data synchronization is performed on the commit log between the primary database and the standby database in the second object database set, thereby ensuring the accuracy of distributed transaction processing as well as avoiding data loss.

In an optional solution, the writing the commit log to the second object database set in a distributed storage manner includes the following steps:.

Optionally, in this embodiment, the foregoing shared key field value may be, but is not limited to, a value in a shard key column specified in the commit log.

Description is made with reference to <FIG>. Assuming that a column recording the identifier of the distributed transaction in the commit log is the specified shard key column, the hash operation may be sequentially performed on the identifiers ID of the distributed transactions, to obtain a hash value. The second object database set to which the commit log is written is determined according to the hash value. For example, an identifier of the second object database set is determined according to an end value of the hash value, or an identifier of the second object database set is determined according to a result obtained after performing a remainder operation on a specified parameter from the hash value. Then, the foregoing commit log is written to a set indicated by the determined identifier of the second object database set. <FIG> shows that the set indicated by the determined identifier of the second object database set is set1. The commit log is written to set1.

The foregoing second object database set determined according to the hash value may be an object database set of the M first object database sets, or may be another object database set other than the M first object database sets.

Still using <FIG> as an example, the distributed transaction requested by the distributed transaction processing request is to perform a processing operation on account data of accounts located in two first object database sets (for example, set1 and set2). Assuming that the hash value obtained through the hash operation indicates that set3 is the second object database set, the commit log may be written to set3.

In this embodiment provided in this application, the commit log is written to the second object database set in a distributed storage manner by using the hash value, thereby achieving the purpose of evenly writing, to prevent the commit logs from being written to the same object database set.

Description is made with reference to an example shown in <FIG>. Assuming that one first object database set of the M first object database sets is specified as the second object database set, as shown in <FIG>, the commit log of the distributed transaction may be written to set1, and data synchronization may be performed between a primary database and a standby database in set1.

In this embodiment provided in this application, the commit log is written to a specified object database set of the plurality of first object database sets associated with the distributed transaction according to configuration, thereby ensuring that the commit logs are written evenly, to prevent the commit logs from being written to the same object database set.

In an optional solution, in this embodiment, a plurality of commit logs may be written in batches by using a single insert statement (for example, insert), thereby improving the efficiency of writing the commit logs. The method includes the following steps:.

Optionally, in this embodiment, the first threshold may be set to, but is not limited to, different values according to specific scenarios. If a quantity of the commit logs cached reaches the foregoing first threshold, the commit logs cached in the internal cache queue are sequentially written to the corresponding second object database set by using the single insert statement.

Assuming that the first threshold is five, during the process of caching the commit log, when five commit logs are cached in the internal cache queue, a background thread may assemble the five commit logs in the internal cache queue into a single insert statement, and then send the single insert statement to the second object database set. If the quantity of the cached commit logs does not reach five, a wait-for-commit state is entered until the quantity of the cached commit logs reaches five.

In this embodiment provided in this application, the writing process of the commit log is controlled by using the first threshold, and if the quantity of the commit logs cached in the internal cache queue reaches the first threshold, the commit logs are read from the internal cache queue, and written in batches to the second object database set, thereby simplifying the process of the writing operation of the commit log, and improving the efficiency of writing the commit logs.

In an optional solution, before the writing the commit log to the second object database set in a distributed storage manner, the method further includes the following steps:.

When the insertion time does not reach the timeout condition, a writing operation is performed. That is, in this embodiment, if a timestamp of the insertion time in the single insert statement (for example, an insert statement) is compared with a timeout time to determine that writing has timed out, an invalid value is written to the commit log to make the insert fail, thereby avoiding storing the commit log that has timed out to the second object database set at the back end.

Description is made with reference to the following example. As shown in <FIG>, five commit logs are cached in the internal cache queue, each commit log carries an insertion time. The five commit logs are Log1 to Log5 respectively. For example, assuming that the insertion time of Log1 is <NUM>:<NUM>:<NUM>, the insertion time of Log2 is <NUM>:<NUM>:<NUM>, the insertion time of Log3 is <NUM>:<NUM>:<NUM>, the insertion time of Log4 is <NUM>:<NUM>:<NUM>, and the insertion time of Log5 is <NUM>:<NUM>:<NUM>, Log1 has been inserted into the internal cache queue for <NUM> hours. In a possible implementation, it is assumed that the timeout condition is that a period of time for which the commit log is stored in the internal cache queue exceeds two hours. That is, in the foregoing example, Log1 has reached the timeout condition, and an invalid value is written to Log1. Assuming that <NUM> is an invalid value, the invalid value <NUM> may be written to Log1.

In a possible implementation, during the process of writing the foregoing five commit logs to the second object database set by using the single insert statement, if Log1 carrying the invalid value is detected in Log1 to Log5, the foregoing five commit logs will not be written to the second object database set.

In this embodiment provided in this application, through the insertion times of the cached commit logs, it is determined whether the commit log currently to be written reaches the timeout condition, and if the commit log reaches the timeout condition, the invalid value is written to the commit log, thereby ensuring the timeliness of the commit log, and preventing the commit log that has timed out from being written to the second object database set, so as to improve the accuracy of writing the commit log.

In an optional solution, during the process of writing the commit log to the second object database set in a distributed storage manner, the method further includes the following steps:.

Optionally, in this embodiment, the obtaining the first commit log to the ith commit log that are successfully written includes: obtaining, through a control agent device corresponding to a database included in the second object database set, the first commit log to the ith commit log that are successfully written, the control agent device being configured to resume the processing operation.

In this embodiment, each database in the object database set is configured with a corresponding control agent device, and the control agent device is configured to monitor data in the database and provide services for the database to which the control agent device belongs.

In this embodiment provided in this application, if a write failure is detected, the control agent device may read the commit log from the database that has been successfully written by using a monitoring result, so that the operation in the distributed transaction is resumed according to the commit log, to avoid a problem of inconsistent transaction processing statuses in the distributed devices caused by a failure.

In an optional solution, the performing, if the commit indication result instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts located in the M first object database sets includes:.

Optionally, in this embodiment, the foregoing distributed transaction processing method includes: a first commit mode (also referred to as an automatic commit mode), and a second commit mode (also referred to as an instruction commit mode). In the first commit mode, each time the operation is completed, a corresponding automatic commit instruction is automatically generated, the automatic commit instruction carrying an automatic commit moment. If the automatic commit moment is reached, a corresponding processing operation is automatically performed on the account data in the first object database set. In the second commit mode, only after a commit instruction (for example, commit) is received, a corresponding processing operation is performed on the account data in the first object database set.

Optionally, in this embodiment, an operation instruction for performing the processing operation on the account data may include, but is not limited to, at least one of the following: an insert/update/delete statement.

In this embodiment provided in this application, the processing operation is performed on the account data in the accounts according to the commit log in different commit modes, thereby improving the flexibility of performing the processing operation.

In an optional solution, the performing, if the commit indication result instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts located in the M first object database sets includes:
S1. Perform a first processing operation on account data in the i accounts, and a second processing operation on account data in the N-i accounts, to obtain an operation result.

The operation result indicates that a total operation value of the first processing operation is equal to a total operation value of the second processing operation, the first processing operation and the second processing operation are reverse operations, and i is an integer greater than or equal to <NUM> and less than or equal to N.

Notify application clients corresponding to the N accounts of the operation result.

For example, a financial system transfers funds between a plurality of accounts. The foregoing distributed transaction may, but is not limited to, instruct to perform a fund deduction operation on account data in some accounts and perform a fund increase operation on account data in other accounts associated with the distributed transaction. To ensure the balance of financial funds, the total operation value of the deduction operation is equal to the total operation value of the increase operation.

Optionally, in this embodiment, the performing a first processing operation on account data in the i accounts, and a second processing operation on account data in the N-i accounts includes the following steps:.

The value increasing operation is the first processing operation, and the value decreasing operation is the second processing operation.

Description is made with reference to the following example. Assuming that N=<NUM> and i=<NUM>, N-i=<NUM>. Further assuming that the distributed transaction processing request is used for requesting to perform the following operations: a total asset value of account <NUM> needs to be reduced by <NUM> yuan, and a total asset value of each of account <NUM> and account <NUM> needs to be increased by <NUM> yuan. After a commit log corresponding to the foregoing distributed transaction processing request is obtained, the following operations are performed on account data in account <NUM> to account <NUM>: the total asset value of account <NUM> is reduced by <NUM> yuan, and a total asset value of each of account <NUM> and account <NUM> is increased by <NUM> yuan. Then, changes in total asset values of account <NUM> to account <NUM> are notified to respective application clients.

In this embodiment provided in this application, the same processing operation as the operation recorded in the commit log is performed on the account data in the accounts, thereby improving the accuracy of committing the processing operation.

For the foregoing method embodiments, for a purpose of simple description, each method embodiment is described as a combination of a series of actions; however, a person skilled in the art is to know that, the present disclosure is not limited by the described action sequence, because according to the present disclosure, some steps can be performed in another sequence or simultaneously. In addition, a person skilled in the art is to know that, all the embodiments described in the specification are exemplary embodiments, and the involved actions and modules are not necessarily required by the present disclosure.

According to the foregoing descriptions of implementations, a person skilled in the art may clearly know that the method according to the foregoing embodiments may be implemented by using software and a necessary general hardware platform, or may be implemented by using hardware. However, in most cases, the former is a better implementation. Based on such understanding, the technical solutions of the present disclosure or the part that makes contributions to the related art may be substantially embodied in the form of a software product. The computer software product is stored in a storage medium (for example, a read-only memory (ROM)/random access memory (RAM), a magnetic disk, or an optical disc), and contains several instructions for instructing a terminal device (which may be a mobile phone, a computer, a server, or a network device) to perform the method according to the embodiments of the present disclosure.

According to another aspect of the embodiments of the present disclosure, a distributed transaction processing apparatus configured to perform the foregoing distributed transaction processing method is further provided, the apparatus being configured to perform any one of the distributed transaction processing methods provided in the foregoing embodiments. As shown in <FIG>, the apparatus includes:.

In an optional implementation, as shown in <FIG>, the foregoing writing unit includes:.

In an optional implementation, the first writing module includes:.

In an optional implementation, the foregoing writing unit further includes:.

Optionally, in this embodiment, the obtaining the first commit log to the ith commit log that are successfully written includes: obtaining, through an control agent device corresponding to a database included in the second object database set, the first commit log to the ith commit log that are successfully written, the control agent device being configured to resume the processing operation.

In an optional implementation, the processing unit includes:.

In an optional implementation, the foregoing processing unit includes:.

According to still another aspect of the embodiments of the present disclosure, an electronic apparatus configured to implement the foregoing distributed transaction processing method is further provided. As shown in <FIG>, the electronic apparatus includes a memory and a processor, the memory storing a computer program, and the processor being configured to perform steps in any one of the foregoing method embodiments through the computer program.

Optionally, in this embodiment, the electronic apparatus may be located in at least one of a plurality of network devices in a computer network.

Optionally, in this embodiment, the foregoing processor may be configured to perform the following steps through a computer program:.

A person of ordinary skill in the art may understand that, the structure shown in <FIG> is only illustrative. The electronic apparatus may be a terminal device such as a smartphone (for example, an Android mobile phone or an iOS mobile phone), a tablet computer, a laptop computer, a mobile Internet device (MID), or a portable Android device (PAD). <FIG> does not constitute a limitation on a structure of the foregoing electronic apparatus. For example, the electronic apparatus may further include more or fewer components (for example, a network interface) than those shown in <FIG>, or have a configuration different from that shown in <FIG>.

The memory <NUM> may be configured to store a software program and module, such as a program instruction/module corresponding to the distributed transaction processing method and apparatus in the embodiments of the present disclosure. The processor <NUM> runs the software program and module stored in the memory <NUM>, to perform various functional applications and data processing, thereby implementing the foregoing distributed transaction processing method. The memory <NUM> may include a high-speed random memory, and a non-volatile memory such as one or more magnetic storage devices, a flash, or another non-volatile solid-state memory. In some examples, the memory <NUM> may include memories remotely disposed relative to the processor <NUM> in a possible implementation, and the remote memories may be connected to a terminal through a network. An example of the network includes, but is not limited to, the Internet, an intranet, a local area network, a mobile communications network and a combination thereof. Specifically, the memory <NUM> may be configured to, but is not limited to, store content such as a commit log. In an example, as shown in <FIG>, the memory <NUM> may include, but is not limited to, the obtaining unit <NUM>, the writing unit <NUM>, and the processing unit <NUM> in the foregoing distributed transaction processing apparatus. In addition, the memory may further include, but is not limited to, other module units in the foregoing distributed transaction processing apparatus, and details are not described in this example.

The transmission apparatus <NUM> is configured to receive or send data by using a network. A specific example of the network may include a wired network and a wireless network. In an example, the transmission apparatus <NUM> includes a network interface controller (NIC). The NIC may be connected to another network device and a router by using a network cable, so as to communicate with the Internet or the local area network. In an embodiment, the transmission apparatus <NUM> is a radio frequency (RF) module that is configured to communicate with the Internet in a wireless manner.

In addition, the foregoing electronic apparatus further includes: a display <NUM>, configured to display content such as a commit log; and a connection bus <NUM>, configured to connect various module components in the foregoing electronic apparatus.

According to still another aspect of the embodiments of the present disclosure, a storage medium is further provided. The storage medium stores a computer program, the computer program being configured to perform steps in any one of the foregoing method embodiments when being run.

Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:.

Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:
S1. Obtain, through an control agent device corresponding to a database included in the second object database set, the first commit log to the ith commit log that are successfully written to the second object database set, the control agent device being configured to resume the processing operation.

Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps of the methods in the foregoing embodiments may be implemented by a program by instructing hardware relevant to a terminal device. The program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disc, and the like.

The sequence numbers of the embodiments of the present disclosure are merely for the convenience of description, and do not imply the preference among the embodiments.

When the integrated unit in the foregoing embodiment is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in the foregoing computer-readable storage medium. Based on such an understanding, the technical solutions of the present disclosure essentially, or the part contributing to the prior art, or all or some of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing one or more computer devices (which may be a personal computer, a server, a network device, or the like) to perform all or some of the steps of the methods described in embodiments of the present disclosure.

In the foregoing embodiments of the present disclosure, the descriptions of the embodiments have respective focuses. For the part that is not detailed in an embodiment, refer to the relevant description of other embodiments.

In the several embodiments provided in this application, it is understood that the disclosed client may be implemented in other manners. For example, the unit division is merely logical function division and may be another division in an actual implementation. In addition, the coupling, or direct coupling, or communication connection between the displayed or discussed components may be the indirect coupling or communication connection by means of some interfaces, units, or modules, and may be in electrical or other forms.

Some or all of the units may be selected according to actual requirements to achieve the objectives of the solutions in the embodiments.

Claim 1:
A distributed transaction processing method, comprising:
obtaining (S202), by a distributed transaction processing device (<NUM>), a distributed transaction processing request, the distributed transaction processing request being used for requesting to perform a processing operation on account data in N accounts, the account data in the N accounts being located in M first object database sets (<NUM>), the M first object database sets being comprised in a target database cluster (<NUM>), N being an integer greater than <NUM>, and M being an integer greater than <NUM>;
writing (S204), by the distributed transaction processing device (<NUM>), a commit log corresponding to the distributed transaction processing request to a second object database set (<NUM>), the commit log comprising a commit indication result being recorded and used for indicating whether the processing operation on the account data in the N accounts is committed; the second object database set (<NUM>) being comprised in the target database cluster (<NUM>);
obtaining (S206), by the distributed transaction processing device (<NUM>) after the distributed transaction processing device resumes distributed transaction processing after an interruption in the distributed transaction processing, the commit log from the second object database set (<NUM>); and
performing (S208), by the distributed transaction processing device (<NUM>) when the commit indication result in the commit log instructs to commit the processing operation on the account data in the N accounts, the processing operation on the account data in the N accounts;
wherein the distributed transaction processing device (<NUM>) is a user equipment remotely connected to the target database cluster (<NUM>) through a network (<NUM>).