A transaction processing method and system
By introducing transaction logging, optimistic locking, and intelligent retry mechanisms for compensated transactions into fund operations, the reliability issues of fund operations under a distributed architecture are resolved, transaction success rate and system availability are improved, and data consistency and fund security are ensured.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING LANGE CLOUD BUSINESS TECH CO LTD
- Filing Date
- 2026-03-09
- Publication Date
- 2026-06-09
AI Technical Summary
In existing technologies, fund operations under a distributed architecture face uncertainties such as network latency, resource contention, and node failures. This leads to indiscriminate retry mechanisms wasting computing resources and potentially causing system congestion, thus failing to effectively improve system reliability.
An intelligent retry mechanism based on pipeline records is adopted to distinguish between transient failures and permanent failures. Through optimistic locking and compensatory transaction design, controlled retry and rollback operations are achieved to avoid invalid retries.
It improves transaction success rate and system availability, reduces database lock contention in high-concurrency scenarios, and ensures data consistency and fund security.
Smart Images
Figure CN122173322A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a transaction processing method and system. Background Technology
[0002] In e-commerce, mobile payment, and modern financial services, fund transaction systems serve as core infrastructure, and the high reliability, strong consistency, and high concurrency capabilities of their processing are crucial technical indicators. These systems typically receive fund operation requests from upstream business systems (such as order systems and marketing systems) and call the underlying database to update account balances. However, in a distributed architecture, database operations face various uncertainties such as network latency, resource contention, and node failures. Ensuring data accuracy and business stability for every fund operation under abnormal conditions has become an ongoing technical challenge in this field.
[0003] Common technical solutions in the industry to ensure the reliability of fund operations mainly involve the account center directly executing fund update operations (such as deductions and transfers) within a database transaction after receiving a business request. After the operation is executed, it waits for the database to return the result. If the database operation fails (such as throwing an SQLException), it immediately retryes the operation. If the retry operation reaches a preset number of times, it triggers a database transaction rollback to undo all changes in the transaction and returns a failure response to the business system.
[0004] However, this existing technology directly retryes all types of failed operations. This indiscriminate retry mechanism not only fails to effectively improve system reliability, but also wastes a lot of computing resources by ineffectively retrying business-related permanent errors such as "insufficient balance". It may also exacerbate system congestion or even trigger an avalanche by launching a concentrated retry attack when the database is overloaded. Summary of the Invention
[0005] Based on this, in response to the aforementioned technical problems, a transaction processing method and system are provided to solve the problem that the existing technology's indiscriminate retry mechanism may lead to invalid retries and waste a large amount of computing resources.
[0006] Firstly, a transaction processing method, the method comprising:
[0007] In response to a fund operation request from the business system, a transaction record with a globally unique serial number is created, and the status of the transaction record is marked as "processing".
[0008] Based on the fund operation request, a fund operation instruction is sent to the database;
[0009] Obtain execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, determine the cause of failure and identify whether the cause of failure is a retryable transient failure or a non-retryable permanent failure.
[0010] If the failure is a retryable transient failure, then at least N retry operations are initiated to the database; wherein each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, the status of the transaction record is marked as successful; if the retry operation fails again after N retry operations, then proceed to the next step.
[0011] If the failure is a permanent failure that cannot be retried, or if the failure still occurs after N retries, then the compensation transaction operation corresponding to the execution feedback of the fund operation is executed to achieve rollback, and the transaction record is marked as failed.
[0012] Optionally, in the above scheme, determining whether the cause of failure is a retryable transient failure or a non-retryable permanent failure includes:
[0013] If the failure is due to database connection timeout, lock wait timeout, transient network anomaly, or optimistic lock conflict, it is determined to be a retryable transient failure.
[0014] If the failure is due to insufficient account balance, abnormal account status, parameter verification failure, or business rule verification failure, it is determined to be a permanent failure that cannot be retried.
[0015] Optionally, in the above scheme, the retry operation employs an exponential backoff algorithm, specifically including:
[0016] Set the maximum number of retries, the maximum backoff delay, and the initial backoff delay time;
[0017] After each failed retry, the delay time for the next retry is increased by a set multiple until the maximum backoff delay or the maximum number of retries is reached.
[0018] Optionally, in the above scheme, the process of initiating a fund operation instruction to the database adopts an optimistic locking execution mechanism.
[0019] Optionally, in the above scheme, the execution of the compensation transaction for rollback specifically includes:
[0020] Based on the transaction records, the original fund operations that have been successfully executed are identified;
[0021] Generate a compensation operation instruction that is the opposite of the original fund operation logic;
[0022] The compensation operation instruction is executed, and upon successful execution, the status of the transaction record is updated to "rollback completed"; wherein, the compensation operation instruction is designed to be an idempotent operation.
[0023] Optionally, in the above scheme, marking the transaction record as a failure further includes:
[0024] The transaction number corresponding to the transaction record and the operation failure information are sent to the business system.
[0025] Optionally, in the above scheme, after obtaining the execution feedback of the fund operation instruction, the method further includes:
[0026] If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to be successful, and the transaction number corresponding to the transaction record and the operation success information are sent to the business system.
[0027] Secondly, a transaction processing system, the system comprising:
[0028] Transaction record creation module: In response to a fund operation request from the business system, it creates a transaction record with a globally unique transaction number and marks the status of the transaction record as "processing".
[0029] Fund operation instruction issuance module: Used to issue fund operation instructions to the database based on fund operation requests;
[0030] Operation failure reason classification module: used to obtain the execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, the failure reason is determined and it is determined whether the failure reason is a retryable transient failure or a non-retryable permanent failure.
[0031] Retry operation module: If the failure reason is a retryable transient failure, then initiate at least N retry operations to the database; wherein, each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, mark the status of the transaction record as successful; if it still fails after executing N retry operations, then execute the rollback module.
[0032] Rollback module: If the failure reason is a permanent failure that cannot be retried, or if the failure still occurs after N retries, the module executes the compensation transaction operation corresponding to the execution feedback of the fund operation to achieve rollback and marks the transaction record as a failure.
[0033] Thirdly, a computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the transaction processing method described in the first aspect above.
[0034] Fourthly, a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the transaction processing method described in the first aspect.
[0035] This application has at least the following beneficial effects:
[0036] This application, upon receiving a fund operation request from the business system and initiating a fund operation instruction to the database, does not directly roll back if the execution feedback indicates that the operation failed. Instead, it determines the cause of failure based on the execution feedback, classifying it as a retrievable transient failure or a non-retrievable permanent failure. If it is a retrievable transient failure, a retry operation is initiated with the database. If it is a non-retrievable permanent failure, or if the failure persists after N retries, a compensation transaction corresponding to the fund operation's execution feedback is executed to achieve a rollback. Thus, for recoverable faults such as network jitter and database lock timeouts, a controlled intelligent retry mechanism is triggered, enabling a large number of otherwise failed transactions to be successfully completed, directly improving the transaction success rate and overall system availability. For non-retrievable permanent failures, the process is immediately terminated and rolled back, avoiding meaningless waiting and wasted retry resources.
[0037] By using optimistic locking to replace or supplement traditional pessimistic locking, version verification is performed when updating data instead of locking beforehand, which greatly reduces database lock contention in high-concurrency scenarios.
[0038] By combining "streaming logs + intelligent retries + compensatory transactions (rollbacks)," a complete fault-tolerant closed loop is formed. Even if the system fails after multiple retries, it can ensure eventual data consistency through idempotent and reliable compensatory transactions, preventing incorrect fund transfers. Attached Figure Description
[0039] Figure 1 This application provides a schematic flowchart of a transaction processing method according to one embodiment.
[0040] Figure 2 A schematic diagram illustrating the transaction success process provided in one embodiment of this application;
[0041] Figure 3 This is a schematic diagram of a transaction failure post-processing procedure provided in one embodiment of this application. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0043] In one embodiment, such as Figure 1 As shown, a transaction processing method is provided, the method comprising:
[0044] Step S1: In response to a fund operation request from the business system, create a transaction record with a globally unique serial number and mark the status of the transaction record as "processing".
[0045] Step S2: Based on the fund operation request, send a fund operation instruction to the database.
[0046] Step S3: Obtain the execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, determine the cause of failure and identify whether the cause of failure is a retrievable transient failure or a non-retrievable permanent failure.
[0047] Step S4: If the failure reason is a retryable transient failure, then initiate at least N retry operations to the database; wherein, each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, mark the status of the transaction record as successful; if it still fails after executing N retry operations, then proceed to the next step.
[0048] Step S5: If the failure reason is a permanent failure that cannot be retried, or if the failure still occurs after N retry operations, then execute the compensation transaction operation corresponding to the execution feedback of the fund operation to achieve rollback, and mark the transaction record as a failure.
[0049] In this embodiment, as Figure 2 As shown, the steps for successfully executing a fund operation instruction include the following:
[0050] (1) Initiating a request: The business system initiates a fund operation request to the account center (e.g., deduct 100 yuan);
[0051] (2) Creating a transaction record: After receiving the request, the first step of the account center is not to directly operate the funds, but to write a record to the database. This record contains a globally unique transaction number and its initial status is "processing".
[0052] (3) Execution of operations: After the transaction record is successfully created, the account center will start to execute the core fund operations, namely, operate the database, update the corresponding account balance, and use optimistic locking to prevent concurrency.
[0053] (4) Mark Success: After a successful database operation, the account center will update the transaction record and mark its status as "successful".
[0054] (5) Return result: Finally, the account center returns a success response to the business system, which includes information such as the operation serial number, so that the business system can record it itself.
[0055] In this scenario, the entire process is completed smoothly within the account center without triggering retry, alarm, or rollback mechanisms.
[0056] like Figure 3 As shown, the steps for successfully executing a fund operation instruction include the following:
[0057] (1) Initiating a request: The business system initiates a fund operation request to the account center (e.g., deduct 100 yuan);
[0058] (2) Creating a transaction record: After receiving the request, the first step of the account center is not to directly operate the funds, but to write a record to the database. This record contains a globally unique transaction number and its initial status is "processing".
[0059] (3) Execution of operations: After the transaction record is successfully created, the account center will start to execute the core fund operations, namely, operate the database, update the corresponding account balance, and use optimistic locking to prevent concurrency.
[0060] (4) The database returns a failure message to the account center, such as a lock wait timeout due to database overload or an optimistic lock update failure. The failure message is categorized as either a retryable transient failure or a non-retryable permanent failure. If it is a retryable transient failure, it will not immediately give up but will initiate a retry mechanism. It will wait a short period (using an exponential backoff algorithm) and then resend the fund operation to the database. This loop will repeat, incrementing the failure count by 1 each time, and checking if the maximum number of attempts (3 times) has been reached. If the loop completes and the operation still fails after 3 retries, the account center determines that the operation cannot be recovered through automatic retries.
[0061] (5) If the failure is permanent and cannot be retried, or if the failure still occurs after the maximum number of retries, the account center will first update the status of the transaction record to "failed". Then, in order to ensure data consistency, a compensation transaction (i.e., rollback operation) will be executed.
[0062] (6) Send alarm: After completing all internal remedial measures, send a detailed alarm message for one day, including: the serial number of the failure, the business type, the reason for the failure, etc.
[0063] (7) Return the final result: The account center returns a clear failure response to the initial business system, informing the business system that the operation was unsuccessful, and the business system will carry out subsequent business logic processing based on this result.
[0064] In the aforementioned transaction processing method, after initiating a fund operation instruction to the database based on a fund operation request from the business system, if the execution feedback indicates that the operation failed, a rollback is not performed directly. Instead, the reason for the failure is determined based on the execution feedback, classifying it as either a retryable transient failure or a non-retryable permanent failure. If it is a retryable transient failure, a retry operation is initiated with the database. If it is a non-retryable permanent failure, or if the failure persists after N retries, a compensation transaction operation corresponding to the fund operation's execution feedback is executed to achieve a rollback. Thus, for recoverable faults such as network jitter and database lock timeouts, a controlled intelligent retry mechanism is triggered, enabling a large number of transactions that would otherwise fail to complete successfully, thereby directly improving the transaction success rate and the overall availability of the system. For non-retryable permanent failures...
[0065] In one embodiment, determining whether the cause of failure is a retryable transient failure or a non-retryable permanent failure includes:
[0066] If the failure is due to database connection timeout, database lock wait timeout, transient network anomaly, or optimistic lock conflict, it is determined to be a transient failure that can be retried.
[0067] If the failure is due to insufficient account balance, abnormal account status (e.g., frozen), parameter verification failure (e.g., negative amount), or business rule verification failure (e.g., exceeding the daily transaction limit), it is determined to be a permanent failure that cannot be retried.
[0068] In one embodiment, the retry operation employs an exponential backoff algorithm, specifically including:
[0069] Set the maximum number of retries, the maximum backoff delay, and the initial backoff delay time;
[0070] After each failed retry, the delay time for the next retry is increased by a set multiple until the maximum backoff delay or the maximum number of retries is reached.
[0071] In one embodiment, the process of initiating a fund operation instruction to the database employs an optimistic locking mechanism.
[0072] In this embodiment, specifically, the optimistic locking implementation scheme is as follows: obtain the current account balance before updating, and use the balance as a judgment condition when executing the update SQL.
[0073] Step 1: Read data. The transaction control module first reads the information of the current account.
[0074] Step 2: Based on the balance value read in Step 1, construct and execute a conditional update SQL statement. Not only should the account to be updated be specified, but the current balance of the account must also be strictly equal to the value read in Step 1.
[0075] Step 3: After the database executes the above update statement, it will return a clear execution result to the application to determine the update result;
[0076] Based on the update statement executed in step two, the database will return the number of rows affected.
[0077] Scenario A: Number of rows affected = 1, indicating a successful update. This means the database found a record that perfectly matches all conditions (account ID and balance value are exactly the same) and successfully updated it. This implies that no other concurrent operations modified the record during the entire process from "read" to "update," and the update was successful.
[0078] Scenario B: Number of affected rows = 0. This indicates that another transaction preemptively modified this data between the read and update steps, causing the condition to fail. The database did not find any record that simultaneously satisfies all conditions in the WHERE clause. The most likely reason is that within a very short time window between step one (reading the balance) and step two (initiating the update), another concurrent transaction completed modifying the account balance, causing the current balance value to change and no longer equal to the old value read in step one. Therefore, this update failed to execute due to condition mismatch, indicating an "optimistic locking conflict."
[0079] When an optimistic locking conflict occurs (Case B), i.e., the update operation fails, the transaction control module will capture this specific failure. Optimistic locking conflicts are categorized as "retryable transient failures." This is because it does not represent a business logic error, but merely an "incorrect timing of the operation," and a later retry is likely to succeed. Once the transaction control module detects that the number of affected rows is 0, it will immediately trigger the aforementioned intelligent retry process.
[0080] Using optimistic locking as the mechanism for determining account fund updates is a core technological highlight of this invention in handling high-concurrency financial scenarios. It not only solves the performance bottleneck of traditional pessimistic locking but also seamlessly integrates with the retry and rollback mechanisms of this invention, jointly constructing a high-performance, highly reliable, and highly consistent fund risk control system.
[0081] In one embodiment, performing the compensation transaction to rollback specifically includes:
[0082] Based on the transaction records, the original fund operations that have been successfully executed are identified;
[0083] Generate a compensation operation instruction that is the opposite of the original fund operation logic;
[0084] The compensation operation instruction is executed, and upon successful execution, the status of the transaction record is updated to "rollback completed"; wherein, the compensation operation instruction is designed to be an idempotent operation.
[0085] In this embodiment, rollback is the last line of defense to ensure data consistency. This invention employs a compensating transaction model to achieve accurate and secure rollback.
[0086] The design principles of the compensation transactions in this application include:
[0087] (1) Idempotency: The rollback operation itself must be idempotent. That is, the result is the same no matter how many times it is executed. This is crucial to prevent repeated rollbacks caused by network problems.
[0088] (2) Atomicity: The compensation transaction itself should be an atomic operation, either all of them succeed or all of them fail.
[0089] The steps to implement a rollback operation are as follows:
[0090] Assuming the original operation is "transfer 100 yuan from account A to account B", the steps are as follows: Step 1: 1100 yuan is deducted from account A; Step 2: 100 yuan is credited to account B.
[0091] If step 2 fails, a rollback operation is performed: if the log shows that "Account A was deducted 100 yuan" successfully, a compensation instruction of "Account A received 100 yuan" needs to be generated. After successful compensation, the status of the original transaction record is updated to "rollback completed". If the compensation operation fails, the status of the original transaction record is updated to "rollback failed", and a high-priority alarm is triggered to notify manual intervention for this operation.
[0092] In one embodiment, marking the transaction record as failed further includes: sending the transaction number corresponding to the transaction record and operation failure information to the business system.
[0093] In one embodiment, after obtaining the execution feedback of the fund operation instruction, the method further includes: if the execution feedback indicates that the operation was unsuccessful, then determining that the fund operation was successfully executed, and sending the transaction number corresponding to the transaction record and the operation success information to the business system.
[0094] In one embodiment, a transaction processing system includes:
[0095] Transaction record creation module: In response to a fund operation request from the business system, it creates a transaction record with a globally unique transaction number and marks the status of the transaction record as "processing".
[0096] Fund operation instruction issuance module: used to issue fund operation instructions to the database based on fund operation requests;
[0097] Operation failure reason classification module: used to obtain the execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, the failure reason is determined and it is determined whether the failure reason is a retryable transient failure or a non-retryable permanent failure.
[0098] Retry operation module: If the failure reason is a retryable transient failure, then initiate at least N retry operations to the database; wherein, each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, mark the status of the transaction record as successful; if it still fails after executing N retry operations, then execute the rollback module.
[0099] Rollback module: If the failure reason is a permanent failure that cannot be retried, or if the failure still occurs after N retries, the module executes the compensation transaction operation corresponding to the execution feedback of the fund operation to achieve rollback and marks the transaction record as a failure.
[0100] For specific limitations regarding a transaction processing system, please refer to the limitations regarding a transaction processing method above, which will not be repeated here. Each module in the aforementioned transaction processing system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0101] In one embodiment, a computer device is provided, which may be a server. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and 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 stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements one of the transaction processing methods described above.
[0102] In one embodiment, a computer-readable storage medium is also provided, on which a computer program is stored relating to all or part of the processes in the methods of the above embodiments.
[0103] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.
[0104] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0105] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A transaction processing method, characterized in that, The method includes: In response to a fund operation request from the business system, a transaction record with a globally unique serial number is created, and the status of the transaction record is marked as "processing". Based on the fund operation request, a fund operation instruction is sent to the database; Obtain execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, determine the cause of failure and identify whether the cause of failure is a retryable transient failure or a non-retryable permanent failure. If the failure is a retryable transient failure, then at least N retry operations are initiated to the database; wherein each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, the status of the transaction record is marked as successful; if the retry operation fails again after N retry operations, then proceed to the next step. If the failure is a permanent failure that cannot be retried, or if the failure still occurs after N retries, then the compensation transaction operation corresponding to the execution feedback of the fund operation is executed to achieve rollback, and the transaction record is marked as failed.
2. The transaction processing method according to claim 1, characterized in that, Determining whether the cause of failure is a retryable transient failure or a non-retryable permanent failure includes: If the failure is due to database connection timeout, lock wait timeout, transient network anomaly, or optimistic lock conflict, it is determined to be a retryable transient failure. If the failure is due to insufficient account balance, abnormal account status, parameter verification failure, or business rule verification failure, it is determined to be a permanent failure that cannot be retried.
3. The transaction processing method according to claim 1, characterized in that, The retry operation employs an exponential backoff algorithm, specifically including: Set the maximum number of retries, the maximum backoff delay, and the initial backoff delay time; After each failed retry, the delay time for the next retry is increased by a set multiple until the maximum backoff delay or the maximum number of retries is reached.
4. The transaction processing method according to claim 1, characterized in that, The process of initiating a fund operation instruction to the database employs an optimistic locking execution mechanism.
5. The transaction processing method according to claim 1, characterized in that, The execution of the compensation transaction for rollback specifically includes: Based on the transaction records, the original fund operations that have been successfully executed are identified; Generate a compensation operation instruction that is the opposite of the original fund operation logic; The compensation operation instruction is executed, and upon successful execution, the status of the transaction record is updated to "rollback completed"; wherein, the compensation operation instruction is designed to be an idempotent operation.
6. The transaction processing method according to claim 1, characterized in that, The step of marking the transaction record as failed also includes: The transaction number corresponding to the transaction record and the operation failure information are sent to the business system.
7. The transaction processing method according to claim 1, characterized in that, After obtaining the execution feedback of the fund operation instruction, the process also includes: If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to be successful, and the transaction number corresponding to the transaction record and the operation success information are sent to the business system.
8. A transaction processing system, characterized in that, The system includes: Transaction record creation module: In response to a fund operation request from the business system, it creates a transaction record with a globally unique transaction number and marks the status of the transaction record as "processing". Fund operation instruction issuance module: Used to issue fund operation instructions to the database based on fund operation requests; Operation failure reason classification module: used to obtain the execution feedback of the fund operation instruction. If the execution feedback indicates that the operation was unsuccessful, the fund operation is determined to have failed. Based on the execution feedback, the failure reason is determined and it is determined whether the failure reason is a retryable transient failure or a non-retryable permanent failure. Retry operation module: If the failure reason is a retryable transient failure, then initiate at least N retry operations to the database; wherein, each retry operation includes re-initiating the fund operation instruction to the database; if the retry is successful, mark the status of the transaction record as successful; if it still fails after executing N retry operations, then execute the rollback module. Rollback module: If the failure reason is a permanent failure that cannot be retried, or if the failure still occurs after N retries, the module executes the compensation transaction operation corresponding to the execution feedback of the fund operation to achieve rollback and marks the transaction record as a failure.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.