Method and device for guaranteeing consistency of distributed services in financial level, computer device and storage medium

Abstract

Embodiments of the present application disclose a financial-level distributed business consistency guarantee method and device, computer equipment and a storage medium. The method comprises: obtaining a verification request with an original transaction code; performing transaction verification according to the verification request, generating a verification result, and returning to a peripheral system; when the peripheral system does not receive a response, the response is unknown, or the peripheral system is abnormal, obtaining a correction request; querying a main transaction log according to the correction request; determining a processing flow according to the transaction state of the main transaction log and processing; and for a transaction with a successful transaction state but a wrong account on the business, the transaction is reversed. The method of the embodiments of the present application can guarantee the business consistency between systems and the data consistency within the system in the financial field.

Description

Technical Field

[0001] This invention relates to a method for ensuring business consistency, and more specifically to a financial-grade distributed business consistency assurance method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In the financial sector, particularly in financial systems employing microservices distributed architectures, ensuring data accuracy and consistency is an extremely critical challenge. This architecture often involves the aggregation of multiple downstream systems or services, such as channel layers, product layers, and new core systems. This complex business scenario leads to a series of problems:

[0003] First, business consistency is difficult to guarantee; because multiple systems or services are involved, communication and data exchange between these systems may experience delays, data loss, or errors, leading to inconsistencies in transaction states. Second, business states are difficult to manage; in a distributed environment, various services may be in different states, making unified management and monitoring of the entire business process difficult. Third, business monitoring and maintenance are challenging; due to the involvement of multiple systems and services, monitoring the entire business process becomes complex, making it difficult to identify and resolve problems in a timely manner. Finally, there is a lack of unified error protection capabilities; in a complex distributed environment, handling anomalies and errors becomes more difficult, lacking a unified mechanism to address these issues. Faced with these challenges, traditional ACID transactions are difficult to implement in a distributed environment.

[0004] Therefore, it is necessary to design a new method to ensure business consistency between systems and data consistency within systems in the financial sector. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a financial-grade distributed business consistency guarantee method, apparatus, computer equipment and storage medium.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a financial-grade distributed business consistency guarantee method, comprising:

[0007] Obtain a verification request containing the original transaction code;

[0008] The transaction is verified according to the verification request, the verification result is generated, and the result is returned to the external system.

[0009] When the peripheral system does not receive a response, the response is unknown, or an anomaly occurs in the peripheral system, a reversal request is obtained;

[0010] Query the main transaction flow based on the aforementioned reversal request;

[0011] The processing flow is determined based on the transaction status of the main transaction flow, and then the processing is carried out.

[0012] For transactions that are successful in status but are incorrect in business operations, the transactions shall be cancelled.

[0013] The further technical solution is as follows: For transactions whose transaction status is successful but are actually erroneous in business operations, after canceling the transaction, the solution further includes:

[0014] The aggregation service orchestrates the process of service calls and configures compensation and reversal services for each called service.

[0015] When an anomaly occurs, the driving state engine uses the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node, thus rolling back the transaction.

[0016] The further technical solution is as follows: the step of performing transaction verification based on the verification request, generating verification results, and returning them to the external system includes:

[0017] Query the original transaction code;

[0018] When the original transaction code exists, determine whether the subsystem corresponding to the original transaction code is a public subsystem;

[0019] If the subsystem corresponding to the original transaction code is a public subsystem, then the local verification method is invoked;

[0020] Determine if the original transaction serial number is empty;

[0021] If the original transaction serial number is empty, then query the main transaction serial number table based on the requester information in the verification request;

[0022] When the query result is not empty, the verification result is returned to the external system;

[0023] If the original transaction serial number is not empty, and the original transaction time is the current business date or the previous day, the main transaction serial number is queried based on the original transaction serial number, and a verification result is generated and returned to the external system; if the original transaction time is neither the current business date nor the previous day, the verification result is set to empty and the verification result is returned to the external system.

[0024] The further technical solution is as follows: the process of determining the processing flow based on the transaction status of the main transaction flow and performing the processing includes:

[0025] Determine whether the transaction status of the main transaction flow is unknown;

[0026] If the transaction status of the main transaction flow is unknown, check the basic services one by one, and according to the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, enter the end step; if the verification result is not failure or is not the first node, send a reversal MQ message to perform automatic reversal.

[0027] If the transaction status of the main transaction stream is not unknown, a reversal MQ message is sent to automatically reverse the transaction.

[0028] The further technical solution is as follows: after sending the reversal MQ message and performing automatic reversal, it also includes:

[0029] When the external system does not respond, the reverse transaction is verified. When the external system fails to respond, the reverse transaction is reversed again. When the external system responds successfully, the reverse request is processed asynchronously.

[0030] The further technical solution is as follows: When an anomaly occurs, the driving state engine uses the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node to roll back the transaction, including:

[0031] When the system is in a positive transaction phase, determine whether the positive transaction is an unknown transaction;

[0032] If the positive transaction is an unknown transaction, then the positive transaction will be automatically reversed.

[0033] Determine whether the correction has ended;

[0034] If the reversal is not completed, asynchronous compensation will be performed on the positive transaction;

[0035] When asynchronous compensation is not completed, manual intervention is used to handle the abnormality of the positive transaction.

[0036] The further technical solution is as follows: when asynchronous compensation is not completed, manual intervention is used to handle the anomalies of the positive transaction, including:

[0037] When asynchronous compensation is not completed, manual intervention is used to query abnormal transaction log records, correct abnormal transaction status, and initiate manual reversal for the positive transaction.

[0038] This invention also provides a financial-grade distributed business consistency guarantee device, comprising:

[0039] The verification request acquisition unit is used to acquire verification requests containing the original transaction code;

[0040] The verification unit is used to verify the transaction according to the verification request, generate the verification result, and return it to the external system;

[0041] The reversal request acquisition unit is used to acquire a reversal request when the peripheral system does not receive a response, the response is unknown, or an anomaly occurs in the peripheral system;

[0042] The query unit is used to query the main transaction flow based on the reversal request;

[0043] The reversal processing unit is used to determine the processing flow based on the transaction status of the main transaction flow and to perform the processing.

[0044] The cancellation unit is used to cancel transactions that are successful in terms of transaction status but are incorrect in terms of business operations.

[0045] The present invention also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described method.

[0046] The present invention also provides a storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0047] The beneficial effects of this invention compared with the prior art are as follows: This invention verifies transactions for verification requests, and performs reversal processing based on the transaction status when the external system does not receive a response, the response is unknown, or the external system experiences an anomaly. Furthermore, it cancels transactions that are successful in status but are incorrect in business operations, thereby ensuring business consistency between systems and data consistency within systems in the financial field.

[0048] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0049] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 A schematic diagram illustrating an application scenario of the financial-grade distributed business consistency guarantee method provided in an embodiment of the present invention;

[0051] Figure 2 A flowchart illustrating the financial-grade distributed business consistency guarantee method provided in this embodiment of the invention;

[0052] Figure 3 A flowchart illustrating a financial-grade distributed business consistency guarantee method provided in another embodiment of the present invention;

[0053] Figure 4 This is a system state transition diagram provided in an embodiment of the present invention;

[0054] Figure 5 This is a system internal rectified state transition diagram provided in an embodiment of the present invention;

[0055] Figure 6 This is a transition diagram of the reverse state of a canceled transaction provided in an embodiment of the present invention;

[0056] Figure 7 This is the overall architecture of the Saga transaction compensation model provided in this embodiment of the invention;

[0057] Figure 8 This is a schematic representation of the transaction flow provided in an embodiment of the present invention;

[0058] Figure 9 A schematic block diagram of a financial-grade distributed business consistency guarantee device provided in an embodiment of the present invention;

[0059] Figure 10 A schematic block diagram of a financial-grade distributed business consistency guarantee device provided in another embodiment of the present invention;

[0060] Figure 11 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0063] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0064] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0065] Please see Figure 1 and Figure 2 , Figure 1 This is a schematic diagram illustrating an application scenario of the financial-grade distributed business consistency guarantee method provided in an embodiment of the present invention. Figure 2 This is a schematic flowchart illustrating a financial-grade distributed business consistency guarantee method provided in an embodiment of the present invention. This method is applied to a server that interacts with external systems. Based on requests from the external systems, the server provides inter-system reversal, transaction cancellation, and transaction verification mechanisms to resolve business consistency issues between systems. Utilizing the Saga transaction compensation model, it designs solutions such as automatic reversal, scheduled task compensation, and manual intervention to address data inconsistency issues within the system group.

[0066] Figure 2 This is a flowchart illustrating the financial-grade distributed business consistency guarantee method provided in an embodiment of the present invention. Figure 2 As shown, the method includes the following steps S110 to S160.

[0067] S110. Obtain a verification request with the original transaction code.

[0068] The system provides a historical transaction status query function, and its operation follows the dominant principles of the external system. In the event of unknown responses, no response received from the core system, internal logic anomalies, or other scenarios, the system chooses to verify the original transaction, and the external system performs further processing based on the specific circumstances.

[0069] S120. Perform transaction verification according to the verification request, generate verification results, and return them to the external system.

[0070] In one embodiment, step S120 described above may include steps S121 to S128.

[0071] S121. Query the original transaction code.

[0072] In this embodiment, the original transaction code is queried through the system database or storage structure to ensure that the system can accurately find the required original transaction information.

[0073] S122. When the original transaction code exists, determine whether the subsystem corresponding to the original transaction code is a public subsystem.

[0074] In this embodiment, it checks whether the subsystem corresponding to the original transaction code belongs to the public system; it distinguishes between the verification process for public subsystems and non-public subsystems to adapt to different types of transactions.

[0075] S123. If the subsystem corresponding to the original transaction code is a public subsystem, then the local verification method is invoked.

[0076] In this embodiment, if the subsystem corresponding to the original transaction code is a public subsystem, the local verification method is invoked for verification; performing local verification within the public subsystem improves efficiency and accuracy.

[0077] S124. Determine if the original transaction serial number is empty.

[0078] In this embodiment, it is checked whether the original transaction serial number exists to determine whether additional serial number information is needed to locate the original transaction.

[0079] S125. If the original transaction serial number is empty, query the main transaction serial number table based on the requester information in the verification request.

[0080] In this embodiment, the main transaction log table is queried based on the requester information in the verification request to obtain the main transaction log number; this ensures that the correct main transaction log information related to the request can be found.

[0081] S126. When the query result is not empty, return the verification result to the external system.

[0082] In this embodiment, the verification results are returned to the peripheral system so that the peripheral system can obtain the verification results in a timely manner and perform subsequent processing.

[0083] S127. If the original transaction serial number is not empty, when the original transaction time is the current business date or the previous day, query the main transaction serial number based on the original transaction serial number, generate the verification result, and return the verification result to the external system; when the original transaction time is neither the current business date nor the previous day, set the verification result to empty and return the verification result to the external system.

[0084] In this embodiment, verification results are generated based on the original transaction serial number and time conditions. Accurate verification results are generated based on different conditions, thereby improving the accuracy and practicality of verification.

[0085] S128. If the subsystem corresponding to the original transaction code is not a public subsystem, then route to the specific subsystem, initiate an internal verification request, and execute step S124.

[0086] In this embodiment, if the subsystem corresponding to the original transaction code is not a public subsystem, the request is routed to the specific subsystem and an internal verification request is initiated; this ensures that internal verification can be performed correctly in a non-public subsystem, guaranteeing the comprehensiveness and accuracy of the verification.

[0087] In this embodiment, the peripheral system initiates a verification request to the unified verification aggregation service (APLAT70001) provided by the server using the original transaction code (service route), the three elements of the requester, and the main transaction serial number (if any). After receiving the original transaction code, the server first queries the transaction code table, then performs service routing, initiates a transaction verification request to the target basic service, and returns the verification result to the peripheral system. If the original transaction does not exist, it is identified in the response message by the original transaction status (orgnlTransStat=NE). In the response judgment process: if the verified transaction has no response or returns unknown, it is recommended to initiate verification again; otherwise, further judgment and processing are performed based on the original transaction status in the response message body: if the original transaction status is UN, it is recommended to initiate verification again after a period of time. If the original transaction status is NE, inter-system reversal is performed.

[0088] S130. When the peripheral system does not receive a response, the response is unknown, or an anomaly occurs in the peripheral system, a reversal request is obtained.

[0089] In this embodiment, the inter-system reversal is used when the external system does not receive a response, the response is unknown, or an anomaly occurs in the external system, but it is desired to offset the effects of the original transaction and roll it back to its previous state. In most cases, this operation needs to be used in conjunction with transaction verification.

[0090] In this embodiment, a reversal request is obtained when an external system malfunctions, fails to receive a response, or provides an unknown response. This step ensures that the external system is indeed in an uncertain state when the process starts and requires a reversal to ensure consistency. This avoids other errors caused by uncertain transaction states due to external system malfunctions.

[0091] S140. Query the main transaction flow according to the reversal request.

[0092] In this embodiment, based on the reversal request, the main transaction log is queried to find the relevant transaction records. This step is to determine the status of the transaction and obtain preliminary information for the processing flow. It ensures that the process unfolds based on accurate transaction information, providing a foundation for subsequent judgments and operations.

[0093] S150. Determine the processing flow based on the transaction status of the main transaction flow, and then process it.

[0094] In this embodiment, the processing flow may differ under different states. Based on the actual transaction state, different processing paths can be flexibly selected to improve the accuracy and reliability of the process.

[0095] In this embodiment, after receiving a reversal request from an external system, the main transaction log is first queried. If no transaction log is found or the transaction status is failed, the process terminates; otherwise, proceed to the next step. If the transaction status is unknown, the underlying services need to be verified one by one, and the subsequent processing flow is comprehensively judged based on the node position of the erroneous underlying service in the process: if the verification result is a failure and it is the first node, the process ends; otherwise, a reversal MQ message is sent to start the automatic reversal process. If the transaction status is successful, a reversal MQ message is sent directly to start the automatic reversal process. In the response judgment process, if there is no response, it is recommended to initiate verification for the reversal transaction; if the response clearly fails, it is recommended to initiate the inter-system reversal again; if the response clearly succeeds, it means that the system has received this reversal request and is processing it asynchronously.

[0096] In one embodiment, step S150 described above may include steps S151 to S154.

[0097] S151. Determine whether the transaction status of the main transaction flow is unknown.

[0098] In this embodiment, it is determined whether further verification of the transaction status is needed to avoid blind operation and ensure that the process only performs complex verification and reversal when necessary.

[0099] S152. If the transaction status of the main transaction flow is unknown, check the basic services one by one, and according to the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, enter the end step; if the verification result is not failure or is not the first node, send a reversal MQ message to perform automatic reversal, and execute step S154.

[0100] In this embodiment, if the transaction status is unknown, the underlying services need to be verified one by one, and the subsequent operation is determined based on the node position of the erroneous underlying service in the process. If the verification result is a failure and it is the first node, the process ends; otherwise, a reversal MQ message is sent for automatic reversal. By verifying the underlying services, the specific problem can be identified, and whether a reversal is necessary can be determined based on the severity of the problem.

[0101] S153. If the transaction status of the main transaction flow is not unknown, a reversal MQ message is sent to perform automatic reversal.

[0102] If the transaction status is not unknown, it means the transaction has either succeeded or failed. In this case, a reversal message is sent directly to the message queue (MQ) to initiate the automatic reversal process; this avoids unnecessary verification and directly performs the reversal operation, improving efficiency.

[0103] S154. When the external system does not respond, verify the reverse transaction. When the external system fails to respond, perform the inter-system reverse transaction again. When the external system responds successfully, process the reverse request asynchronously.

[0104] If the external system does not respond, verify the reversal transaction. If the external system fails to respond, attempt the inter-system reversal again. If the response is successful, it indicates that the system has received the reversal request and is processing it asynchronously; ensure that the reversal request is successfully processed, and take appropriate action based on the response from the external system to prevent unnecessary errors or duplicate operations.

[0105] Specifically, continuously check the response status of external systems to determine whether there is a response, a failed response, or a successful response. If an external system does not provide any response within a predetermined time, initiate an investigation procedure to check whether the transaction request has been received and processed, or whether it exists in a queue awaiting processing. Investigation may include querying logs, databases, or using specialized monitoring tools to confirm the status of the reversal transaction. If the external system returns a failure response, analyze the cause of the failure and decide whether to immediately retry the reversal transaction. Before retrying, ensure that the system state and data environment are suitable for another attempt. If the retry still fails, a retry limit can be set, and an alarm or notification can be triggered if the limit is exceeded. When a successful response is received from an external system, the reversal request is processed asynchronously to ensure that the current business process is not blocked. Asynchronous processing may involve queuing the task in a background processing queue and processing it through a dedicated background service to reduce the impact on the front end or other interactive services. Throughout the entire process, transparency and detailed logging should be maintained, including each step of the operation, system response, and final result. Logs will help with future analysis and auditing to improve processing procedures and response strategies. In this way, it can be ensured that even if external systems fail or respond unstably, reversal transactions can be effectively managed and resolved, thus guaranteeing business continuity and data consistency.

[0106] In this embodiment, the original transaction is first verified. If the original transaction does not exist, a new main transaction is inserted. If the original transaction exists, and if it is not already settled daily, its status is successful or unknown, it is not in the process of being cancelled, and there is no system reversal acceptance record, then an asynchronous reversal request acceptance table can be registered. If the original transaction is successful, an asynchronous reversal MQ is initiated, and the main transaction process information is returned after the reversal acceptance is successful. If the original transaction is unsuccessful, the main transaction process information is returned directly after the reversal acceptance is successful.

[0107] Overall, this process ensures the accuracy and reliability of reversal operations by gradually judging and verifying the transaction status, thereby minimizing transaction inconsistencies or errors caused by external system problems.

[0108] S160. For transactions that are successful in status but are incorrect in business operations, the transactions shall be cancelled.

[0109] In this embodiment, the original transaction is first verified. If the original transaction exists and its status is successful and it is not cancelled the next day, the business self-processing cancellation process is carried out, and the status of the original main transaction is modified.

[0110] Specifically, in the response cancellation judgment process, the first consideration should be the case where no response has been received. In this situation, it is recommended that the external system initiate a verification transaction and determine the next steps based on the verification results, or directly trigger an inter-system reversal operation.

[0111] If a response has been received, the transaction status needs to be determined first:

[0112] If the transaction status is marked as successful, it means the transaction has been completed smoothly. In this case, the external system can choose whether to initiate an inter-system reversal based on actual needs.

[0113] If the transaction status is marked as failed, it means that the transaction processing failed. In this case, the reason for the failure can be further determined based on the response code (respCode).

[0114] If the transaction status is marked as unknown, it indicates a system anomaly. In this case, the system will automatically initiate a reversal. It is recommended that external systems investigate after a period of time and take further action based on the investigation results.

[0115] The aforementioned financial-grade distributed business consistency guarantee method verifies transactions for verification requests, and performs reversal processing based on transaction status when the external system does not receive a response, the response is unknown, or an anomaly occurs in the external system. Furthermore, it cancels transactions that are successful in status but are incorrect in business operations, thereby ensuring business consistency between systems and data consistency within the financial sector.

[0116] Figure 3 This is a flowchart illustrating a financial-grade distributed business consistency guarantee method according to another embodiment of the present invention. Figure 3 As shown, the financial-grade distributed business consistency guarantee method in this embodiment includes steps S210-S280. Steps S210-S260 are similar to steps S110-S160 in the previous embodiment and will not be described again here. The following details the additional steps S270-S280 in this embodiment.

[0117] S270, the aggregation service orchestrates the service call process and configures the compensation and reversal service for each called service.

[0118] In this embodiment, a process engine is defined, or an existing process engine is used, to orchestrate and combine the service calls to be executed according to business logic, forming a complete process. This process can be linear, or it can include branching and parallel execution. Within the process, each service to be executed is called. These services can be internal services, external services, or interfaces to other subsystems. For each service call, a corresponding compensation and reversal service is configured. These services are typically used to roll back or correct service calls in case of exceptions, ensuring data consistency and integrity. During the service call process, the occurrence of exceptions is monitored. When an exception occurs, the corresponding compensation or reversal process is triggered according to the configured compensation and reversal service for processing. Throughout the entire process, transaction states need to be managed to ensure transaction consistency and integrity. This can be achieved through a state machine or a transaction state table.

[0119] Configuring compensation and reversal services can handle anomalies promptly, improving the system's fault tolerance and reliability, and reducing data loss or inconsistency caused by abnormal situations. Using a process engine can abstract and organize complex business processes, simplifying the work of developers and reducing the cost of system development and maintenance. By configuring compensation and reversal services, different situations can be handled flexibly, making the system more adaptable and flexible, and able to cope with diverse business needs and abnormal situations.

[0120] S280. When an exception occurs, the driving state engine uses the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node and roll back the transaction.

[0121] In one embodiment, step S280 described above may include steps S281 to S285.

[0122] S281. When the system is in a positive transaction, determine whether the positive transaction is an unknown transaction;

[0123] S282. If the positive transaction is an unknown transaction, then the positive transaction is automatically reversed.

[0124] S283. Determine whether the correction has ended;

[0125] S284. If the reversal is not completed, then asynchronous compensation shall be performed on the positive transaction;

[0126] S285. When asynchronous compensation is not completed, manual intervention is used to handle the abnormality of the positive transaction.

[0127] Specifically, when asynchronous compensation is not completed, manual intervention is used to query abnormal transaction log records, correct abnormal transaction status, and initiate manual reversal for the positive transaction.

[0128] In this embodiment, the Saga transaction compensation model described above is as follows: Figure 7 As shown, the Saga transaction solution is built on the DAP process engine and implemented using a state machine. Its mechanism involves orchestrating service call flows through an aggregation service and configuring compensation and reversal services for each call. When an exception occurs, the state engine is driven to reverse the execution of the compensation nodes corresponding to successfully executed nodes to roll back the transaction.

[0129] The overall architecture of the Saga transaction compensation model consists of four modular components:

[0130] Transaction initiator (aggregation subsystem): Responsible for global transaction orchestration and registration, receiving requests from external transactions, and initiating calls to sub-transactions. Based on the process model, it registers the master-sub-transaction relationship and updates the transaction status. If execution fails, it automatically initiates a reversal process.

[0131] Transaction participants (basic subsystem): manage local transactions within the global transaction, responsible for data modification, commit, rollback, and compensation operations. They are the specific business executors of sub-transactions.

[0132] Asynchronous Compensation (Batch Subsystem): Responsible for asynchronous transaction compensation services, determining the appropriate processing mechanism based on transaction status and information, such as sending reversal messages or alarms. This generally includes: periodically or in real-time monitoring of asynchronous transaction status, including success, failure, or other abnormal states; identifying abnormal transactions: identifying abnormal transactions based on monitored transaction status, such as failed transactions due to network problems, system failures, or business logic errors; determining the processing mechanism: deciding on the appropriate processing mechanism based on the specific circumstances of the abnormal transaction. If the problem can be resolved automatically through reversal, a reversal message can be sent to the relevant system; if manual intervention or other specific processing is required, an alarm may be triggered or relevant personnel notified; executing the processing: performing the corresponding operation according to the determined processing mechanism. When sending a reversal message, the message is sent to the corresponding system or queue; when an alarm is triggered, relevant personnel are notified to handle the situation; monitoring processing results: monitoring the results of processing operations to ensure successful processing or timely follow-up on processing failures, and recording processing logs for subsequent review and analysis; providing status updates: updating the status of asynchronous transactions based on the processing results, marking them as processed or failed for subsequent tracking and management.

[0133] Operations Control Console (Operations Subsystem): Provides a manual intervention entry point, supporting operations such as querying abnormal transactions, correcting status, and manually reversing them.

[0134] Overall, this Saga transaction compensation model uses a main transaction log, a service call log, and sub-transaction logs to register transaction information and relationships. When a positive transaction fails, it is reversed using the main transaction number, including querying service call information and executing the reversal process. Reversing a transaction also follows a similar automatic reversal process, but focuses on specific information changes.

[0135] Scheduled tasks are used to scan transactions that have not reached an eventual consistency state, send reversal messages, and trigger an automatic reversal process. If the maximum number of reversals is reached, an alarm message will be sent and recorded in the error log, requesting manual intervention. The operations backend provides functions for querying abnormal transaction records and manual processing.

[0136] Specifically, the main transaction log table records the transaction log of the first service. Idempotent control is achieved through the primary key TRANS_SRL_NO and a unique index: the requester's transaction number + the requester's identifier, used to track the original transaction information and complete the reversal compensation mechanism. That is, when a system anomaly occurs, the main transaction number is used to track the original transaction information and complete the reversal compensation mechanism. The transaction status `transStat` indicates the current transaction processing result of a certain transaction. This attribute is uniformly assigned a value on the platform side, and the field can take one of three values: failed, successful, or unknown. Unknown scenarios include: no response from the basic service or an explicit return of "unknown," an explicit return of failure from a service other than the first one, and failure to update the transaction log.

[0137] The service call log table records calls made by aggregated services to basic services. It uses a main stream ID, service call log number, and sub-stream IDs for association, facilitating a reversal process in case of system anomalies. When a system anomaly occurs and the reversal process begins, the main stream ID is used to identify all successful sub-transaction IDs associated with the original transaction that require compensation, and subsequent reversal compensation is then performed.

[0138] The sub-flow table is used to record the transaction flow of basic services. It achieves idempotent control through the primary key TRANS_SRL_NO and a unique index, and drives process reversal by combining flow status, reversal status, and transaction status.

[0139] The automatic reversal process for positive transactions includes querying the service call log table, judging based on the execution status of each branch transaction log, processing the successfully executed sub-transactions in reverse order, and updating the relevant information in the main transaction log.

[0140] Specifically, when an anomaly occurs within the main transaction system, the system sends an asynchronous MQ message for reversal. Upon receiving the message, the consumer executes the core logic of automatic reversal: First, it queries the service call log table to check the execution status of each branch transaction log. If an anomaly is found and the branch is the first node, and verification fails, the transaction status and flow status of the main transaction log are changed to failure, and the process terminates; otherwise, the automatic reversal process continues. If the current branch is the last node and verification succeeds, and it is not an inter-system reversal, the transaction status and flow status of the flow are changed to success, and the process ends; otherwise, the automatic reversal process continues. Next, successfully executed sub-transactions are processed in reverse order, calling the corresponding reversal base service to complete the reversal logic of the sub-transaction and updating the sub-transaction flow. This continues until all base service reversals are completed, and then the transaction status, flow status, number of reversals, and number of reversal nodes of the main transaction flow are updated. The transaction log table is as follows: Figure 8 As shown.

[0141] The aforementioned automatic reversal process is an operational procedure used to correct trading errors or abnormal situations. It typically includes the following steps:

[0142] Retrieve the list of service call pipelines that need to be reversed, determine the position of the underlying service, and if the underlying service position is the first one, query the status of the underlying service. If the status of the underlying service is successful, update the status of the main transaction pipeline table, for example, change the original transaction's forward status from pending confirmation to failed, or change the original transaction's transaction status from unknown to failed, and then proceed with MQ consumption confirmation. If the status of the underlying service is failed, determine whether the forward status is pending confirmation and the reverse status is empty or failed. If so, change the original transaction's reverse status to in progress, increment the reverse count, and retrieve the list of service call pipelines with sub-transaction statuses of success / in progress. The process involves several steps: First, determine if there is a next record. If not, update the main transaction log's status. For example, change the original transaction's forward status from pending confirmation to failure, the original transaction's reversal status from in progress to success, the original transaction's transaction status from unknown to failure, and the reversal transaction from in progress to success. Then, proceed with MQ consumption confirmation. If there is a next record, verify the sub-transaction status. If the sub-transaction status is in progress, check the basic service status. If the basic service status is in progress, determine if the reversal count has reached the limit. If not, create a new reversal MQ and perform MQ consumption. Fee confirmation; when the limit is reached, MQ consumption confirmation is performed; when the sub-transaction status is successful, the reversal service of the basic service is called; when the execution is successful, the self-flow status of the service call flow is updated, and the service call flow list with the sub-transaction status of success / execution is retrieved; when the execution fails, the flow status of the main transaction flow table is updated, and the reversal count is checked to see if the limit has been reached; if the sub-transaction status is failed, the self-flow status of the service call flow is updated; when the status of the basic service is failed, the self-flow status of the service call flow is updated; when the basic service position is the last, verification is performed. The basic service status is determined by checking if it is successful. If successful, it checks if the transaction is between systems. If not, it updates the main transaction log status, for example, changing the original transaction's positive status from pending confirmation to successful, or changing the transaction status from unknown to successful, and then proceeding with MQ consumption confirmation. If unsuccessful, it checks if the positive status is pending confirmation and if the reversal status is empty or failed. When the basic service position is neither the first nor the last, it retrieves the original trading platform's transaction log and checks if the positive status is pending confirmation and if the reversal status is empty or failed. The overall inter-system state transition diagram is shown below. Figure 4 As shown, the transition between the positive and negative states within the system is as follows: Figure 5 As shown.

[0143] The process of canceling and reversing a transaction is similar to the automatic reversal process of a positive transaction, but it is necessary to pay attention to the changes in three types of transaction information: the status changes of the original transaction (the transaction that was successfully executed and needs to be canceled), the canceled transaction, and the reversal transaction (cancellation status, transaction status, reversal status, transaction status, and number of reversals).

[0144] The specific process is as follows: Obtain the list of service calls to be revoked, determine the position of the underlying service, and if the underlying service is the first one, query its status. If the underlying service status is successful, update the status of the main transaction log table. For example, update the revocation status of the original revoked transaction from "in execution" to "failed," the transaction status of the original revoked transaction from "unknown" to "successful," and the forward status of the revoked transaction from "pending confirmation" to "failed." Change the transaction status of the revoked transaction from "unknown" to "failed." Next, perform MQ consumption confirmation. If the underlying service status is "failed," determine if the forward status is "pending confirmation" and the forward status is empty or failed. If so, change the original transaction revocation status to "in execution," increment the revocation count, and obtain the service calls with sub-transaction statuses of success / in execution. The process involves calling the transaction log list; determining if there is a next record; if not, updating the transaction status of the main transaction log table, such as changing the cancellation status of the original cancelled transaction from unknown to failed, changing the transaction status of the original cancelled transaction from unknown to successful, changing the forward status of the cancelled transaction from pending confirmation to failed, changing the transaction status of the cancelled transaction from unknown to failed, changing the reversal status of the cancelled transaction from in progress to successful, and changing the status of the reversal transaction's transaction log from in progress to successful; then proceeding with MQ consumption confirmation; if there is a next record, verifying the sub-transaction status; if the sub-transaction status is in progress, checking the basic service status; if the basic service status is in progress, determining if the reversal count has reached the limit; if not, then... Create a new reversal MQ and confirm MQ consumption. When the limit is reached, confirm MQ consumption. When the sub-transaction status is successful, call the basic service's reversal service. If successful, update the self-flowing status of the service call log and retrieve the service call log list where the sub-transaction status is successful or in progress. If failure occurs, update the log status of the main transaction log table, for example, update the reversal status of the reversal transaction from in progress to failed, and update the status of the reversal transaction log from in progress to failed. Also, check if the reversal count has reached the limit. If the sub-transaction status is failed, update the self-flowing status of the service call log. When the basic service status is failed, update the self-flowing status of the service call log. When the basic service position is the most... In the next step, check the status of the basic service and determine if it is successful. If successful, determine if it is an inter-system transaction. If not, update the status of the main transaction log. For example, change the cancellation status of the original transaction to successful from "in execution" and change the transaction status from unknown to failed. Update the positive status of the cancelled transaction from "pending confirmation" to successful and the transaction status from unknown to successful. Then, perform MQ consumption confirmation. If unsuccessful, check if the positive status is "pending confirmation" and the reversal status is empty or failed. If the basic service position is neither the first nor the last, retrieve the original transaction platform's transaction log and check if the positive status is "pending confirmation" and the reversal status is empty or failed.The specific conversion diagram for canceling a transaction that is in a positive state is shown below; Figure 6 As shown.

[0145] The scheduled task is used to scan for main transaction flows that have not reached eventual consistency. If the number of automatic reversals reaches the limit, an alarm message is sent and the error flow is recorded, requiring manual intervention.

[0146] Based on the time of the last scan, calculate the data range for this scan, and combine it with the transaction status (unknown UN). Scan out the main transaction flows that have not reached final consistency, and perform the following judgment and processing: If the number of automatic reversals reaches the limit, send an alarm message to the operation and maintenance side, register the key transaction information in the error flow table, and request manual intervention; otherwise, proceed to the following process: Simultaneously send a reversal MQ message and go through the automatic reversal process (if the final state is still not reached in the process, an alarm needs to be sent and the error flow needs to be registered).

[0147] The specific process is as follows:

[0148] The system retrieves the last successful scan time, scans the main transaction log for transactions with an unknown status some time ago, and checks if there is a next record. If not, it records the successful scan time. If there is a next record, it checks the error log to see if it exists. If it exists, it scans the main transaction log for transactions with an unknown status some time ago. If it doesn't exist, it retrieves the number of reversals and checks if the reversal count has reached the limit. If not, it initiates a reversal service, sending a message to the MQ (Message Queue) for one-step consumption, which automatically follows the reversal process. It checks if the reversal is successful. If successful, it scans the main transaction log for transactions with an unknown status some time ago. If unsuccessful, it sends an alarm and records it in the error log, then scans the main transaction log for transactions with an unknown status some time ago. If the number of reversals has reached the limit, it sends an alarm and records it in the error log.

[0149] The operations backend provides functions such as querying abnormal transaction records, correcting abnormal transaction status, and manual reversal to handle abnormal transactions that cannot be processed automatically by the system.

[0150] In the above process, when an external system needs to perform a positive transaction or cancel a transaction, it will send a request message. The server's core system group will then perform the positive or negative transaction and send feedback to the external system for response analysis. If the response is success or failure, the transaction ends. If the response is no response or unknown, an inter-system reversal or verification transaction will be performed. When a verification transaction is required, the external system initiates the verification. After receiving the verification request message, the server performs the verification transaction and sends feedback to the external system. If the verification transaction receives no response or returns unknown, the verification will be initiated again. If the response is not no response or unknown, the verification will continue. When the return value is unknown, the original transaction status is checked. If it is failed, does not exist, or is successful, the transaction ends. If it is unknown or does not exist, the verification is initiated again. In extreme cases, when the verification is initiated, the upper level receives the original request. In this case, it is recommended to re-initiate the verification after a period of time. For inter-system reversal, when an external system initiates a reversal request message, the server's core system group performs inter-system reversal and feeds back to the external system to check the original transaction status. If it is failed, the transaction ends. If it is unknown or is successful, the instruction is received and processed asynchronously. This step is to register the received instruction and initiate the automatic reversal process asynchronously.

[0151] The aforementioned financial-grade distributed business consistency guarantee method provides a solution to the business consistency problem in the financial field within a distributed environment. This includes methods such as transaction verification, transaction reversal, and inter-system transaction reversal to address the challenges of business consistency between systems. Utilizing Saga long-transaction theory and combining core functionalities such as microservice orchestration and transaction pipeline status, it provides an eventual data consistency solution. Peripheral systems, by adopting this method, can determine and control transaction consistency issues between different systems. The core server system group, by inheriting the capabilities provided by this solution, solves the data consistency problem between systems in a distributed environment. This allows developers of each system to focus more on the development and implementation of business logic without worrying about data consistency issues in the event of system anomalies. This not only meets the business consistency requirements in distributed scenarios in the financial field but also simplifies the design and development of core financial systems.

[0152] Figure 9 This is a schematic block diagram of a financial-grade distributed business consistency guarantee device 300 provided in an embodiment of the present invention. Figure 9 As shown, corresponding to the above-described financial-grade distributed business consistency guarantee method, the present invention also provides a financial-grade distributed business consistency guarantee device 300. This financial-grade distributed business consistency guarantee device 300 includes a unit for executing the above-described financial-grade distributed business consistency guarantee method, and the device can be configured in a server. Specifically, please refer to... Figure 9The financial-grade distributed business consistency assurance device 300 includes a verification request acquisition unit 301, a verification unit 302, a reversal request acquisition unit 303, a query unit 304, a reversal processing unit 305, and a cancellation unit 306.

[0153] Verification request acquisition unit 301 is used to acquire verification requests with the original transaction code; verification unit 302 is used to perform transaction verification according to the verification request, generate verification results, and return them to the external system; reversal request acquisition unit 303 is used to acquire reversal requests when the external system does not receive a response, the response is unknown, or an anomaly occurs in the external system; query unit 304 is used to query the main transaction flow according to the reversal request; reversal processing unit 305 is used to determine the processing flow according to the transaction status of the main transaction flow and perform the processing; cancellation unit 306 is used to cancel transactions whose transaction status is successful but are incorrect in business operations.

[0154] In one embodiment, the verification unit 302 includes:

[0155] The system comprises the following sub-units: a transaction code query sub-unit for querying the original transaction code; a subsystem judgment sub-unit for determining whether the subsystem corresponding to the original transaction code is a public subsystem when the original transaction code exists; a local call sub-unit for calling the local verification method if the subsystem corresponding to the original transaction code is a public subsystem; a serial number judgment sub-unit for determining whether the original transaction serial number is empty; a serial number table query sub-unit for querying the main transaction serial number table based on the requester information in the verification request if the original transaction serial number is empty; a return sub-unit for returning the verification result to the external system when the query result is not empty; and a verification result generation sub-unit for querying the main transaction serial number table based on the original transaction serial number and generating a verification result when the original transaction time is the current business date or the previous day, and returning the verification result to the external system when the original transaction time is neither the current business date nor the previous day; and setting the verification result to empty and returning the verification result to the external system when the original transaction time is neither the current business date nor the previous day.

[0156] In one embodiment, the correction processing unit 305 includes:

[0157] The system includes a status judgment subunit, used to determine whether the transaction status of the main transaction flow is unknown; a line-by-line verification subunit, used to verify the basic services line by line if the transaction status of the main transaction flow is unknown, and based on the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, proceeding to the end step; if the verification result is not failure or it is not the first node, a reversal MQ message is sent for automatic reversal; a sending subunit, used to send a reversal MQ message for automatic reversal if the transaction status of the main transaction flow is not unknown; and an asynchronous processing subunit, used to verify the reversal transaction when there is no response from the external system, to perform inter-system reversal again when the external system response fails, and to process the reversal request asynchronously when the external system response is successful.

[0158] Figure 10 This is a schematic block diagram of a financial-grade distributed business consistency guarantee device 300 provided in another embodiment of the present invention. Figure 10 As shown, the financial-grade distributed business consistency guarantee device 300 in this embodiment is based on the above embodiment with the addition of a configuration unit 307 and a rollback unit 308.

[0159] Configuration unit 307 is used to orchestrate the service call process of the aggregation service and configure the compensation and reversal service for each called service; rollback unit 308 is used to drive the state engine when an exception occurs, and use the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node to roll back the transaction.

[0160] In one embodiment, the rollback unit 308 includes:

[0161] The system includes a transaction judgment subunit, used to determine whether a positive transaction is an unknown transaction when the system is in the process of making a positive transaction; an automatic reversal subunit, used to automatically reverse a positive transaction if it is an unknown transaction; an end judgment subunit, used to determine whether the reversal has ended; an asynchronous compensation subunit, used to asynchronously compensate a positive transaction if the reversal has not ended; and a manual intervention subunit, used to manually handle the positive transaction when asynchronous compensation has not been completed.

[0162] In one embodiment, the manual intervention subunit is used to manually query the abnormal transaction log records, correct the abnormal transaction status, and initiate manual reversal of the positive transaction when asynchronous compensation is not completed.

[0163] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned financial-grade distributed business consistency guarantee device 300 and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0164] The aforementioned financial-grade distributed business consistency guarantee device 300 can be implemented as a computer program, which can, for example... Figure 11 It runs on the computer device shown.

[0165] Please see Figure 11 , Figure 11 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0166] See Figure 11 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0167] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a financial-grade distributed business consistency guarantee method.

[0168] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0169] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a financial-grade distributed business consistency guarantee method.

[0170] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0171] The processor 502 is used to run a computer program 5032 stored in the memory to perform the following steps:

[0172] Obtain a verification request with the original transaction code; verify the transaction according to the verification request, generate a verification result, and return it to the external system; when the external system does not receive a response, the response is unknown, or an anomaly occurs in the external system, obtain a reversal request; query the main transaction log according to the reversal request; determine the processing flow based on the transaction status of the main transaction log and process it; for transactions with a successful transaction status but incorrect accounting in business terms, cancel the transaction.

[0173] In one embodiment, after performing the transaction cancellation step for a transaction whose transaction status is successful but whose business operation is incorrect, the processor 502 further performs the following steps:

[0174] The aggregation service orchestrates the service call process and configures the compensation and reversal service for each called service. When an exception occurs, the state engine is driven to use the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node to roll back the transaction.

[0175] In one embodiment, when the processor 502 performs the step of verifying the transaction according to the verification request, generating the verification result, and returning it to the peripheral system, it specifically implements the following steps:

[0176] The system queries the original transaction code. If the original transaction code exists, it determines whether the subsystem corresponding to the original transaction code is a public subsystem. If the subsystem corresponding to the original transaction code is a public subsystem, the local verification method is invoked. It then determines whether the original transaction serial number is empty. If the original transaction serial number is empty, the main transaction serial number is queried based on the requester information in the verification request. If the query result is not empty, the verification result is returned to the external system. If the original transaction serial number is not empty, and the original transaction time is the current business date or the previous day, the main transaction serial number is queried based on the original transaction serial number, and a verification result is generated and returned to the external system. If the original transaction time is neither the current business date nor the previous day, the verification result is set to empty, and the verification result is returned to the external system.

[0177] In one embodiment, when the processor 502 implements the process of determining the processing flow based on the transaction status of the main transaction stream and performing the processing steps, it specifically implements the following steps:

[0178] Determine whether the transaction status of the main transaction flow is unknown; if the transaction status of the main transaction flow is unknown, verify each basic service, and according to the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, proceed to the end step; if the verification result is not failure or is not the first node, send a reversal MQ message to perform automatic reversal; if the transaction status of the main transaction flow is not unknown, send a reversal MQ message to perform automatic reversal.

[0179] In one embodiment, after implementing the step of sending the reversal MQ message and performing the automatic reversal, the processor 502 further implements the following steps:

[0180] When the external system does not respond, the reverse transaction is verified. When the external system fails to respond, the reverse transaction is reversed again. When the external system responds successfully, the reverse request is processed asynchronously.

[0181] In one embodiment, when the processor 502 implements the step of driving the state engine when an exception occurs and using the Saga transaction compensation model to reverse the transaction rollback of the compensation node corresponding to the successfully executed node, the specific implementation steps are as follows:

[0182] When the system is in a positive transaction, it determines whether the positive transaction is an unknown transaction; if the positive transaction is an unknown transaction, it automatically reverses the positive transaction; it then determines whether the reversal is complete; if the reversal is not complete, it performs asynchronous compensation for the positive transaction; if the asynchronous compensation is not completed, it uses manual intervention to handle the anomaly of the positive transaction.

[0183] In one embodiment, when the processor 502 implements the step of manually intervening to handle the abnormality of the positive transaction when asynchronous compensation is not completed, the specific steps are as follows:

[0184] When asynchronous compensation is not completed, manual intervention is used to query abnormal transaction log records, correct abnormal transaction status, and initiate manual reversal for the positive transaction.

[0185] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0186] It will be understood by those skilled in the art 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 includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0187] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein when executed by a processor, the computer program causes the processor to perform the following steps:

[0188] Obtain a verification request with the original transaction code; verify the transaction according to the verification request, generate a verification result, and return it to the external system; when the external system does not receive a response, the response is unknown, or an anomaly occurs in the external system, obtain a reversal request; query the main transaction log according to the reversal request; determine the processing flow based on the transaction status of the main transaction log and process it; for transactions with a successful transaction status but incorrect accounting in business terms, cancel the transaction.

[0189] In one embodiment, after executing the computer program to perform the step of reversing a transaction whose transaction status is successful but is a business error, the processor further performs the following steps:

[0190] The aggregation service orchestrates the service call process and configures the compensation and reversal service for each called service. When an exception occurs, the state engine is driven to use the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node to roll back the transaction.

[0191] In one embodiment, when the processor executes the computer program to perform transaction verification based on the verification request, generate verification results, and return them to the peripheral system, the processor specifically implements the following steps:

[0192] The system queries the original transaction code. If the original transaction code exists, it determines whether the subsystem corresponding to the original transaction code is a public subsystem. If the subsystem corresponding to the original transaction code is a public subsystem, the local verification method is invoked. It then determines whether the original transaction serial number is empty. If the original transaction serial number is empty, the main transaction serial number is queried based on the requester information in the verification request. If the query result is not empty, the verification result is returned to the external system. If the original transaction serial number is not empty, and the original transaction time is the current business date or the previous day, the main transaction serial number is queried based on the original transaction serial number, and a verification result is generated and returned to the external system. If the original transaction time is neither the current business date nor the previous day, the verification result is set to empty, and the verification result is returned to the external system.

[0193] In one embodiment, when the processor executes the computer program to implement the processing flow based on the transaction status of the main transaction stream and performs the processing steps, it specifically implements the following steps:

[0194] Determine whether the transaction status of the main transaction flow is unknown; if the transaction status of the main transaction flow is unknown, verify each basic service, and according to the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, proceed to the end step; if the verification result is not failure or is not the first node, send a reversal MQ message to perform automatic reversal; if the transaction status of the main transaction flow is not unknown, send a reversal MQ message to perform automatic reversal.

[0195] In one embodiment, after executing the computer program to implement the sending of the reversal MQ message and the automatic reversal step, the processor further implements the following steps:

[0196] When the external system does not respond, the reverse transaction is verified. When the external system fails to respond, the reverse transaction is reversed again. When the external system responds successfully, the reverse request is processed asynchronously.

[0197] In one embodiment, when the processor executes the computer program to implement the step of driving the state engine when an exception occurs and using the Saga transaction compensation model to reverse the transaction rollback step of the compensation node corresponding to the successfully executed node, the specific implementation is as follows:

[0198] When the system is in a positive transaction, it determines whether the positive transaction is an unknown transaction; if the positive transaction is an unknown transaction, it automatically reverses the positive transaction; it then determines whether the reversal is complete; if the reversal is not complete, it performs asynchronous compensation for the positive transaction; if the asynchronous compensation is not completed, it uses manual intervention to handle the anomaly of the positive transaction.

[0199] In one embodiment, when the processor executes the computer program to implement the step of manually intervening to handle the abnormality of the positive transaction when asynchronous compensation is not completed, the specific steps are as follows:

[0200] When asynchronous compensation is not completed, manual intervention is used to query abnormal transaction log records, correct abnormal transaction status, and initiate manual reversal for the positive transaction.

[0201] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0202] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0203] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0204] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0205] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0206] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A financial-grade distributed business consistency guarantee method, characterized in that, include: Obtain a verification request with the original transaction code; The transaction is verified according to the verification request, the verification result is generated, and the result is returned to the external system. When the peripheral system does not receive a response, the response is unknown, or an anomaly occurs in the peripheral system, a reversal request is obtained; Query the main transaction history based on the reversal request; The processing flow is determined based on the transaction status of the main transaction flow, and then the processing is carried out. For transactions that are successful in status but are incorrect in business operations, the transactions shall be cancelled. The step of verifying the transaction based on the verification request, generating verification results, and returning them to the external system includes: Query the original transaction code; When the original transaction code exists, determine whether the subsystem corresponding to the original transaction code is a public subsystem; If the subsystem corresponding to the original transaction code is a public subsystem, then the local verification method is invoked; Determine if the original transaction serial number is empty; If the original transaction serial number is empty, then query the main transaction serial number table based on the requester information in the verification request; When the query result is not empty, the verification result is returned to the external system; If the original transaction serial number is not empty, and the original transaction time is the current business date or the previous day, the main transaction serial number is queried based on the original transaction serial number, and a verification result is generated and returned to the external system; if the original transaction time is neither the current business date nor the previous day, the verification result is set to empty and the verification result is returned to the external system.

2. The financial-grade distributed business consistency guarantee method according to claim 1, characterized in that, For transactions that are successful in status but have errors in business operations, after canceling the transaction, the process further includes: The aggregation service orchestrates the process of service calls and configures compensation and reversal services for each called service. When an anomaly occurs, the driving state engine uses the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node, thus rolling back the transaction.

3. The financial-grade distributed business consistency guarantee method according to claim 1, characterized in that, The process of determining and processing based on the transaction status of the main transaction flow includes: Determine whether the transaction status of the main transaction flow is unknown; If the transaction status of the main transaction flow is unknown, check the basic services one by one, and according to the node position of the erroneous basic service in the process, if the verification result is failure and it is the first node, enter the end step; if the verification result is not failure or is not the first node, send a reversal MQ message to perform automatic reversal. If the transaction status of the main transaction stream is not unknown, a reversal MQ message is sent to automatically reverse the transaction.

4. The financial-grade distributed business consistency guarantee method according to claim 3, characterized in that, After sending the reversal MQ message and performing automatic reversal, the process also includes: When the external system does not respond, the reverse transaction is verified. When the external system fails to respond, the reverse transaction is reversed again. When the external system responds successfully, the reverse request is processed asynchronously.

5. The financial-grade distributed business consistency guarantee method according to claim 2, characterized in that, The process of driving the state engine when an anomaly occurs, using the Saga transaction compensation model to reverse the execution of the compensation node corresponding to the successfully executed node, and rolling back the transaction includes: When the system is in a positive transaction phase, determine whether the positive transaction is an unknown transaction; If the positive transaction is an unknown transaction, then the positive transaction will be automatically reversed. Determine whether the correction has ended; If the reversal is not completed, asynchronous compensation will be performed on the positive transaction; When asynchronous compensation is not completed, manual intervention is used to handle the abnormality of the positive transaction.

6. The financial-grade distributed business consistency guarantee method according to claim 5, characterized in that, When asynchronous compensation is not completed, the abnormal handling of the positive transaction by manual intervention includes: When asynchronous compensation is not completed, manual intervention is used to query abnormal transaction log records, correct abnormal transaction status, and initiate manual reversal for the positive transaction.

7. A financial-grade distributed business consistency guarantee device, utilizing the financial-grade distributed business consistency guarantee method as described in any one of claims 1 to 6, characterized in that, include: The verification request acquisition unit is used to acquire verification requests containing the original transaction code; The verification unit is used to verify the transaction according to the verification request, generate the verification result, and return it to the external system; The reversal request acquisition unit is used to acquire a reversal request when the peripheral system does not receive a response, the response is unknown, or an anomaly occurs in the peripheral system; The query unit is used to query the main transaction flow based on the reversal request; The reversal processing unit is used to determine the processing flow based on the transaction status of the main transaction flow and to perform the processing. The cancellation unit is used to cancel transactions that are successful in terms of transaction status but are incorrect in terms of business operations.

8. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

Images