[go: up one dir, main page]

CN119904228A - Transaction processing method, device, computer equipment and storage medium - Google Patents

Transaction processing method, device, computer equipment and storage medium Download PDF

Info

Publication number
CN119904228A
CN119904228A CN202311403425.2A CN202311403425A CN119904228A CN 119904228 A CN119904228 A CN 119904228A CN 202311403425 A CN202311403425 A CN 202311403425A CN 119904228 A CN119904228 A CN 119904228A
Authority
CN
China
Prior art keywords
transaction
asset
account
unit
data center
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.)
Pending
Application number
CN202311403425.2A
Other languages
Chinese (zh)
Inventor
金韬
刘长辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202311403425.2A priority Critical patent/CN119904228A/en
Publication of CN119904228A publication Critical patent/CN119904228A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123Shopping for digital content
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The present application relates to a transaction processing method, apparatus, computer device, storage medium and computer program product. The method can be applied to intelligent traffic, game scenes and the like. The method comprises the steps of responding to a transaction request, determining a transaction account participating in the transaction, wherein the transaction account comprises at least one asset unit, the asset unit carries version identification updated according to transaction behaviors, the total asset quantity of the transaction account is represented by the asset sum of the asset units, determining a main data center for executing the transaction from data centers of the asset units stored with the transaction account, executing the asset transaction according to the asset units in the main data center to obtain the transaction asset units updated according to the version identification, and synchronizing the transaction asset units to the data centers. By adopting the method, the transaction throughput of each transaction account can be improved, the high availability of the transaction process is ensured, and the transaction processing efficiency can be effectively improved.

Description

Transaction processing method, device, computer equipment and storage medium
Technical Field
The present application relates to the field of computer technology, and in particular, to a transaction processing method, apparatus, computer device, storage medium, and computer program product.
Background
With the development of computer technology, hot standby technology appears, and in particular, different types of business applications can be connected into different data centers by setting different data centers to prevent data conflict, and the data centers in different places are generally synchronized in two directions by crossing cities or crossing special lines, so that the purpose of hot standby is achieved.
Considering that the transaction system has high requirements on data strong consistency and integrity, a plurality of data centers must run the same application and have the same data, and when the data centers are switched to have faults, the transaction data needs to be checked and repaired, and the process can reduce the throughput and usability of the system, so that the problem of low transaction processing efficiency exists.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a transaction processing method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve transaction processing efficiency.
In a first aspect, the present application provides a transaction processing method. The method comprises the following steps:
In response to a transaction request, determining a transaction account for participation in a transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, a sum of assets for each of the asset units being used to characterize a total asset yield of the transaction account;
determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account;
Executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identification;
Synchronizing the transaction asset units to each of the data centers.
In a second aspect, the application also provides a transaction processing device. The device comprises:
A transaction account determination module for determining a transaction account involved in a transaction in response to a transaction request, the transaction account comprising at least one asset unit carrying a version identification updated by transaction activity, the sum of the assets of each of the asset units being used to characterize the total asset yield of the transaction account;
a master data center determination module for determining a master data center for executing a transaction from among the data centers of the asset units storing the transaction account;
the transaction execution module is used for executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identifiers;
And the data synchronization module is used for synchronizing the transaction asset units to each data center.
In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor which when executing the computer program performs the steps of:
In response to a transaction request, determining a transaction account for participation in a transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, a sum of assets for each of the asset units being used to characterize a total asset yield of the transaction account;
determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account;
Executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identification;
Synchronizing the transaction asset units to each of the data centers.
In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of:
In response to a transaction request, determining a transaction account for participation in a transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, a sum of assets for each of the asset units being used to characterize a total asset yield of the transaction account;
determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account;
Executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identification;
Synchronizing the transaction asset units to each of the data centers.
In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the steps of:
In response to a transaction request, determining a transaction account for participation in a transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, a sum of assets for each of the asset units being used to characterize a total asset yield of the transaction account;
determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account;
Executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identification;
Synchronizing the transaction asset units to each of the data centers.
According to the transaction processing method, the device, the computer equipment, the storage medium and the computer program product, the transaction account is divided into the asset units, so that the asset transaction processing can be directly performed from the granularity of the asset units, the concurrent processing capacity of the asset transaction processing can be effectively improved, meanwhile, the version identification carried by the asset units is updated according to the transaction behavior, and the backtracking of the transaction can be realized between the synchronous transaction asset units of different data centers based on the version identification, so that the balance data of the account transaction can be directly recovered from the granularity of the asset units, the execution of other normal asset transactions can not be blocked, the transaction throughput of each transaction account can be improved, the high availability of the transaction process is ensured, and the transaction processing efficiency can be effectively improved.
Drawings
FIG. 1 is an application environment diagram of a transaction processing method in one embodiment;
FIG. 2 is a flow chart of a transaction processing method according to one embodiment;
FIG. 3 is a schematic diagram of an asset unit in a transaction processing method according to one embodiment;
FIG. 4 is a schematic diagram of a transaction processing method chain update in one embodiment;
FIG. 5 is a schematic diagram of a transaction processing system in one embodiment;
FIG. 6 is a schematic diagram of a transaction backtracking flow of a transaction processing method according to one embodiment;
FIG. 7 is a schematic diagram of a version rollback flow of a transaction processing method in one embodiment;
FIG. 8 is a flow diagram of a process for fragmenting an asset unit in one embodiment;
FIG. 9 is a schematic diagram of a data recovery process of a transaction processing method according to another embodiment;
FIG. 10 is a block diagram of a transaction processing device in one embodiment;
FIG. 11 is an internal block diagram of a computer device in one embodiment;
fig. 12 is an internal structural view of a computer device in another embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
The transaction processing method provided by the embodiment of the application can be applied to an application environment shown in figure 1. The application environment may include a transaction system including a terminal 102, a server 104, a server 106, etc., with the terminal 102 in communication with the server 104, the server 106 via a network. The data storage system may store data that the server 104, 106 needs to process. The data storage system may be integrated on the server 104, the server 106, or may be located on the cloud or other servers. Both server 104 and server 106 may act as data centers for performing transaction processing. In practical application, the transaction system distributes a data center (Base) for each transaction account, the read-write request is based on the Base data, if the Base fails, the transaction system can switch the Base of the transaction account and continue to provide transaction service, and high availability of the transaction account is ensured.
Specifically, taking a data center allocated by the transaction account a as an example of a Base1 where the server 104 is located, the server 104 responds to a transaction request initiated by a user through the terminal 102 to determine a transaction account X participating in a transaction, where the transaction account X includes at least one asset unit, the asset unit carries a version identifier updated according to transaction behavior, a total asset amount of each asset unit is used to represent a total asset amount of the transaction account, a master data center where the transaction is performed is determined from each data center of the asset units where the transaction account is stored, that is, the Base1 where the server 104 is located, in the master data center, the asset transaction is performed according to the asset units to obtain a transaction asset unit updated according to the version identifier, and the transaction asset units are synchronized to each data center, such as Base2 where the server 106 is located.
Further, each data center comprises a plurality of copies, strong consistency data synchronization of single writing and multiple reading is realized through the plurality of copies, and when the copies are failed, the transaction system can automatically complement the copies to the appointed redundancy amount, so that disaster recovery of the data in the single data center is ensured.
In a specific application, taking a transaction account as an example of a game account, the transaction request may be a transaction request of a game asset, and the game asset transaction between different game accounts is realized by executing the transaction. In the example of a transaction account as a virtual asset account, for example, the transaction request may be a transaction request for a virtual asset, and the virtual asset transaction between different virtual asset accounts is implemented by performing the transaction.
The terminal 102 may be, but not limited to, various desktop computers, notebook computers, smart phones, tablet computers, internet of things devices, and portable wearable devices, where the internet of things devices may be smart speakers, smart televisions, smart air conditioners, smart vehicle devices, and the like. The portable wearable device may be a smart watch, smart bracelet, headset, or the like. The server 104 and the server 106 may be independent physical servers, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be cloud servers that provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligence platforms, and the like. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the present application is not limited herein. In some of these embodiments, the assets for the transaction may be stored in a blockchain wallet, with the security of the assets ensured by blockchain technology.
In one embodiment, as shown in fig. 2, a transaction processing method is provided, which is exemplified by the application of the method to the transaction system in fig. 1, and includes the following steps:
in response to the transaction request, a transaction account is determined to be involved in the transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, the sum of the assets of each asset unit being used to characterize the total asset yield of the transaction account.
Where the transaction request refers to a data processing request for requesting an asset transfer, the type of asset transfer includes an asset in-coming and an asset out-coming. E.g., transferring assets from transaction account a to transaction account B, and then, e.g., by way of a system recharge, causing the system to assign corresponding assets to transaction account a, etc. The transferred assets can comprise various assets matched with the actual application scene, such as game assets in a game scene, article assets in an article transaction scene and the like, when the transaction is executed, the asset transaction can be directly carried out when the asset types of the two transaction sides are the same, and when the asset types of the two transaction sides are different, the asset transaction can be carried out through asset conversion based on the same asset evaluation dimension.
The transaction account involved in the transaction may be determined according to the type of the transaction request, and the transaction account involved in the transaction may be a transfer account only when the type of the transaction request is a top-up, and may include both a transfer account and a transfer account when the type of the transaction request is a transfer.
For each transaction account, the transaction account may be divided into asset units by total assets such that each asset account has at least one asset unit. The number of the asset units of the transaction account can be fixed or variable, and can be specifically set according to actual scene requirements, for example, the number of the asset units of the transaction account is set to be N (N is a positive integer), when the number of the asset units of the transaction account is less than N, part of the asset units can be divided into two or M (M is less than or equal to N and M is a positive integer) through the asset unit slicing, so that the number of the asset units of the transaction account is maintained to be N. For another example, without limiting the number of asset units of the transaction account, when the number of transaction requests for the transaction account is large, the asset unit may be automatically fragmented and divided into more asset units, and when the asset amount of the asset unit in the transaction account is less than a set minimum threshold, the asset unit may be combined with other asset units in a state where the asset unit is allowed to be combined, thereby ensuring that the asset yield of each asset unit is not less than the set minimum threshold. By further splitting each account, by dividing a plurality of asset units, each transaction account automatically repairs conflicted or missing data when switching the main data center, the efficiency is improved, the final consistency of the asset data is ensured, in addition, each main data center can serve a plurality of transaction accounts, each transaction account carries a plurality of asset units, each asset unit can conduct transactions, and the high throughput, the high availability and the easy expansibility of the system are improved.
The version identifier is an identifier for recording the transaction behavior of the asset unit, and may be updated according to the transaction behavior in which the asset unit participates. For each asset unit, there is an independent version identifier matched with the asset unit, different asset units in the same transaction account are respectively provided with version identifiers for recording transaction behaviors of the asset units, so as to trace the transaction process of the different asset units in the transaction account, for example, the asset unit A and the asset unit B are divided according to total assets in a small transaction account, each of the asset unit A and the asset unit B is provided with one version identifier, when the transaction is carried out through the asset unit A, for example, 20 assets are transferred out from the asset unit A, the asset amount of the asset unit A is reduced by 20, the version identifier of the asset unit A is updated with the generation of the transaction, for example, the version identifier of the asset unit A before the transaction is 4, and the version identifier of the asset unit A after the transaction is updated to 5. However, since the asset unit B does not participate in the transaction, the generation of the transaction does not affect the asset identification of the asset unit B, which would remain unchanged without participating in the transaction.
In some embodiments, the version identification may be a version number or other identification data. The updated version identifier is associated with the version identifier before updating, and specifically, backtracking of transaction behaviors participated by the asset unit can be realized according to the association relation. For example, the version identifier of the asset unit K may be 1 before the asset unit K participates in the transaction, and the version identifier of the asset unit K may be increased by 1 on the basis of the original version identifier to update the version identifier to 2 after the asset unit K participates in the transaction. For another example, the version identification of the asset unit K may be 1 before the asset unit K participates in the transaction, while the version identification of another asset unit H participating in the transaction is 3, and the version identifications of the asset unit K and the asset unit H may be updated to 4 after the asset unit K and the asset unit H participate in the transaction.
It should be noted that, the updated version identifier and the version identifier before updating may be associated by a preset association rule, and based on the set association rule, a specific representation of the version identifier after updating may be determined. In one embodiment, taking the version identifier as the version number, the preset association rule as the initial version number is 0, and the version number +1 after each update is taken as an example, for a certain transaction behavior of the asset unit a, before the current transaction is executed, the version number before the update is 3, which indicates that the asset unit a has participated in three transaction behaviors, and after the current transaction is executed, the updated version number is 3+1=4. The transaction occurrence number of each asset unit can be analyzed and obtained through the concrete representation of the version identification and the preset association rule.
In one specific embodiment, when two asset units participate in the same transaction, the version identifiers of the two asset units are updated, and the specific updating mode is that the updated version identifiers take the version identifier of one asset unit with more transaction occurrence times as an updating reference, so that the version identifiers of the two asset units participating in the transaction are consistent after the transaction is completed, the tracing of the transaction process to both transaction parties is facilitated, and the reliability of transaction tracing is ensured.
The transaction behavior refers to the execution process of each transaction, different transaction behaviors can be distinguished through different transaction identifiers, the transaction identifiers are respectively associated with the pre-transaction asset data and the post-transaction asset data, and detailed data of the transaction behavior represented by the transaction identifiers can be searched through the transaction identifiers, wherein the detailed data comprise specific data of the pre-transaction asset unit and specific data of the post-transaction asset unit.
Each asset unit may represent a number of assets, and the sum of the assets of each asset unit of the same transaction account is equal to the total asset yield of that transaction account. The asset yields of the asset units of the same transaction account may or may not be equal. For example, transaction account A has a total asset amount equal to 100, transaction account A is divided into 4 asset units, and the asset yield for each asset unit is 25. For another example, transaction account A has a total asset size equal to 100, transaction account A has 4 asset units, one of which has a asset size of 70 and the other three of which have asset sizes of 10.
Step 204, determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account.
The data centers are objects for realizing the distributed storage of the asset data of the transaction accounts, and the asset data of the same transaction account can be stored in each data center so as to realize the data backup of different data centers. Specifically, the service system can be segmented according to service types or geographic positions, corresponding data centers are respectively arranged in different regions, different types of service applications are connected to different data centers to prevent data collision, the data centers in different regions are generally synchronized in two directions through private lines crossing cities or countries, the purpose of hot standby is achieved, when a certain data center fails, the service connected to the data center can be switched to another data center in real time and continue to provide service, the transaction system can be classified according to transaction accounts, and in consideration of the fact that the transaction system has high requirements on data strong consistency and integrity, the data centers must be operated with the same application and have the same data.
The primary data center performing the transaction refers to the data center for processing the transaction request, which is one of the data centers of the asset units where the transaction account is stored. The determination of the master data center may be one selected at random from the data centers of the asset units storing the transaction account, or one selected from the data centers of the asset units storing the transaction account by a set selection rule. For example, the data center storing the asset unit of the transaction account a includes the data center 1 and the data center 2, and in the case where the selection manner of the master data center is a random selection, one data center may be randomly selected from the data center 1 and the data center 2 as the master data center for processing the transaction request of the transaction account a. In the case where the primary data center is selected according to the selected rule, one of the data center 1 and the data center 2 satisfying the selected rule may be determined as the primary data center that processes the transaction request.
The main data center for executing the transaction can be specifically determined according to the selection rule configured according to the actual scene. In some embodiments, the primary data center may be the data center where the transaction account that is assigned to participate in the transaction by default, e.g., data center assigned to transaction account a and transaction account B is data center 1, data center assigned to transaction account C is data center 2, and in the case where the transaction account that participates in the transaction includes at least one of transaction account a and transaction account B, the primary data center that performs the transaction is data center 1. In the case where the transaction account involved in the transaction includes transaction account C, then the primary data center performing the transaction is data center 2. In the case where the transaction account participating in the transaction includes both the transaction account a and the transaction account C, then the main data center performing the transaction is any one of the data center 1 and the data center 2.
In another embodiment, the master data center may also be a data center assigned to the transaction account that received the transaction request, e.g., data center assigned to transaction account a and transaction account B is data center 1, and data center assigned to transaction account C is data center 2. In the case where the transaction request is a request initiated by transaction account a to transaction account C, the master data center is data center 2 assigned to transaction account C, and in the case where the transaction request is a request initiated by transaction account C to transaction account B, the master data center is data center 1 assigned to transaction account B.
At step 206, in the primary data center, asset transactions are performed on an asset unit basis, resulting in a transaction asset unit with version identification updated.
Wherein, the asset transaction refers to a data processing process for asset transfer. The asset transaction takes an asset unit as a resource transfer object, the asset transaction is to transfer the transacted asset out of the asset unit to generate a new asset unit belonging to a transfer account in the transfer transaction process, and the asset transaction is to directly generate the new asset unit belonging to the transfer account in the recharging transaction process.
The transaction asset unit refers to an asset unit obtained after performing asset transaction, and the updating mode of the version identification is related to the number of transaction input asset units in the transaction process. In the case where there are 1 transaction input asset units in the transaction process, the version identification of the transaction asset unit may be updated directly based on the transaction input asset unit version identification. For example, the asset units involved in the transaction in transaction account A are AU a with sufficient balance, and the transaction, when executed, will result in two AU-AU a 'and AU b,AUa' and AU b belonging to account A and account B, respectively. Compared with the balance of AU a, AU a 'subtracts the transaction asset Amount, AU b belongs to account B for the newly generated AU, the balance of AU b is equal to the transaction asset Amount, and the Version number Version of AU a' and AU b is updated to be one plus the Version value in the transaction input asset unit. For example, the Version number Version of the transaction input asset unit AU a is 5, and the Version numbers Version of the AU a' and AU b are updated to 6.
When the number of the transaction input asset units is 2 or more, the version identification of each transaction input asset unit can firstly determine the transaction times represented by the version identification of each transaction input asset unit, and then update the version identification by taking the one with more transaction times as a reference. In one embodiment, taking the example of transferring the resources from the transaction account A and the transaction account B to the transaction account C, the asset units participating in the transaction account A are AU a, the asset units participating in the transaction account B are AU b, three AUs, AU a'、AUb 'and AU c,AUa'、AUb' and AU c, respectively belong to the account A, Account B and account C. AU a 'compared to AU a balance deduction of transaction asset Amount1, AU b' compared to AU b balance deduction of transaction asset Amount2, AU c is that the newly generated AU belongs to account C, the balance of AU c is equal to the sum of transaction assets Amount1+Amount2, and Version number Version of AU a'、AUb 'and AU c are updated to the maximum value of Version in transaction input asset units AU a and AU b plus one, for example, version number Version of AU a- is 5, version number Version of AU b is 3, and Version number Version of AU a'、AUb' and AU c are updated to 6 based on 5.
Step 208, the transaction asset units are synchronized to the data centers.
After the asset transaction is performed, the transaction asset units need to be synchronized so that the data centers of the asset units storing the transaction account are synchronized. In particular, the data synchronization of the master data center with the other data centers may be asynchronously implemented, where the master data center asynchronously synchronizes the transaction asset data to the remaining data centers, which, upon receipt, update the respective asset sets of the internal transaction accounts.
According to the transaction processing method, the transaction account is divided into the asset units, so that the asset transaction processing can be directly performed from the granularity of the asset units, the concurrent processing capacity of the asset transaction processing can be effectively improved, meanwhile, the version identifiers carried by the asset units are updated according to the transaction behaviors, backtracking of transactions can be realized between synchronous transaction asset units of different data centers based on the version identifiers, so that the balance data of account transactions can be directly recovered from the granularity of the asset units, the execution of other normal asset transactions can not be blocked, the transaction throughput of each transaction account can be improved, the high availability of the transaction process is ensured, and further the transaction processing efficiency can be effectively improved.
In some embodiments, where the transaction request is a transfer transaction request, the transaction account includes a transfer-in account and a transfer-out account, the transaction processing method further includes:
and determining a target asset unit participating in the transaction from the asset units of the transaction account based on the transaction asset yield requested by the transaction request, wherein the asset amount of the target asset unit is greater than or equal to the transaction asset yield.
Further, performing an asset transaction per asset unit, generating an updated asset unit with version identification updates, comprising:
and performing asset transaction on the target asset unit according to the transaction asset yield to generate an updated asset unit belonging to the transfer-out account and a newly-added asset unit belonging to the transfer-in account, wherein the version identification of the updated asset unit and the version identification of the newly-added asset unit are both associated with the version identification of the target asset unit.
Where a transfer transaction request refers to a resource transfer request to transfer an asset of one or more transaction accounts to another transaction account or to transfer an asset of one transaction account to one or more transaction accounts. The transfer-out account refers to a transaction account of the transfer-out asset, and correspondingly, the transfer-in account refers to a transaction account of the transfer-in asset. In the case where the transaction request is a transfer transaction request, the transaction accounts include both a transfer account and a transfer account, and it is understood that the number of one of the transfer account and the transfer account may be plural, for example, one transaction account transfers to plural transaction accounts, and for example, plural transaction accounts transfers to one transaction account. In other embodiments, the number of out-accounts and in-accounts may be defined to be 1. For example, when the number of transferred accounts is plural, asset transfer is performed by different asset units, respectively, to improve data processing efficiency.
The amount of transaction resources requested by the transaction request refers to the amount of resources that need to be transferred. The target asset unit is an asset unit with the asset yield greater than or equal to the transaction asset yield in the transaction account, and by determining the target asset unit, the asset transaction can be ensured to be executed directly through the divided asset units, the influence on the transaction processing efficiency caused by the failure condition of the asset transaction is avoided, and the success rate of the transaction execution can be improved.
The version identifier is used for recording the transaction behavior of the asset unit, and the version identifier can be updated according to the transaction behavior of the asset unit. The version identification may specifically be a version number or other identification data. The updated version identifier is associated with the version identifier before updating, so that backtracking of transaction actions participated by the asset unit can be realized according to the association relation.
For the change of the asset unit of the transfer transaction request, the original target asset unit AU a is needed for the transfer account A, the original asset unit can be available or not for the transfer account B, the account A selects an AU a with enough balance, the transfer Amount Amount and the account B as inputs of the transaction, and the transaction is initiated. The Version identifier Version1 of AU a is the maximum value of Version in the transaction input AU set.
After the transaction is performed, two new asset units AU are generated, namely an updated asset unit AU a' belonging to the transfer-out account A and a newly added asset unit AU b belonging to the transfer-in account B. Compared with AU a, the asset represented by AU a ' is deducted by the transfer Amount Amount, the transaction identifier FID of the transaction is used as the asset source ID of AU a ', the balance of AU b is equal to the transfer Amount Amount, the transaction identifier FID of the transaction is used as the asset source ID of AU b, and the Version numbers of AU a ' and AU b are updated to Version2.
In this embodiment, by determining, from the transaction account, an asset unit with an asset yield greater than or equal to the transaction asset yield as a target asset unit for participating in the transaction, it is possible to ensure that the asset transaction can be directly executed through the divided asset units, to avoid the occurrence of failure of the asset transaction from affecting the transaction processing efficiency, to improve the success rate of transaction execution, and to generate an update asset unit belonging to the transfer account and a new add asset unit belonging to the transfer account, and to associate both the version identifier of the update asset unit and the version identifier of the new add asset unit with the version identifier of the target asset unit, so that the associated version identifier can facilitate backtracking of the transaction behavior in which the asset unit participates, and to facilitate the realization of asset synchronization of the asset units for asynchronous participation transactions in different data centers by backtracking.
In some embodiments, the method further comprises constructing transaction metadata comprising a transaction identifier characterizing transaction behavior, a transaction input set, and a transaction output set;
Further, synchronizing the transaction asset units to the data centers includes synchronizing transaction metadata to the data centers.
Wherein the transaction input set is a set of asset units for characterizing the roll-out asset and the transaction output set is a set of asset units for characterizing a newly generated asset unit after the transaction is performed. For transfer transaction actions, the transaction input set comprises target asset units participating in transactions in the transfer-out account, and the transaction output set comprises updated asset units belonging to the transfer-out account and newly-added asset units belonging to the transfer-in account.
In one embodiment, as shown in FIG. 3, the transaction metadata includes a transaction ID, an input set { AU a }, an output set { AU a',AUb }, wherein each asset unit has a corresponding core field, the core fields of the asset unit include an asset identification UID, a belonging account identification ID, a Balance, a Version identification Version, and an asset source ID (FID), wherein the asset identification UID is a unique identification of the asset unit, the Balance and the Version identification Version in the AU core field are updated and the asset source ID is bound as the transaction ID after each related transaction is performed.
In this embodiment, by constructing transaction metadata including a transaction identifier, a transaction input set and a transaction output set, which characterize transaction behaviors, detailed data of asset units before and after a transaction can be synchronized between different data centers, so that the different data centers can be convenient to trace back transaction behaviors based on the transaction metadata, and data recovery can be quickly and conveniently realized under the condition that the data centers are switched.
In some embodiments, where the transaction request is a top-up transaction request, the transaction account includes a transfer account, and performing the asset transaction by asset unit to generate an updated asset unit with the version identification updated includes performing the asset transaction by transaction asset yield to generate a new added asset unit belonging to the transfer account.
Wherein the recharging transaction request refers to a transaction request of the transaction system as an asset providing object. The transaction account of the recharging transaction action is only a transfer account, and for the transfer account, the recharging transaction action can be to newly add one or more asset units in the transfer account, wherein the total balance of the newly added asset units is the recharged asset yield.
In some embodiments, a maximum allowable asset amount may be set for the asset units, and when the amount of the added asset is greater than the maximum allowable asset amount, a plurality of newly added asset units belonging to the transfer account may be generated, and when the amount of the added asset is less than or equal to the maximum allowable asset amount, 1 newly added asset unit belonging to the transfer account may be generated.
In other embodiments, the number of newly added asset units may also be set for the recharge transaction, for example, setting the number of newly added asset units to 2, and then the recharge transaction may be performed by dividing the recharged asset amount into two portions to generate two newly added asset units belonging to the transfer account.
In this embodiment, for the recharging transaction, the asset transaction is directly performed according to the transaction asset amount to generate the new asset unit belonging to the transfer account, so that the data processing process of the recharging transaction can be simplified, no interference to other transaction acts can be generated, and the overall data processing efficiency can be effectively improved.
In some embodiments, each data center includes multiple copies, and performing asset transactions on an asset unit basis at a master data center to obtain a transaction asset unit with version identification updates, including:
determining a master copy for participating in transaction and a slave copy for synchronizing data from each copy of the master data center, performing asset transaction based on the target asset units stored in the master copy, and obtaining transaction asset units updated in version identification;
Further, after performing the asset transaction per asset unit at the master data center to obtain the transaction asset unit with the version identification updated, synchronizing the transaction asset unit to each slave copy is included.
The copy is a basis for realizing local disaster recovery in the data center. In some embodiments, each transaction account has at least 3 copies in the Base, and multiple copies realize strong consistency data synchronization of single writing and multiple reading, and when the copies fail, the system can automatically complement the copies to the appointed redundancy amount, so that disaster recovery of data in a single data center is ensured.
In the process of transaction processing, the transaction system firstly determines a master data center for executing transactions, then determines a master copy for participating in the transactions and slave copies for synchronizing data from all copies of the master data center, writes transaction asset units generated based on the master copy for carrying out transactions in the process of transaction processing, and synchronizes the transaction asset units written in the master copy to all slave copies, thereby realizing data synchronization among multiple copies of the master data center.
In one embodiment, transfer account A selects an AU a of sufficient balance, transfer Amount Amount, transfer account B as input to the transaction, and initiates the transaction, identified as FID. After the transaction is performed, an updated asset unit AU a' belonging to the transfer-out account A and a newly added asset unit AU b belonging to the transfer-in account B are generated. The transaction system stores transaction metadata (transaction identification FID, input set { AU a }, output set { AU a',AUb }) in 3 copies of account a and account B respectively, and after the 3 copies complete strong consistency synchronization, the transaction execution ends and returns to the client. The master data center Base asynchronously synchronizes the transaction metadata to the remaining data centers, which, upon receipt, update the asset collection of the internal account A, B.
In this embodiment, the transaction system divides the data replication process into two layers, and each transaction account uses a strong synchronization mode between multiple copies in the same data center to prevent single-point faults of the copies, so as to ensure availability and consistency of accounts in a single data center.
In some embodiments, determining a master data center for executing a transaction from among the data centers of the asset units storing the transaction account includes, in the event that the transaction request is a transfer transaction request, taking as candidate data centers the data centers for which the transfer account and the transfer account each match, and selecting the master data center for executing the transaction from among the candidate data centers.
Wherein the primary data center performing the transaction may be determined based on the transaction account participating in the transaction to reduce the number and frequency of switching of the data center during the performance of the transaction. Specifically, for each transaction account, a data center matched with the transaction account can be pre-configured, the data center 1 is used as a main data center of the transaction account A and the transaction account B, and the data center 2 is used as a main data center of the transaction account C.
In one embodiment, the main data center of the transaction account A, B is Base1, the main data center of the account C is Base2, the account has 3 copies in each Base and executes a strong agreement, transaction information is transmitted between the bases in an asynchronous manner, each account also has a plurality of asset units AU, and the AUs under the same account can be fragmented or combined. AU is the smallest unit of transaction, and the user's total asset is the set of all AUs under his account ID. As shown in fig. 4, each version of AU can be understood as a node on a chain structure, and each transaction related to AU can be understood as an edge of this structure, and the AU is continuously driven to update.
For example, as shown in fig. 5, when the transaction request is a transfer transaction request, a data center Base1 matched with the transfer account a and a data center Base2 matched with the transfer account C are used as candidate data centers, and when determining a main data center for executing the transaction, base1 may be used as the main data center or Base2 may be used as the main data center.
In the case of Base1 as the primary data center, it is necessary to switch the primary data center of the transfer-out account C from Base2 to Base1 and then execute a transaction in Base 1. In the case of Base2 as the primary data center, it is necessary to switch the primary data center of the account a from Base1 to Base2 and then execute a transaction in Base 2.
In some embodiments, when both Base1 and Base2 are in an abnormal state and cannot perform a transaction, base3 may be taken as the primary data center, at which time the primary data center of the transfer-out account a needs to be switched from Base1 to Base2, and the primary data center of the transfer-out account C is switched from Base2 to Base1, and then the transaction is performed in Base 3.
In this embodiment, the data centers of the transfer account and the transfer account are respectively matched as candidate data centers to select the main data center for executing the transaction, so that the number of transaction accounts needing to be switched to the main data center can be reduced, the main data center for executing the transaction can be rapidly positioned, the occupation of the data resource in the process of switching to the main data center is reduced, and the resource utilization rate can be effectively improved.
In some embodiments, determining a primary data center to perform a transaction from among the data centers of the asset units storing the transaction account includes determining a first data center currently assigned to the transaction account from among the data centers of the asset units storing the transaction account as the primary data center to perform the transaction.
Further, the transaction processing method further comprises the steps of reassigning the second data center to the transaction account under the condition that the main data center is in an abnormal state, and switching the main data center for executing the transaction to the second data center.
In the transaction processing process, the data center allocated to the transaction account can be switched, in the process of executing the transaction, the first data center currently allocated to the transaction account is generally determined as the main data center for executing the transaction, when the data centers currently allocated to the transaction two parties are the same, the data center is used as the main data center for executing the transaction, and when the data centers currently allocated to the transaction two parties are different, the data center allocated to the transfer account or the transfer account can be used as the main data center for executing the transaction. When the main data center is in an abnormal state, a second data center is reassigned to the transaction account, wherein the second data center may be any one of the data centers of the asset unit in which the transaction account is stored, except the first data center.
For example, when the data centers currently allocated by the two transaction parties are different, the first data center allocated by the transfer-out account can be used as the main data center for executing the transaction, and the second data center originally allocated to the transfer-in account is reallocated to the transfer-out account under the condition that the first data center is in an abnormal state, so that the main data center for executing the transaction is switched to the second data center, and the quick searching and switching of the main data center are realized.
In this embodiment, by switching the main data center for executing the transaction, the data center can be quickly adjusted under the condition that the main data center for executing the transaction is in an abnormal state, so as to ensure that the transaction can be executed smoothly, and improve the execution efficiency of the transaction.
In some embodiments, the method further comprises creating a virtual asset unit belonging to the transfer-out account at the second data center in the event that the asset yields of the transfer-out account asset units are each less than the transaction asset yields.
Further, in the main data center, performing asset transaction according to the asset units to obtain transaction asset units updated by version identification, wherein the transaction asset units comprise performing asset transaction according to the virtual asset units before the completion of the asset unit synchronization of the second data center to generate updated virtual asset units belonging to the transfer-out account and newly-added asset units belonging to the transfer-in account, and after the completion of the asset unit synchronization of the second data center, combining the updated virtual asset units with the synchronized asset units to generate updated asset units belonging to the transfer-out account.
The virtual asset unit is a pre-supported asset unit, and the difference between the virtual asset unit and the asset unit is that the virtual asset unit is marked as a negative value by the transaction system, and is forcedly combined with the normal asset unit when the transaction system completes all data synchronization. The balance is added when the normal asset units are combined, the balance is subtracted when the virtual asset units are combined with the normal asset units, the balance of the normal asset units is required to be larger than the balance of the virtual asset units when the virtual asset units are combined, if the combined asset units are positive values, the balance of the transaction account is sufficient, the subsequent transaction can be continued, and if the combined asset units are negative values, the balance of the transaction account is insufficient, and the subsequent transaction cannot be carried out.
In some embodiments, since transaction data of the account a in the Base1 is backed up to the Base2 in an asynchronous manner, data inconsistency may occur during the Base switching, which is specifically manifested as abnormal situations such as account balance deficiency, expiration of the asset unit version, and the like.
For the case of inconsistent data, if account a has insufficient balance (no balance of any asset units is greater than the transfer Amount amountj) before time t, a special type of asset unit, namely a Virtual Asset Unit (VAU) needs to be created for account a, and a transaction process is executed through the Virtual asset unit. After the asset units are synchronously completed and automatically repaired, after the transaction system processes all AUs with the same UID of the assets, the transaction system can combine the VAU in the account with the AUs to obtain updated AUs.
The premise of starting the automatic repairing function is that the original Base is recovered and can read the data, if the original Base is in a downtime and network disconnection state all the time, the balance data cannot be synchronized all the time, the condition of inconsistent data can exist all the time, and the other condition of automatic repairing is that the AU is not allowed to be combined before the recovery is completed.
In the embodiment, by creating the virtual asset unit to execute the transaction, the asset transaction can be smoothly executed under the abnormal conditions of inconsistent data such as insufficient balance or expired version of the asset unit, and the data combination is completed after the data is automatically repaired, so that the occurrence of transaction failure caused by the asynchronous backup mode of the asset transaction data is avoided, and the occurrence of transaction failure can be effectively reduced.
In some embodiments, the process of synchronizing the asset units of the second data center includes receiving a synchronized transaction asset unit transmitted by the first data center, respectively acquiring a first transaction identification of the synchronized transaction asset unit and a second transaction identification of the actual transaction asset unit if a first version identification of the synchronized transaction asset unit is the same as a second version identification of the actual transaction asset unit of the second data center, performing transaction backtracking based on the first transaction identification and the second transaction identification to obtain a root transaction asset unit with the same transaction identification, and performing asset unit synchronization on the actual transaction asset unit based on asset changes of the root transaction asset unit and the synchronized transaction asset unit.
Wherein after switching the primary data center from the first data center to the second data center, the transaction data of the first data center may also have a part of the transaction being performed, so that the transaction data of the first data center needs to be synchronized to the second data center for data synchronization.
For the second data center, after the primary data center is switched from the first data center to the second data center, the second data center receives the synchronous data sent from the first data center, and specifically includes the synchronous transaction asset unit sent by the first data center. In some embodiments, the synchronization data sent by the first data center may be transaction metadata including, in particular, a transaction identification characterizing transaction behavior, a transaction input set where a target asset unit of the transfer-out asset is located, and a transaction output set including an updated asset unit belonging to the transfer-out account and a newly added asset unit belonging to the transfer-in account.
After receiving the synchronous transaction asset units, the second data center needs to determine the transaction actions and transaction asset volumes occurring at the first data center through version rollback and transaction backtracking. Because the transaction metadata records data corresponding to each transaction action, when version rollback and transaction backtracking are carried out, backtracking processing can be carried out based on the transaction identification and the version identification.
In particular, in the case where the first version identification of the synchronous transaction asset unit is the same as the second version identification of the actual transaction asset unit of the second data center, the second data center need not perform version rollback, but only transaction backtracking. Specifically, the second data center respectively acquires a first transaction identifier of the synchronous transaction asset unit and a second transaction identifier of the actual transaction asset unit, and the synchronous transaction asset unit and the actual transaction asset unit trace back to the same transaction asset unit according to the first transaction identifier and the second transaction identifier respectively, namely the first transaction identifier of the synchronous transaction asset unit is identical to the second transaction identifier of the actual transaction asset unit, and the first version identifier of the synchronous transaction asset unit is identical to the second version identifier of the actual transaction asset unit. The root transaction asset unit is a bifurcation point of the first data center and the second data center for generating different transactions.
And determining the balance difference between the transaction asset unit of the first data center and the root transaction asset unit based on the bifurcation point, adding the balance difference to the transaction asset unit of the second data center, creating a new recharging transaction for the transaction account A in the second data center to increase the balance of AU2 if the balance difference is greater than 0, and creating a new liability transaction for the account A in the second data center if the balance difference is less than 0, wherein a virtual asset unit is created after the transaction is executed to repair balance asset data.
As shown in fig. 6, for the synchronous transaction asset unit and the actual transaction asset unit with the same version identifier, if the transaction identifier is also the same, the synchronous transaction asset unit and the actual transaction asset unit are indicated to be the same transaction, namely, the root transaction asset unit. If the transaction identifications are different, for example, the transaction identification of the synchronous transaction asset unit is Tx3, the transaction identification of the actual transaction asset unit is Tx5, and further transaction backtracking is needed through the transaction identification, so as to obtain the synchronous transaction asset unit and the actual transaction asset unit with the same transaction identification, namely, the root transaction asset unit with Version identification of Version 3.
In this embodiment, by tracing back to the root transaction asset unit, where the first transaction identifier of the synchronous transaction asset unit is the same as the second transaction identifier of the actual transaction asset unit and the first version identifier of the synchronous transaction asset unit is the same as the second version identifier of the actual transaction asset unit, the bifurcation point of the first data center and the second data center, where different transactions are generated, can be accurately located, so that synchronization of transaction data respectively generated by different data centers can be conveniently and rapidly realized, and thus, the data synchronization efficiency is effectively improved.
In some of these embodiments, the second data center needs to perform version rollback and transaction backtracking twice in the event that the first version identification of the synchronous transaction asset unit is different from the second version identification of the actual transaction asset unit of the second data center. Specifically, the asset transaction method further comprises a process of determining, by version rollback, that the version identifies the same synchronous transaction asset unit and the actual transaction asset unit, the process specifically comprising:
The method comprises the steps of obtaining a first version identifier of a synchronous transaction asset unit and a second version identifier of an actual transaction asset unit of a second data center, determining a target asset unit with more updating times in the first version identifier and the second version identifier under the condition that the first version identifier is different from the second version identifier, and carrying out version rollback on the target asset unit to obtain the synchronous transaction asset unit and the actual transaction asset unit with the same version identifier.
In the actual data processing process, the version identifier of the synchronous transaction asset unit received by the second data center may be different from the version identifier of the actual transaction asset unit generated by the second data center, and version rollback needs to be performed on the synchronous transaction asset unit and the actual transaction asset unit until the first version identifier of the synchronous transaction asset unit is the same as the second version identifier of the actual transaction asset unit of the second data center.
In some particular embodiments, as shown in FIG. 7, the Version of the synchronous transaction asset unit that was last received by the second data center Base2 from the first data center Base1 is identified as Version5, the Version of the actual transaction asset unit that was generated by the second data center Base2 is identified as Version10 (Version number of Version10 is greater than Version 5), and the synchronous transaction asset unit with Version identified as Version4 and the actual transaction asset unit with Version identified as Version4 can be determined by the second data center via Version rollback.
The transaction of the synchronous transaction asset unit with Version identification of Version4 is identified as Tx3, the transaction of the actual transaction asset unit with Version identification of Version4 is identified as Tx5, (Tx 3 and Tx5 are only used to represent different transactions, and other symbol identifications can be used). For the synchronous transaction asset units and the actual transaction asset units with the same Version identification, if the transaction identifications are different, for example, the transaction identification of the synchronous transaction asset unit is Tx3 and the transaction identification of the actual transaction asset unit is Tx5, further transaction backtracking is needed to obtain the synchronous transaction asset units and the actual transaction asset units with the same transaction identifications are Tx2, namely, the root transaction asset unit with the Version identification of Version 3.
In the embodiment, the synchronous transaction asset units and the actual transaction asset units with the same transaction identification can be rapidly determined through version rollback, so that the root transaction asset unit is found to perform asset synchronization, and the synchronization processing efficiency is improved.
In some embodiments, as shown in fig. 8, the transaction processing method further comprises:
Step 802, acquiring the number of asset units in a transaction account in response to a plurality of transaction requests triggered concurrently for the same transaction account;
In step 804, in the case that the number of asset units is smaller than the number of transaction requests, at least a portion of the asset units of the transaction account are fragmented, so as to obtain a plurality of asset units for processing each transaction request respectively.
The transaction requests can be executed at high concurrency, for a plurality of transaction requests triggered at concurrency, the main data center can process different asset units, and under the condition that the number of the asset units is smaller than that of the transaction requests, the existing asset units can be fragmented to obtain a larger number of asset units, so that the transaction requests are executed through different asset units respectively, and the concurrency processing capacity of the transaction requests is improved.
For example, when the number of transaction requests triggered concurrently for the transaction account a is 10 and the number of the currently divided asset units capable of participating in the transaction for the transaction account a is 8, one of the asset units may be divided into 3 asset units capable of participating in the transaction so that the number of the asset units capable of participating in the transaction reaches 10, or two of the asset units may be respectively divided into 2 asset units capable of participating in the transaction so that the number of the asset units capable of participating in the transaction reaches 10. The asset units that can participate in the transaction may specifically be asset units with an asset amount greater than the transaction asset amount.
In this embodiment, when processing multiple concurrent transaction requests, the speed of processing the transaction requests by the transaction account can be further improved, the response time of the transaction requests can be reduced, and the user experience can be improved by performing the fragmentation processing on the asset units.
The application also provides an application scene, which applies the transaction processing method. Specifically, the application of the transaction processing method in the application scene is as follows:
The application scene of the application can be a transaction system supporting multiple data centers capable of being changed in different places, the system mainly follows the design principles of high throughput, high availability and easy expansion, not only provides processing capacity of larger flow and lower response delay, but also can recover at the fastest speed when facing faults, thereby achieving the effect that key services are not interrupted all the time.
The transaction system distributes a main data center (Base) for each account, the read-write request is based on the Base data, if the Base fails, the Base of the account can be switched and transaction service can be continuously provided, so that the high availability of the account is ensured, meanwhile, the system divides a plurality of Asset units (AU, asset Unit) for each account, the total Asset of the account is the sum of all Asset units, and according to the version number of the Asset units and transaction information, the system can automatically repair the conflicted or missing data when each account switches the Base, so that the consistency of the Asset data is ensured. In addition, the system divides the data replication process into two layers, each account uses a strong synchronization mode among a plurality of copies in the same data center to prevent single-point faults of the copies, ensures the availability and consistency of the accounts in a single data center, synchronously adopts an asynchronous mode to prevent single-point faults of the data center, ensures the transaction execution efficiency and disaster recovery of the data center, and can achieve better balance in the aspects of efficiency and disaster recovery by combining the data automation restoration functions.
By further splitting each account, the plurality of asset units are divided, so that each account automatically repairs conflict or missing data when the Base is switched, efficiency is improved, final consistency of the asset data is guaranteed, in addition, each Base can serve a plurality of accounts, each account carries a plurality of asset units, each asset unit can conduct transactions, and high throughput, high availability and easy expansibility of the system are improved.
Specifically, the application provides a transaction system supporting multiple data centers to be capable of multiple activities in different places, which is applicable to the transaction system requiring high throughput, disaster recovery in different places and rapid automatic recovery.
The application can be applied to disaster recovery scenes in the same city or in different places, the system distributes a Base for each account, the transaction request related to the account is accessed to the corresponding Base, each account has at least 3 copies in the Base, the 3 copies realize strong consistency data synchronization of single writing and multiple reading, and when the copies are in fault, the system can automatically complement the copies to the appointed redundancy amount, thereby ensuring the disaster recovery of the data in a single data center. Because network delay between different-place data centers is large, data generated by transaction can be synchronized to other data centers in an asynchronous mode, each account in the other data centers also has at least 3 copies, if a Base fails, the Base of a user can be switched and transaction service can be continuously provided, and the different-place disaster tolerance is ensured.
The application can also be applied to an account data automatic restoration scene, the system divides a plurality of asset units for each account, the interior of each asset unit contains data such as version numbers, balances and the like, when the Base fails, all the asset units of the account can still continue to trade under the new Base, when the original Base is restored, the asset units with data conflict exist in the account are checked, the original Base and the new Base are respectively traced back to find the same Root asset units (RAU, root AU) according to the version numbers of the asset units and the trade information, and then the differential data of the asset units are aligned, and because the granularity of the asset units is smaller, the restoration is more accurate and faster, no manual intervention is needed, and the final consistency of the asset data can be ensured.
In a specific implementation, as shown in fig. 5, the architecture of the transaction system is shown in fig. 5, the main data center of the account A, B is Base1, the main data center of the account C is Base2, the account has 3 copies in each Base and executes a strong agreement, transaction information is transmitted between the bases in an asynchronous manner, and each account also has a plurality of asset units AU, wherein the core fields of the asset units are respectively an asset UID, an account ID, a Balance, version number Version and an asset source ID (FID), the asset UID is a unique identifier thereof, and after each related transaction is executed, the Balance of the AU is updated, the Version number is updated, and the source ID of the bound asset is a transaction ID. AU under the same account can be fragmented or consolidated, and the process of fragmentation or consolidation can be understood as a special class of transactions. AU is the smallest unit of transaction, and the user's total asset is the set of all AUs under his account ID. The AU not only can express the balance information of the user, but also has the capability of backtracking related transactions and version numbers, each AU can be understood as a node on a chain structure, each related transaction of the AU can be understood as an edge of the structure, and the AU is continuously driven to update.
In the system, accounts are distinguished by business, account transactions of the same business are executed in the same Base, the transactions can be essentially divided into recharging or transferring, one transaction is divided into an input asset set and an output asset set, the asset set comprises a plurality of asset units, and the input asset set and the output asset set are bound with the transaction.
The transfer flow from account a to account B is as follows:
Step (1) account A selects an AU a of sufficient balance, transfer Amount Amount, account B as input for the transaction, and initiates the transaction.
After the transaction in the step (2) is executed, two AU a' and AU b are generated, which belong to the account A and the account B respectively. AU a 'deducts the balance and updates the asset source ID, AU b belongs to account B for the newly generated AU, the balance of AU b is equal to the transfer Amount Amount, and the Version numbers of AU a' and AU b are updated to be the maximum value of Version in the transaction input AU set plus one.
And (3) respectively storing transaction metadata (transaction ID, input set { AU a }, output set { AU a',AUb }) in 3 copies of the account A and the account B, and returning the end of transaction execution to the client after the 3 copies are in strong consistency synchronization.
Step (4) Base asynchronously synchronizes the transaction metadata to the remaining data centers, which, upon receipt, update the asset collection of the internal account A, B.
The recharge process is similar to transferring money, adding a new AU to only one account.
The premise of the disaster recovery in the same city is the step (3), the premise of the disaster recovery in different places is the step (4), the disaster recovery in different places is mainly analyzed, and the process of switching the service of the account A to the Base2 is as follows on the assumption that the Base1 of the account A fails:
step (4.1) when the upper layer route finds that Base1 is not available, switching the request flow to Base2 and setting the main Base of account a to Base2, and continuing to receive new transaction requests by account a.
Step (4.2) the new transaction can use all AUs of account a in Base2 immediately, and the AUs can be updated directly after the transaction is completed.
Because the data of the account A in the Base1 is backed up to 3 copies of the Base2 in an asynchronous mode before, the situation that the data is inconsistent can occur during the Base switching, the situation is specifically expressed as abnormal situations such as insufficient account balance, expired AU version and the like, the automatic repair function of the system is mainly analyzed according to the situation that the data is inconsistent, the premise of starting the automatic repair function is that the original Base is recovered and the data can be read, if the original Base is in a downtime and network disconnection state all the time, the balance data cannot be synchronized all the time, the situation that the data is inconsistent can always exist, and the other condition of automatic repair is that the AU is not allowed to be combined before the recovery is completed. Now, assuming that the original Base1 is successfully recovered at a certain moment in the future, the automatic repair flow is as follows:
If the balance of the account a is insufficient (no balance of any AU is greater than the transfer Amount amounta) before the time t of the step (4.3), a special AU-Virtual asset unit (VAU, virtual AU) needs to be created for the account a, the largest difference between the VAU and AU is that the special AU is marked as a negative asset by the system, the VAU is forcedly combined with a normal AU when the system finishes all data recovery, and the VAU still has the capability of backtracking, so the account a still can continue to execute transactions, and the special transactions are input into the account a (no AU is needed), the transfer Amount amounta and the account B, and the output is { VAU a,AUb }. Account a is allowed to continue to trade because account a may have a top-up transaction at the original Base but not yet synchronized.
And (4.4) after the time t, the original Base1 is successfully recovered, base2 directly pulls the latest Version AU data and transaction metadata of the account A from Base1, and the AUs of different asset UIDs are combined, and for the AUs with the same asset UID, version numbers Version and FID of the AUs are compared in sequence, wherein the conditions are as follows:
(1) If Version 1=version 2 and fid1=fid2, AU has no difference data, no processing is required.
(2) FID is equal, then Version must be equal, so there is no case where Version 1+.version 2 and fid1=fid2;
(3) If Version 1=version 2 and fid1+.fid2, AU1 and AU2 trace back to the same RAU according to FID1 and FID2, respectively (i.e. case 1). As shown in fig. 9, each AU can find specific transaction metadata through FID, and further find the last version of AU, so AU1 and AU2 can recursively repeat to the same RAU. This scheme always goes back to the same RAU, since Base1 and Base2 have only difference data, there must be one bifurcation point. After the bifurcation point is found, the balance difference between AU1 and RAU of the original Base1 is calculated, if the difference is larger than 0, a new recharging transaction is created for the account A, the balance of AU2 is increased, if the difference is smaller than 0, a new liability transaction is created for the account A, and after the transaction is executed, a VAU a is created, and the balance asset data is repaired.
(4) If Version 1. Noteq. Version2 and fid1. Noteq. FID2, after rollback Version is equal from AU to Version with greater Version, execution 3 continues.
After all the AUs of the same asset UID are processed in the step (5), the system can combine the VAU in the account with the AU, the balance is added when the AU is combined, the balance is subtracted when the VAU is combined with the AU (the balance of the AU is required to be larger than the balance of the VAU when the AU is combined), and if the VAU which cannot be combined exists after the combination is completed, the account is in arrearage state, and subsequent transaction cannot be carried out.
The account switching Base and the automatic recovery flow are finished, the step (3) of the automatic recovery process allows the account to continue to provide transaction service without being influenced by the original Base fault, and meanwhile, the recovery processes of the steps (4, 5) are executed in the background without influencing normal transaction until the system automatically judges whether the account can continue to conduct transaction after the step (5) is completed.
The asset unit will be a smaller computable unit than the account. Because the asset units are smaller, when data conflict or deletion occurs in the account, the data conflict or deletion usually occurs in a part of the asset units, and the rest of the asset units can be directly added or combined to a new Base, so that account balance data can be recovered from granularity of the asset units directly, transaction is not required to be repeatedly executed in the recovery process, manual intervention is not required, and normal transaction is not blocked. The recovery mode can recover more accurately and rapidly, can ensure consistency of asset data, can serve a plurality of accounts by each Base and carry a plurality of asset units by each account, can trade each asset unit, can theoretically promote trade throughput of each account, and ensures high availability and easy expansibility of the system. The system adopts a mode of combining strong synchronization and asynchronism, the data integrity of accounts in a single data center is guaranteed by the strong synchronization, the availability of the accounts in Base switching is guaranteed by asynchronism, and the data consistency in Base switching is guaranteed by combining an automatic recovery function.
It should be understood that, although the steps in the flowcharts related to the above embodiments are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.
Based on the same inventive concept, the embodiment of the application also provides a transaction processing device for realizing the transaction processing method. The implementation of the solution provided by the device is similar to that described in the above method, so the specific limitation of one or more embodiments of the transaction processing device provided below may refer to the limitation of the transaction processing method hereinabove, and will not be repeated herein.
In one embodiment, as shown in FIG. 10, a transaction processing device 1000 is provided, comprising a transaction account determination module 1002, a primary data center determination module 1004, a transaction execution module 1006, and a data synchronization module 1008, wherein:
A transaction account determination module 1002, configured to determine, in response to a transaction request, a transaction account involved in a transaction, where the transaction account includes at least one asset unit, where the asset unit carries a version identifier updated according to transaction behavior, and a sum of assets of each of the asset units is used to characterize a total asset yield of the transaction account;
a main data center determining module 1004 configured to determine a main data center for executing a transaction from among the data centers of the asset units storing the transaction account;
A transaction execution module 1006, configured to execute, in the main data center, an asset transaction according to the asset unit, to obtain a transaction asset unit updated by a version identifier;
A data synchronization module 1008 for synchronizing the transaction asset units to each of the data centers.
In some embodiments, the transaction processing device 1000 further comprises a target asset unit determining unit for determining a target asset unit participating in a transaction from asset units of the transaction account based on the transaction asset amount requested by the transaction request, wherein the asset amount of the target asset unit is greater than or equal to the transaction asset amount;
The transaction execution module 1006 is specifically configured to execute an asset transaction on the target asset unit according to the transaction asset yield, and generate an updated asset unit belonging to the transfer account and a new added asset unit belonging to the transfer account, where a version identifier of the updated asset unit and a version identifier of the new added asset unit are both associated with a version identifier of the target asset unit.
In some of these embodiments, the transaction processing device 1000 further includes a transaction metadata construction module for taking the target asset units involved in transactions as a transaction input set and the updated asset units and the newly added asset units as a transaction output set;
the data synchronization module 1008 is specifically configured to synchronize the transaction metadata to each of the data centers.
In some embodiments, the transaction account comprises a transfer account in the case that the transaction request is a recharge transaction request, and the transaction execution module 1006 is specifically configured to execute an asset transaction according to the transaction asset yield, and generate a new asset unit belonging to the transfer account.
In some embodiments, each data center comprises a plurality of copies, the transaction execution module 1006 is further configured to determine a master copy for participating in transactions and a slave copy for synchronizing data from the copies of the master data center;
The data synchronization module 1008 is further configured to synchronize the transaction asset units to each of the slave copies.
In some embodiments, the main data center determining module 1004 is specifically configured to, in a case where the transaction request is a transfer transaction request, use data centers that are matched with the transfer account and the transfer account as candidate data centers, and select a main data center that performs the transaction from among the candidate data centers.
In some embodiments, the main data center determining module 1004 is specifically configured to determine, from among the data centers of the asset units storing the transaction account, a first data center currently allocated to the transaction account as a main data center for executing a transaction, reallocate a second data center to the transaction account if the main data center is in an abnormal state, and switch the main data center for executing the transaction to the second data center.
In some embodiments, the transaction processing device 1000 further includes a virtual asset unit creation module for creating a virtual asset unit belonging to the transfer-out account at the second data center if the asset unit of the transfer-out account has a smaller asset yield than the transaction asset yield;
The transaction execution module 1006 is specifically configured to execute an asset transaction according to the virtual asset unit before the completion of the synchronization of the asset unit in the second data center, generate an updated virtual asset unit belonging to the transfer-out account and a new asset unit belonging to the transfer-in account, and after the completion of the synchronization of the asset unit in the second data center, merge the updated virtual asset unit with the synchronized asset unit to generate an updated asset unit belonging to the transfer-out account.
In some embodiments, the transaction processing device 1000 further includes an asset unit synchronization module configured to receive a synchronous transaction asset unit sent by the first data center, acquire a first transaction identifier of the synchronous transaction asset unit and a second transaction identifier of the actual transaction asset unit respectively if a first version identifier of the synchronous transaction asset unit is the same as a second version identifier of the actual transaction asset unit of the second data center, perform transaction backtracking based on the first transaction identifier and the second transaction identifier to obtain a root transaction asset unit with the same transaction identifier, and perform asset unit synchronization on the actual transaction asset unit based on asset changes of the root transaction asset unit and the synchronous transaction asset unit.
In some embodiments, the asset unit synchronization module is further configured to obtain a first version identifier of the synchronous transaction asset unit and a second version identifier of an actual transaction asset unit of the second data center, determine a target asset unit with a larger update number in the first version identifier and the second version identifier when the first version identifier is different from the second version identifier, and perform version rollback on the target asset unit to obtain a synchronous transaction asset unit and an actual transaction asset unit with the same version identifier.
In some embodiments, the transaction processing device 1000 further includes an asset unit slicing module, configured to obtain the number of asset units in the transaction account in response to a plurality of transaction requests triggered concurrently for the same transaction account, and perform slicing processing on at least a portion of the asset units in the transaction account to obtain a plurality of asset units for processing each transaction request respectively if the number of asset units is smaller than the number of transaction requests.
According to the transaction processing device, the transaction accounts are divided into the asset units, the asset transaction processing can be directly carried out from the granularity of the asset units, the concurrent processing capacity of the asset transaction processing can be effectively improved, meanwhile, the version identifiers carried by the asset units are updated according to the transaction behaviors, backtracking of transactions can be realized between synchronous transaction asset units of different data centers based on the version identifiers, so that difference data of account transactions can be directly recovered from the granularity of the asset units, execution of other normal asset transactions cannot be blocked, transaction throughput of each transaction account can be improved, high availability of a transaction process is guaranteed, and further transaction processing efficiency can be effectively improved.
The various modules in the transaction processing device described above may be implemented in whole or in part in software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 11. The computer device includes a processor, a memory, an Input/Output interface (I/O) and a communication interface. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface is connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device is for storing data. The input/output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a transaction processing method.
In one embodiment, a computer device is provided, which may be a terminal, and the internal structure thereof may be as shown in fig. 12. The computer device includes a processor, a memory, an input/output interface, a communication interface, a display unit, and an input means. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input/output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless mode can be realized through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a transaction processing method. The display unit of the computer equipment is used for forming a visual picture, and can be a display screen, a projection device or a virtual reality imaging device, wherein the display screen can be a liquid crystal display screen or an electronic ink display screen, the input device of the computer equipment can be a touch layer covered on the display screen, can also be a key, a track ball or a touch pad arranged on a shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.
It will be appreciated by those skilled in the art that the structures shown in fig. 11 or 12 are merely block diagrams of portions of structures associated with the present inventive arrangements and do not constitute a limitation of the computer devices to which the present inventive arrangements may be applied, and that a particular computer device may include more or less components than those shown, or may combine some components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps of the method embodiments described above when the computer program is executed.
In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored which, when executed by a processor, carries out the steps of the method embodiments described above.
In an embodiment, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the steps of the method embodiments described above.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are both information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data are required to meet the related regulations.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magneto-resistive random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (PHASE CHANGE Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in various forms such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc. The databases referred to in the embodiments provided herein may include at least one of a relational database and a non-relational database. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processor referred to in the embodiments provided in the present application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, or the like, but is not limited thereto.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of the application should be assessed as that of the appended claims.

Claims (15)

1. A method of transaction processing, the method comprising:
In response to a transaction request, determining a transaction account for participation in a transaction, the transaction account including at least one asset unit carrying a version identification updated by transaction activity, a sum of assets for each of the asset units being used to characterize a total asset yield of the transaction account;
determining a master data center for executing the transaction from among the data centers of the asset units storing the transaction account;
Executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identification;
Synchronizing the transaction asset units to each of the data centers.
2. The method of claim 1, wherein in the event that the transaction request is a transfer transaction request, the transaction account comprises a transfer-in account and a transfer-out account, the method further comprising:
Determining a target asset unit participating in the transaction from asset units of the transaction account based on the transaction asset yield requested by the transaction request, wherein the asset amount of the target asset unit is greater than or equal to the transaction asset yield;
The executing asset transaction by the asset unit, generating an updated asset unit with updated version identification, comprising:
Performing asset transaction on the target asset unit according to the transaction asset yield, and generating an updated asset unit belonging to the transfer-out account and a newly-added asset unit belonging to the transfer-in account;
wherein the version identification of the updated asset unit and the version identification of the newly added asset unit are both associated with the version identification of the target asset unit.
3. The method according to claim 2, wherein the method further comprises:
taking the target asset units participating in the transaction as a transaction input set, and taking the updated asset units and the newly-added asset units as a transaction output set;
constructing transaction metadata including a transaction identification characterizing the transaction behavior, the transaction input set, and the transaction output set;
The synchronizing the transaction asset units to each of the data centers includes:
synchronizing the transaction metadata to each of the data centers.
4. The method of claim 1, wherein the transaction account comprises a transfer-in account if the transaction request is a top-up transaction request;
The executing asset transaction by the asset unit, generating an updated asset unit with updated version identification, comprising:
And executing asset transaction according to the transaction resource yield, and generating a new asset unit belonging to the transfer account.
5. The method of claim 1, wherein each of the data centers comprises a plurality of copies;
And executing asset transaction according to the asset unit in the main data center to obtain a transaction asset unit with updated version identification, wherein the transaction asset unit comprises:
Determining a master copy for participating in a transaction and a slave copy for synchronizing data from the copies of the master data center;
Performing asset transaction based on the target asset unit stored in the master copy to obtain a transaction asset unit updated by the version identification;
and after the main data center executes the asset transaction according to the asset unit to obtain the transaction asset unit with updated version identification, the main data center further comprises:
Synchronizing the transaction asset units to each of the slave copies.
6. The method of claim 1, wherein determining a master data center to perform a transaction from among the data centers of the asset units storing the transaction account comprises:
Taking the data centers matched with the transfer account and the transfer account as candidate data centers when the transaction request is a transfer transaction request;
from each of the candidate data centers, a master data center is selected that performs the transaction.
7. The method of claim 1, wherein determining a master data center to perform a transaction from among the data centers of the asset units storing the transaction account comprises:
determining a first data center currently allocated to the transaction account as a master data center for executing a transaction from among the data centers of the asset units storing the transaction account;
The method further comprises the steps of:
under the condition that the main data center is in an abnormal state, a second data center is allocated for the transaction account again;
and switching the main data center for executing the transaction to the second data center.
8. The method of claim 7, wherein the method further comprises:
creating a virtual asset unit belonging to the transfer-out account at the second data center under the condition that the asset yield of each asset unit of the transfer-out account in the transaction account is smaller than the transaction asset yield;
And executing asset transaction according to the asset unit in the main data center to obtain a transaction asset unit with updated version identification, wherein the transaction asset unit comprises:
Before the second data center completes the synchronization of the asset units, performing asset transaction according to the virtual asset units to generate updated virtual asset units belonging to the transfer-out account and newly-added asset units belonging to the transfer-in account;
and after the second data center completes the synchronization of the asset units, merging the updated virtual asset units with the synchronized asset units to generate updated asset units belonging to the transfer-out account.
9. The method of claim 8, wherein the process of asset unit synchronization of the second data center comprises:
Receiving a synchronous transaction asset unit sent by the first data center;
under the condition that the first version identifier of the synchronous transaction asset unit is the same as the second version identifier of the actual transaction asset unit of the second data center, respectively acquiring the first transaction identifier of the synchronous transaction asset unit and the second transaction identifier of the actual transaction asset unit;
carrying out transaction backtracking based on the first transaction identifier and the second transaction identifier to obtain a root transaction asset unit with the same transaction identifier;
and performing asset unit synchronization on the actual transaction asset unit based on the asset change of the root transaction asset unit and the synchronous transaction asset unit.
10. The method according to claim 9, wherein the method further comprises:
acquiring a first version identifier of the synchronous transaction asset unit and a second version identifier of an actual transaction asset unit of the second data center;
determining a target asset unit with more updating times in the first version identifier and the second version identifier under the condition that the first version identifier is different from the second version identifier;
And carrying out version rollback on the target asset unit to obtain a synchronous transaction asset unit and an actual transaction asset unit with the same version identification.
11. The method according to any one of claims 1 to 10, further comprising:
responding to a plurality of transaction requests which are triggered for the same transaction account in parallel, and acquiring the number of asset units in the transaction account;
And under the condition that the number of the asset units is smaller than the number of the transaction requests, performing fragmentation processing on at least one part of the asset units of the transaction account to obtain a plurality of asset units respectively used for processing the transaction requests.
12. A transaction processing device, the device comprising:
A transaction account determination module for determining a transaction account involved in a transaction in response to a transaction request, the transaction account comprising at least one asset unit carrying a version identification updated by transaction activity, the sum of the assets of each of the asset units being used to characterize the total asset yield of the transaction account;
a master data center determination module for determining a master data center for executing a transaction from among the data centers of the asset units storing the transaction account;
the transaction execution module is used for executing asset transaction according to the asset units in the main data center to obtain transaction asset units with updated version identifiers;
And the data synchronization module is used for synchronizing the transaction asset units to each data center.
13. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 11 when the computer program is executed.
14. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 11.
15. A computer program product comprising a computer program, characterized in that the computer program, when executed by a processor, implements the steps of the method of any one of claims 1 to 11.
CN202311403425.2A 2023-10-26 2023-10-26 Transaction processing method, device, computer equipment and storage medium Pending CN119904228A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311403425.2A CN119904228A (en) 2023-10-26 2023-10-26 Transaction processing method, device, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311403425.2A CN119904228A (en) 2023-10-26 2023-10-26 Transaction processing method, device, computer equipment and storage medium

Publications (1)

Publication Number Publication Date
CN119904228A true CN119904228A (en) 2025-04-29

Family

ID=95466945

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311403425.2A Pending CN119904228A (en) 2023-10-26 2023-10-26 Transaction processing method, device, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN119904228A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120258997A (en) * 2025-06-05 2025-07-04 嘉实远见科技(北京)有限公司 A fund registration and transfer method and system based on distributed transaction mechanism

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120258997A (en) * 2025-06-05 2025-07-04 嘉实远见科技(北京)有限公司 A fund registration and transfer method and system based on distributed transaction mechanism

Similar Documents

Publication Publication Date Title
JP7001843B2 (en) Data backup methods and their computer programs and computing devices
CN112035410B (en) Log storage method, device, node device and storage medium
JP6553822B2 (en) Dividing and moving ranges in distributed systems
JP2023546249A (en) Transaction processing methods, devices, computer equipment and computer programs
WO2021238701A1 (en) Data migration method and device
CN112162846B (en) Transaction processing method, device and computer readable storage medium
WO2022174735A1 (en) Data processing method and apparatus based on distributed storage, device, and medium
CN105930498A (en) Distributed database management method and system
CN106815218A (en) Data bank access method, device and Database Systems
JP7595758B2 (en) Transaction processing method, device, electronic device, and computer program for database system
CN112181723A (en) Financial disaster recovery method and device, storage medium and electronic equipment
CN110532243A (en) Data processing method, device and electronic equipment
CN113687964A (en) Data processing method, data processing apparatus, electronic device, storage medium, and program product
CN113193947B (en) Method, apparatus, medium, and program product for implementing distributed global ordering
CN114443908A (en) Graph database construction method, system, terminal and storage medium
CN115292394A (en) Data processing method, apparatus, computer equipment and storage medium
CN119904228A (en) Transaction processing method, device, computer equipment and storage medium
CN117424799A (en) Disaster recovery method and system
CN115774754B (en) Metadata management method, device, equipment and medium based on distributed transactions
CN113297173A (en) Distributed database cluster management method and device and electronic equipment
US20160350328A1 (en) Method and system for unified technological stack management for relational databases
CN115238006A (en) Retrieval data synchronization method, device, equipment and computer storage medium
CN119105909A (en) Cross-data center data backup method and device based on operation and maintenance orchestration
CN118394545A (en) Log writing method, log writing device, computer equipment, readable storage medium and program product
CN115955488B (en) Distributed storage copy cross-machine room placement method and device based on copy redundancy

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication