Financial-level distributed service consistency guarantee method and device, computer equipment and storage medium

Abstract

The embodiment of the invention discloses a financial-level distributed service consistency guarantee method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring a verification request with an original transaction code; performing transaction verification according to the verification request, generating a verification result, and returning the verification result to the peripheral system; when the peripheral system does not receive the response, the response is unknown or the peripheral system is abnormal, acquiring a reversal request; querying a main transaction flow according to the reversal request; determining a processing flow according to the transaction state of the main transaction flow, and performing processing; and revoking the transaction aiming at the transaction which is successful in transaction state but wrong in business. By implementing the method provided by the embodiment of the invention, the business consistency between systems and the data consistency in the systems in the financial field can be guaranteed.

Description

Technical Field

[0001] The present invention relates to a business consistency assurance method, and more specifically to a financial-grade distributed business consistency assurance method, device, computer equipment and storage medium. Background Art

[0002] In the financial sector, especially in financial systems that use a microservice distributed architecture, ensuring data accuracy and consistency is an extremely important challenge. This architecture often involves the aggregation of multiple downstream systems or services, such as the channel layer, product layer, new core system, etc. This complex business scenario leads to the following series of problems:

[0003] First, it is difficult to ensure business consistency. Because it involves multiple systems or services, there may be delays, losses or errors in the communication and data exchange between systems, resulting in inconsistency in transaction status. Second, it is difficult to manage business status. In a distributed environment, each service may be in a different state, making it difficult to uniformly manage and monitor the entire business process. Third, business monitoring and operation are difficult. Because it involves multiple systems and services, monitoring the entire business process becomes complicated, and it is difficult to discover and solve problems in a timely manner. Finally, there is a lack of unified error protection capabilities. In a complex distributed environment, it becomes more difficult to handle exceptions and errors, and there is a lack of a unified mechanism to handle these problems. 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 the system in the financial field. Summary of the invention

[0005] The purpose of the present invention is to overcome the defects of the prior art and provide a financial-grade distributed business consistency assurance method, device, computer equipment and storage medium.

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

[0007] Get a verification request with the original transaction code;

[0008] Perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system;

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

[0010] Query the main transaction flow according to the reversal request;

[0011] Determine the processing flow according to the transaction status of the main transaction flow and perform the processing;

[0012] For transactions that are in a successful state but are business errors, the transactions are canceled.

[0013] A further technical solution is: for a transaction whose transaction status is successful but is a wrong account in business, after cancelling the transaction, it also includes:

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

[0015] When an exception occurs, the state engine is driven and the Saga transaction compensation model is used to reversely execute the compensation node corresponding to the successfully executed node to roll back the transaction.

[0016] A further technical solution is: performing transaction verification according to the verification request, generating verification results, and returning them to the peripheral system, including:

[0017] Query the original transaction code;

[0018] When the original transaction code exists, determining 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, a local verification method is called;

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

[0021] If the original transaction serial number is empty, query the main transaction serial number table according to 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, when the original transaction time is the current business date or the previous day, the main transaction serial number is queried according to the original transaction serial number, and the verification result is generated and returned to the external system; when the original transaction time is not the current business date or the previous day, the verification result is set to empty and the verification result is returned to the external system.

[0024] A further technical solution is: the processing flow is determined according to the transaction status of the main transaction flow, and the processing is performed, including:

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

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

[0027] If the transaction status of the main transaction flow is not unknown, a reversal MQ message is sent for automatic reversal.

[0028] A further technical solution is: after sending the reversal MQ message and automatically reversing, the method further includes:

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

[0030] Its further technical solution is: when an exception occurs, the state engine is driven, and the Saga transaction compensation model is used to reversely execute the compensation node corresponding to the successfully executed node to roll back the transaction, including:

[0031] When the system is in a forward transaction, determining whether the forward transaction is an unknown transaction;

[0032] If the positive transaction is an unknown transaction, automatically reversing the positive transaction;

[0033] Determine whether the reversal is completed;

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

[0035] When the asynchronous compensation is not completed, the forward transaction is handled abnormally by manual intervention.

[0036] A further technical solution is: when the asynchronous compensation is not completed, the forward transaction is handled abnormally by manual intervention, including:

[0037] When the asynchronous compensation is not completed, manual intervention is used to query the abnormal transaction flow record of the forward transaction, correct the abnormal transaction status, and initiate manual reversal.

[0038] The present invention also provides a financial-grade distributed business consistency assurance device, including:

[0039] A verification request acquisition unit, used to acquire a verification request with an original transaction code;

[0040] A verification unit, used to verify the transaction according to the verification request, generate a verification result, and return it to the peripheral system;

[0041] A reversal request acquisition unit, used for acquiring a reversal request when the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system;

[0042] A query unit, used for querying the main transaction flow according to the reversal request;

[0043] A reversal processing unit, used to determine a processing flow according to the transaction status of the main transaction flow, and perform processing;

[0044] The revocation unit is used to revoke a transaction that is in a successful state but is a business error.

[0045] The present invention further provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor implements the above method when executing the computer program.

[0046] The present invention also provides a storage medium, wherein the storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0047] Compared with the prior art, the present invention has the following beneficial effects: the present invention verifies transactions on verification requests, and performs reversal processing according to the transaction status when no response is received from the peripheral system, the response is unknown, or an abnormality occurs in the peripheral system. Moreover, for transactions with a successful transaction status but an error in business, the transaction is revoked, thereby ensuring business consistency between systems in the financial field and data consistency within the system.

[0048] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

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

[0051] Figure 2 A flowchart of a method for ensuring consistency of financial-grade distributed services provided by an embodiment of the present invention;

[0052] Figure 3 A flowchart of a method for ensuring consistency of financial-grade distributed services provided by another embodiment of the present invention;

[0053] Figure 4 A state transition diagram between systems provided by an embodiment of the present invention;

[0054] Figure 5 A diagram of the reversal state transition within the system provided by an embodiment of the present invention;

[0055] Figure 6 A conversion diagram of the reversal state of a canceled transaction provided by an embodiment of the present invention;

[0056] Figure 7 The overall architecture of the Saga transaction compensation model provided by the embodiment of the present invention;

[0057] Figure 8 A schematic diagram of a transaction flow provided by an embodiment of the present invention;

[0058] Fig. 9 A schematic block diagram of a financial-grade distributed business consistency assurance device provided by an embodiment of the present invention;

[0059] Fig.10 A schematic block diagram of a financial-grade distributed business consistency assurance device provided by another embodiment of the present invention;

[0060] Fig.11 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work 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 "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

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

[0064] It should be further understood that the term "and / or" used in the present description and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0065] See also Figure 1 and Figure 2 , Figure 1 A schematic diagram of an application scenario of the financial-grade distributed business consistency assurance method provided in an embodiment of the present invention. Figure 2 A schematic flow chart of a financial-grade distributed business consistency assurance method provided by an embodiment of the present invention. The financial-grade distributed business consistency assurance method is applied to a server, which interacts with a peripheral system for data. According to the request of the peripheral system, the server provides inter-system reversal, transaction cancellation, and transaction verification to solve the problem of business consistency between systems; with the help of the Saga transaction compensation model, automatic reversal, timed task compensation, manual intervention and other solutions and measures are designed to solve the problem of data inconsistency within the system group.

[0066] Figure 2 FIG. 1 is a flow chart of a method for ensuring consistency of financial-grade distributed services provided by 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] Provides historical transaction status query function, and its operation follows the dominant principle of the peripheral system. When dealing with unknown responses, no response from the core system, abnormal logic and other scenarios, the system chooses to verify the original transaction, and the peripheral system further processes it according to the specific situation.

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

[0070] In one embodiment, the above-mentioned step S120 may include steps S121 - 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 is checked whether the subsystem corresponding to the original transaction code belongs to the public system; the verification processes of the public subsystem and the non-public subsystem are processed separately to adapt to different types of transactions.

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

[0076] In this embodiment, if the subsystem corresponding to the original transaction code is a public subsystem, a local verification method is called for verification; local verification is performed in the public subsystem to improve efficiency and accuracy.

[0077] S124. Determine whether 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 according to the requesting party information in the verification request.

[0080] In this embodiment, the main transaction flow table is queried according to the requesting party information in the verification request to obtain the main transaction flow number, ensuring that the correct main transaction flow information related to the request can be found.

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

[0082] In this embodiment, the verification result is returned to the peripheral system, so that the peripheral system can obtain the verification result in time 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 table according to the original transaction serial number, generate a verification result, and return the verification result to the peripheral system; when the original transaction time is not the current business date and the previous day, set the verification result to empty and return the verification result to the peripheral system.

[0084] In this embodiment, the verification result is generated according to the original transaction serial number and time conditions, and accurate verification results are generated according to different conditions, thereby improving the accuracy and practicality of the verification.

[0085] S128. If the subsystem corresponding to the original transaction code is not a public subsystem, route to a 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, it is routed to a specific subsystem and an internal verification request is initiated; ensuring that internal verification can be correctly performed in a non-public subsystem to ensure 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 through the original transaction code (service routing), the three elements of the requesting party, 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 is 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, a reversal between systems is performed.

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

[0089] In this embodiment, the reversal between systems is used when the peripheral does not receive a response, the response is unknown, or an abnormality occurs in the peripheral, but you want to offset the effect of the original transaction and roll it back to the previous state. In most cases, this operation needs to be used in conjunction with the verification transaction.

[0090] In this embodiment, when an exception occurs in the peripheral system, no response is received, or the response is unknown, a reversal request is obtained. This step ensures that when the process starts, the peripheral system is indeed in an uncertain state and needs to be reversed to ensure consistency. This avoids the uncertainty of the transaction status due to the abnormality of the peripheral system, which may cause other errors.

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

[0092] In this embodiment, according to the reversal request, the main transaction flow is queried to find the relevant transaction records. This step is to determine the status of the transaction and obtain preliminary information on the processing flow. Ensure that the process is based on accurate transaction information and provide a basis for subsequent judgment and operation.

[0093] S150. Determine a processing flow according to the transaction status of the main transaction flow and perform processing.

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

[0095] In this embodiment, after receiving the reversal request between peripheral systems, the main transaction flow is first queried. If the transaction flow is not found or the transaction status is failed, the process terminates; otherwise, proceed to the next step. If the transaction status is unknown, it is necessary to verify the basic services one by one, and make a comprehensive judgment on the subsequent processing flow based on the node position of the erroneous basic 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 of the reversal transaction; if the clear response fails, it is recommended to initiate the reversal between systems again; if the clear response is successful, it means that the system has received the reversal request and is performing asynchronous processing.

[0096] In one embodiment, the above-mentioned step S150 may include steps S151 - 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 required to avoid blind operations 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, verify the basic services one by one, and according to the node position of the erroneous basic service in the process, when the verification result is failure and it is the first node, enter the end step, when the verification result is not failure or it is not the first node, send a reversal MQ message, perform automatic reversal, and execute step S154;

[0100] In this embodiment, if the transaction status is unknown, it is necessary to verify the basic services one by one, and determine the subsequent operations based on the node position of the erroneous basic 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 basic service, the specific problem can be found, and whether reversal is needed 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 for automatic reversal.

[0102] If the transaction status is not unknown, it means that the transaction has succeeded or failed. In this case, directly send a reversal MQ message to start the automatic reversal process; avoid unnecessary verification, and directly perform the reversal operation to improve efficiency.

[0103] S154. When the peripheral system does not respond, the hedging transaction is verified. When the peripheral system fails to respond, the system is re-resolved. When the peripheral system responds successfully, the hedging request is processed asynchronously.

[0104] In the case of no response from the peripheral system, verify the reversal transaction. If the peripheral system fails to respond, reversal between systems is performed again. If the response is successful, it means that the system has received the reversal request and is processing it asynchronously; ensure that the reversal request is successfully processed and take appropriate actions based on the response of the peripheral system to prevent unnecessary errors or repeated operations.

[0105] Specifically, the response status of the peripheral system is constantly checked to determine whether it has responded, failed to respond, or successfully responded. If the peripheral system does not give any response within the predetermined time, a verification procedure is initiated to check whether the transaction request has been received and processed, or whether it exists in a queue waiting to be processed. Verification may include querying logs, databases, or using specialized monitoring tools to confirm the status of the reversal transaction. If the peripheral system returns a failed response, analyze the cause of the failure and decide whether to retry the reversal transaction immediately. Before retrying, ensure that the system status and data environment are suitable for another attempt. If the retry still fails, a limit on the number of retries can be set, and an alarm or notification to relevant personnel will be triggered after exceeding the limit. When a successful response from the peripheral system is received, the reversal request is processed asynchronously to ensure that the current business process is not blocked. Asynchronous processing may involve queuing the task into a background processing queue and processing it through a specialized background service to reduce the impact on the front-end or other interactive services. Throughout the entire processing process, transparency and detailed logs should be maintained, including each step of the operation, system response, and final result. Logs will help future analysis and auditing to improve processing processes and response strategies. In this way, it can be ensured that even if the peripheral system fails or responds unstablely, the problem of reversal transaction can be effectively managed and resolved, ensuring business continuity and data consistency.

[0106] In this embodiment, the original transaction is first verified. When the original transaction does not exist, a new main transaction flow is inserted. When the original transaction exists, if the original transaction has not been settled, the original transaction status is successful or unknown, the original transaction is not in the process of being revoked, and the system reversal acceptance record does not exist, then the asynchronous reversal request acceptance table can be registered. When the original transaction is successful, an asynchronous reversal MQ is initiated, and after the reversal is successfully accepted, the main transaction process information is returned; when the original transaction is unsuccessful, it is directly executed after the reversal is successfully accepted, and the main transaction process information is returned.

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

[0108] S160. For a transaction whose transaction status is successful but is a business error, cancel the transaction.

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

[0110] Specifically, in the revocation response judgment process, the situation where no response is received should be considered first. It is recommended that in this case, the peripheral system can choose to initiate a verification transaction and decide the next processing method based on the verification result, or directly trigger the reversal operation between systems.

[0111] If a response has been received, you need to determine the transaction status first:

[0112] If the transaction status is marked as successful, it means that the transaction has been successfully completed. In this case, the peripheral system can choose whether to initiate a reversal between systems based on actual needs.

[0113] If the transaction status is marked as failed, it means that the transaction processing has failed. At this time, 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 means that the system is abnormal. In this case, the system will automatically initiate a reversal operation. It is recommended that the peripheral system verify it after a period of time and make further processing based on the verification results.

[0115] The above-mentioned financial-grade distributed business consistency assurance method verifies transactions on verification requests, and performs reversal processing based on the transaction status when no response is received from the peripheral system, the response is unknown, or an abnormality occurs in the peripheral system. For transactions with a successful transaction status but a business error, the transaction is revoked, thereby ensuring business consistency between systems in the financial field and data consistency within the system.

[0116] Figure 3 FIG. 2 is a flow chart of a method for ensuring consistency of financial-grade distributed services provided by another embodiment of the present invention. Figure 3 As shown, the financial-grade distributed business consistency assurance method of this embodiment includes steps S210-S280. Steps S210-S260 are similar to steps S110-S160 in the above embodiment and are not described here. Steps S270-S280 added in this embodiment are described in detail below.

[0117] S270: The aggregation service orchestrates the process of service calls and configures a 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 arrange and combine the service calls that need to be executed according to the business logic to form a complete process. This process can be linear or contain branches and parallel execution; in the process, each service that needs to be executed is called. These services can be internal services, external services, or interfaces of other subsystems; for each service call, a corresponding compensation and reversal service is configured. These services are usually used to roll back or correct service calls in the event of an exception to ensure the consistency and integrity of the data; during the service call process, monitor the occurrence of abnormal situations. When an exception occurs, the corresponding compensation process or reversal process is triggered for processing according to the configured compensation and reversal service; in the entire process, the transaction status needs to be managed to ensure the consistency and integrity of the transaction. This can be achieved through a state machine or a transaction status table.

[0119] Configuring compensation and reversal services can handle exceptions in a timely manner, improve the system's fault tolerance and reliability, and reduce data loss or inconsistency caused by abnormal situations; using the 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 state engine is driven to reversely execute the compensation node corresponding to the successfully executed node using the Saga transaction compensation model to roll back the transaction.

[0121] In one embodiment, the above-mentioned step S280 may include steps S281 - S285 .

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

[0123] S282. If the forward transaction is an unknown transaction, automatically reversing the forward transaction;

[0124] S283, judging whether the reversal is completed;

[0125] S284. If the reversal is not completed, asynchronous compensation is performed on the forward transaction;

[0126] S285: When the asynchronous compensation is not completed, perform exception processing on the forward transaction by manual intervention.

[0127] Specifically, when the asynchronous compensation is not completed, manual intervention is used to query the abnormal transaction flow record of the forward transaction, correct the abnormal transaction status, and initiate manual reversal.

[0128] In this embodiment, the above-mentioned Saga transaction compensation model is as follows Figure 7 As shown in the figure. The Saga transaction solution is built on the DAP process engine and implemented using a state machine. Its mechanism is to orchestrate the service call process through aggregate services and configure compensation and reversal services for each calling service. When an exception occurs, the state engine is driven to reversely execute the compensation node corresponding to the successfully executed node to roll back the transaction.

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

[0130] Transaction initiator (aggregation subsystem): responsible for global transaction orchestration and registration, receiving peripheral transaction requests, and initiating calls to subtransactions. According to the process model, register the main and subtransaction relationships and update the transaction status. If an execution failure occurs, the reversal process is automatically initiated.

[0131] Transaction participant (basic subsystem): manages local transactions in global transactions and is responsible for data modification, commit, rollback, and compensation operations. It is the specific business executor of the subtransaction.

[0132] Asynchronous compensation (batch subsystem): responsible for asynchronous transaction compensation services, and decides what processing mechanism to adopt based on the transaction status and information, such as sending a correction message or an alarm. Generally, it includes: monitoring the status of asynchronous transactions regularly or in real time, including success, failure or other abnormal status; identifying abnormal transactions: identifying abnormal transactions based on the monitored transaction status, such as failed transactions caused by network problems, system failures or business logic errors; deciding the processing mechanism: deciding what processing mechanism to adopt based on the specific circumstances of the abnormal transaction. If it is a problem that can be solved by automatic correction, you can choose to send a correction message to the relevant system; if manual intervention or other specific processing is required, it may trigger an alarm or notify the relevant responsible personnel; executing processing: executing the corresponding operation according to the decided processing mechanism. When sending a correction message, send the message to the corresponding system or queue; when an alarm is triggered, notify the relevant personnel to handle it; monitoring the processing results: monitoring the results of the processing operation to ensure successful processing or timely follow up on the processing failure, and record the processing log for subsequent review and analysis; feedback status update: based on the processing results, update the status of the asynchronous transaction, mark it as processed or failed, for subsequent tracking and management.

[0133] Operation control console (operation subsystem): provides a manual intervention portal and supports operations such as querying abnormal transactions, modifying status, and manually reversing transactions.

[0134] In general, the Saga transaction compensation model uses the main transaction flow table, service call flow table and sub-transaction flow table to register transaction information and relationships. When a transaction is abnormal, the main flow number is used for reversal, including querying service call status and executing reversal procedures. Reversal of transactions 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 the final consistent state, send reversal messages and trigger the automatic reversal process. If the number of reversals reaches the upper limit, an alarm message will be sent and recorded in the error flow table, requesting manual intervention. The operation background provides abnormal transaction record query and manual processing functions.

[0136] Specifically, the main transaction flow table records the transaction flow of the first service, and implements idempotence control through the primary key TRANS_SRL_NO and the unique index: the requester flow number + the requester identifier, which is used to track the original transaction information to complete the reversal compensation mechanism. That is, when an abnormality occurs in the system, the original transaction information is tracked through the main flow number to complete the reversal compensation mechanism. The transaction status transStat identifies the current transaction processing result of a transaction. This attribute is uniformly assigned on the platform side, and the field values ​​are the following three: failure, success, and unknown. Among them, unknown scenarios include: the basic service has no response or explicitly returns unknown, the non-first basic service explicitly returns failure, and the update flow fails.

[0137] The service call flow table is used to record the calls of the aggregation service to the basic service, and is associated with the main flow number, service call flow number and sub-flow number so that the reversal process can be carried out when the system is abnormal. When the system is abnormal and the reversal process is carried out, the main flow number is used to find all the sub-transaction IDs that are successful and need to be compensated that are associated with the original transaction, and then the subsequent reversal compensation is carried out.

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

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

[0140] Specifically, when an exception occurs inside the trading system, the system will send an asynchronous MQ message for reversal. After receiving the message, the consumer will execute the core logic of automatic reversal: First, query the service call flow table to determine the execution status of each branch transaction flow one by one. If an exception is found and the branch is the first node, and the verification fails, the transaction status and flow status of the main flow are modified to failure, and the process is terminated; otherwise, the automatic reversal process continues. If the current branch is the last node and the verification is successful, if it is not a reversal between systems, the transaction status and flow status of the flow are modified to success, and then the process is terminated; otherwise, the automatic reversal process continues. Next, process the successfully executed sub-transactions one by one in reverse order, call the corresponding reversal basic service to complete the reversal logic of the sub-transaction, and update the sub-transaction flow. Until all basic services are reversal, then update the transaction status, flow status, number of reversals, number of reversal nodes and other information of the main transaction flow. Among them, the transaction flow table is as follows: Figure 8 shown.

[0141] The above-mentioned automatic reversal process is an operational process used to correct transaction errors or abnormal situations. It usually includes the following steps:

[0142] Get the service call flow list that needs to be reversed, determine the basic service location, and when the basic service location is the first one, query the basic service status. When the basic service status is successful, update the status of the main transaction flow table. For example, the forward status of the original transaction is changed from pending confirmation to failure, and the transaction status of the original transaction is changed from unknown to failure. Then perform MQ consumption confirmation. When the basic service status is failure, determine whether the forward status is pending confirmation and the reversal status is empty or failed. If so, the reversal status of the original transaction is changed to being executed, and the number of reversals is increased by one. Get the service call flow list with the sub-transaction status as successful / executing. ; Determine whether there is a next record. If there is no next record, update the transaction status of the main transaction flow table. For example, the forward status of the original transaction is changed from pending confirmation to failure, the reversal status of the original transaction is changed from being executed to success, the transaction status of the original transaction is changed from unknown to failure, and the reversal transaction is changed from being executed to success. Then, MQ consumption confirmation is performed; if there is a next record, check the sub-transaction status. When the sub-transaction status is being executed, check the basic service status. When the basic service status is being executed, determine whether the number of reversals has reached the upper limit. If it has not reached the upper limit, create a new reversal MQ and perform MQ consumption. Fee confirmation; when the upper 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 obtained; when the execution fails, the flow status of the main transaction flow table is updated, and the judgment of whether the number of reversals reaches the upper limit is executed; if the sub-transaction status is failed, the self-flow status of the service call flow is updated; when the basic service status is failed, the self-flow status of the service call flow is updated; when the basic service position is the last one, verify Basic service status, determine whether the basic service status is successful. If successful, determine whether it is between systems. If not, update the main transaction flow table status, such as updating the forward status of the original transaction from pending confirmation to success; update the transaction status from unknown to success, and then perform MQ consumption confirmation; if unsuccessful; if unsuccessful, execute to determine whether the forward status is pending confirmation and the reversal status is empty or failed; when the basic service position is neither the first nor the last, obtain the original transaction platform flow, and execute to determine whether the forward status is pending confirmation and the reversal status is empty or failed; the entire inter-system state transition diagram is as follows Figure 4 As shown, the transition of the reversal state in the system is as follows Figure 5 shown.

[0143] The process of reversing a canceled transaction is similar to the automatic reversal process of an active transaction, but it requires attention to changes in three types of transaction information, namely the original transaction (successfully executed, requiring reversal), the status changes of the canceled transaction, and the reversal transaction (cancellation status, transaction status, reversal status, transaction status, and number of reversal times).

[0144] The specific process is as follows: obtain the service call flow list that needs to be revoked, determine the basic service location, and when the basic service location is the first, query the basic service status. When the basic service status is successful, update the status of the main transaction flow table. For example, the revocation status of the original transaction to be revoked is updated from being executed to failure, the transaction status of the original transaction to be revoked is updated from unknown to success, and the forward status of the revoked transaction is updated from pending confirmation to failure; the transaction status of the revoked transaction is changed from unknown to failure; then perform MQ consumption confirmation; when the basic service status is failure, determine whether the forward status is pending confirmation and the reversal status is empty or failed. If so, the revocation status of the original transaction is changed to being executed, the number of revocations is increased by one, and the sub-transaction status is obtained as successful / executing service. The service calls the transaction list; determines whether there is a next record. If there is no next record, the transaction status of the main transaction flow table is updated. For example, the cancellation status of the original transaction being revoked is changed from unknown to failed, the transaction status of the original transaction being revoked is changed from unknown to successful, and the forward status of the revoked transaction is changed from pending confirmation to failed; the transaction status of the revoked transaction is changed from unknown to failed, the reversal status of the revoked transaction is changed from being executed to successful, and the status of the reversal transaction flow is changed from being executed to successful; then MQ consumption confirmation is performed; if there is a next record, the sub-transaction status is checked. When the sub-transaction status is being executed, the basic service status is verified. When the basic service status is being executed, it is determined whether the number of reversals has reached the upper limit. If it has not reached the upper limit, then Create a new reversal MQ and confirm MQ consumption; when the upper limit is reached, confirm MQ consumption; when the sub-transaction status is successful, call the cancellation service of the basic service, and when the execution is successful, update the self-flow status of the service call flow, and execute to obtain the service call flow list with the sub-transaction status of success / execution; when the execution fails, update the flow status of the main transaction flow table, such as updating the reversal status of the cancellation transaction from execution to failure, and updating the status of the reversal transaction flow from execution to failure; and execute to determine whether the number of reversals has reached the upper limit; if the sub-transaction status is failure, update the self-flow status of the service call flow; when the basic service status is failure, update the self-flow status of the service call flow; when the basic service position is the lowest In the latter case, check the basic service status to determine whether the basic service status is successful. If successful, determine whether it is between systems. If not, update the status of the main transaction flow table. For example, change the cancellation status of the original transaction to be cancelled from being executed to successful, and change the transaction status of the original transaction to be cancelled from unknown to failed; update the forward status of the cancelled transaction from pending confirmation to successful, and update the transaction status of the cancelled transaction from unknown to successful, and then perform MQ consumption confirmation; if unsuccessful; if unsuccessful, determine whether the forward status is pending confirmation and the reversal status is empty or failed; when the basic service position is neither the first nor the last, obtain the original transaction platform flow, and determine whether the forward status is pending confirmation and the reversal status is empty or failed;Specifically, the conversion diagram of canceling a transaction in a reversal state is as follows; Figure 6 shown.

[0145] The scheduled task is used to scan the main transaction flow that has not reached final consistency. If the number of automatic corrections reaches the upper limit, an alarm message will be sent and the error flow will be registered, requiring manual intervention.

[0146] Combined with the time point of the last scan, the data range of this scan is calculated, and combined with the transaction status (unknown UN), the main transaction flow that has not reached the final consistency is scanned out, and the following process judgment and processing is performed; if the number of automatic reversals reaches the upper limit, an alarm message is sent to the operation and maintenance side, and the key flow information is registered in the error flow table, and manual intervention is requested, otherwise the following process is transferred; a reversal MQ message is sent synchronously, and the automatic reversal process is performed (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] Get the time of the last successful scan, scan the transactions with unknown transaction status before a certain time in the main transaction flow table, and determine whether there is a next record. If not, register the successful scan time. If there is a next record, check the error flow table to determine whether there is an error flow table. If so, execute the scan of the transactions with unknown transaction status before a certain time in the main transaction flow table; if not, obtain the number of reversals, and determine whether the number of reversals has reached the upper limit. If not, initiate the reversal service, and send MQ one-step consumption to uniformly follow the automatic reversal process to determine whether the reversal is successful. If successful, execute the scan of the transactions with unknown transaction status before a certain time in the main transaction flow table; if unsuccessful, send an alarm, register the error flow table, and execute the scan of the transactions with unknown transaction status before a certain time in the main transaction flow table; if the number of reversals has reached the upper limit, send an alarm, and register the error flow table.

[0149] The operation background provides functions such as abnormal transaction flow record query, abnormal transaction status correction, manual correction, etc., which are used to handle abnormal transactions that cannot be automatically processed by the system.

[0150] For the above process, when the peripheral system needs to conduct a positive transaction or cancel a transaction, a request message will be initiated, and the core system group of the server will conduct a positive transaction or cancel the transaction, and feedback will be sent to the peripheral system for response analysis. When the response is successful or failed, the transaction will be ended. When the response is no response or unknown, the system will reverse or verify the transaction. When verification of the transaction is required, the peripheral system will initiate verification. After receiving the verification request message, the server will verify the transaction and feedback to the peripheral system. When the verification transaction has no response or returns unknown, verification will be initiated again. When the response is not no response or unknown, When unknown is returned, the original transaction status is determined. If it is failed, does not exist, or is successful, the transaction is terminated. If it is unknown or does not exist, verification is initiated again. In extreme cases, when verification is initiated, the upper layer receives the original request. In this case, it is recommended to initiate verification again after a period of time. For inter-system reversal, when the peripheral system initiates a message of a reversal request, the core system group of the server performs inter-system reversal and feeds back to the peripheral system to determine the original transaction status. If it is a failure, the transaction is terminated. If it is unknown or successful, the instruction is received for asynchronous processing. This step is to register the received instruction and asynchronously initiate the automatic reversal process.

[0151] The above-mentioned financial-grade distributed business consistency guarantee method provides solutions to the business consistency problems in the financial field in a distributed environment, including verification of transactions, cancellation of transactions, and reversal of transactions between systems to solve the challenges of business consistency between systems. By using the Saga long transaction theory and combining core functions such as microservice orchestration and transaction flow status, a data final consistency solution is provided. By adopting this method, the peripheral system can judge and control the consistency of transactions between different systems. The core system group of the server solves the problem of data consistency between systems in a distributed environment by inheriting the capabilities provided by this solution, allowing 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 abnormalities; it not only meets the business consistency requirements in distributed scenarios in the financial field, but also simplifies the design and development difficulty of the financial core system.

[0152] Fig. 9 is a schematic block diagram of a financial-grade distributed business consistency assurance device 300 provided in an embodiment of the present invention. Fig. 9 As shown, corresponding to the above financial-level distributed business consistency guarantee method, the present invention also provides a financial-level distributed business consistency guarantee device 300. The financial-level distributed business consistency guarantee device 300 includes a unit for executing the above financial-level distributed business consistency guarantee method, and the device can be configured in a server. Specifically, please refer to Fig. 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 revocation unit 306.

[0153] The verification request acquisition unit 301 is used to obtain the verification request with the original transaction code; the verification unit 302 is used to perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system; the reversal request acquisition unit 303 is used to obtain the reversal request when the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system; the query unit 304 is used to query the main transaction flow according to the reversal request; the reversal processing unit 305 is used to determine the processing flow according to the transaction status of the main transaction flow and perform processing; the cancellation unit 306 is used to cancel the transaction whose transaction status is successful but is a wrong account in business.

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

[0155] a transaction code query subunit, for querying the original transaction code; a subsystem judgment subunit, for judging whether the subsystem corresponding to the original transaction code is a public subsystem when the original transaction code exists; a local call subunit, for calling a local verification method if the subsystem corresponding to the original transaction code is a public subsystem; a serial number judgment subunit, for judging whether the original transaction serial number is empty; a transaction table query subunit, for querying the main transaction transaction table according to the requester information in the verification request if the original transaction serial number is empty; a return subunit, for returning the verification result to the peripheral system when the query result is not empty; a verification result generation subunit, for querying the main transaction transaction table according to the original transaction serial number if the original transaction serial number is not empty, when the original transaction time is the current business date or the previous day, and generating a verification result, and returning the verification result to the peripheral system; when the original transaction time is not the current business date and the previous day, setting the verification result to empty, and returning the verification result to the peripheral system.

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

[0157] The status judgment subunit is used to judge whether the transaction status of the main transaction flow is unknown; the item-by-item verification subunit is used to verify the basic services item by item if the transaction status of the main transaction flow is unknown, and according to the node position of the erroneous basic service in the process, when the verification result is failure and it is the first node, enter the end step, and when the verification result is not failure or it is not the first node, send a reversal MQ message for automatic reversal; the sending subunit is used to send a reversal MQ message for automatic reversal if the transaction status of the main transaction flow is not unknown. The asynchronous processing subunit is used to verify the reversal transaction when the peripheral system does not respond, and to perform reversal between systems again when the peripheral system fails to respond, and to asynchronously process the reversal request when the peripheral system responds successfully.

[0158] Fig.10 FIG. 3 is a schematic block diagram of a financial-grade distributed business consistency assurance device 300 provided by another embodiment of the present invention. Fig.10 As shown, the financial-grade distributed business consistency assurance device 300 of this embodiment is based on the above embodiment and adds a configuration unit 307 and a rollback unit 308.

[0159] The configuration unit 307 is used to aggregate services to orchestrate the process of service calls and configure compensation and reversal services for each calling service; the rollback unit 308 is used to drive the state engine when an exception occurs, and use the Saga transaction compensation model to reversely execute 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 transaction judgment subunit is used to judge whether the forward transaction is an unknown transaction when the system is in a forward transaction; the automatic reversal subunit is used to automatically reverse the forward transaction if the forward transaction is an unknown transaction; the end judgment subunit is used to judge whether the reversal is completed; the asynchronous compensation subunit is used to perform asynchronous compensation on the forward transaction if the reversal is not completed; the manual intervention subunit is used to perform abnormal processing on the forward transaction by manual intervention when the asynchronous compensation is not completed.

[0162] In one embodiment, the manual intervention subunit is used to query the abnormal transaction flow record, correct the abnormal transaction status, and initiate manual reversal of the forward transaction by manual intervention when the asynchronous compensation is not completed.

[0163] It should be noted that technical personnel in the relevant field can clearly understand that the specific implementation process of the above-mentioned financial-grade distributed business consistency assurance device 300 and each unit can refer to the corresponding description in the aforementioned method embodiment, and for the convenience and conciseness of the description, it will not be repeated here.

[0164] The financial-grade distributed business consistency assurance device 300 can be implemented in the form of a computer program. The computer program can be implemented in the following manner: Fig.11 Runs on the computer device shown.

[0165] See also Fig.11 , Fig.11 5 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a server, wherein the server may be an independent server or a server cluster composed of multiple servers.

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

[0167] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, and when the program instructions are executed, the processor 502 can execute a financial-level distributed business consistency assurance method.

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

[0169] The internal memory 504 provides an environment for the operation 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 assurance method.

[0170] The network interface 505 is used to communicate with other devices over the network. Fig.11 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of 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 a different arrangement of components.

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

[0172] Obtain a verification request with the original transaction code; perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system; obtain a reversal request when the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system; query the main transaction flow according to the reversal request; determine the processing flow according to the transaction status of the main transaction flow, and perform processing; for transactions with a successful transaction status but a wrong account in business, cancel the transaction.

[0173] In one embodiment, after implementing the step of cancelling the transaction whose transaction status is successful but is a business error, the processor 502 further implements the following steps:

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

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

[0176] 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, call the local verification method; determine whether the original transaction serial number is empty; if the original transaction serial number is empty, query the main transaction flow table according to the requester information in the verification request; when the query result is not empty, return the verification result to the peripheral system; 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 flow table according to the original transaction serial number, generate a verification result, and return the verification result to the peripheral system; when the original transaction time is not the current business date and the previous day, set the verification result to empty, and return the verification result to the peripheral system.

[0177] In one embodiment, when the processor 502 determines the processing flow according to the transaction status of the main transaction flow and performs the processing steps, the processor 502 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 the basic services one by one, and according to the node position of the erroneous basic service in the process, when the verification result is failure and it is the first node, enter the end step, when the verification result is not failure or it is not the first node, send a reversal MQ message for automatic reversal; if the transaction status of the main transaction flow is not unknown, send a reversal MQ message for 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 peripheral system does not respond, the hedging transaction is verified. When the peripheral system fails to respond, the system is reversed again. When the peripheral system responds successfully, the hedging request is processed asynchronously.

[0181] In one embodiment, the processor 502 implements the following steps when driving the state engine when an exception occurs and using the Saga transaction compensation model to reversely execute the compensation node corresponding to the successfully executed node to roll back the transaction:

[0182] When the system is in a forward transaction, determine whether the forward transaction is an unknown transaction; if the forward transaction is an unknown transaction, automatically reverse the forward transaction; determine whether the reversal is completed; if the reversal is not completed, perform asynchronous compensation on the forward transaction; when the asynchronous compensation is not completed, perform abnormal processing on the forward transaction by manual intervention.

[0183] In one embodiment, when the processor 502 implements the step of performing exception handling on the forward transaction by manual intervention when the asynchronous compensation is not completed, the processor 502 specifically implements the following steps:

[0184] When the asynchronous compensation is not completed, manual intervention is used to query the abnormal transaction flow record of the forward transaction, correct the abnormal transaction status, and initiate manual reversal.

[0185] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0186] It can be understood by those skilled in the art that all or part of the processes in the method for implementing the above embodiment can be completed by instructing the relevant hardware through a computer program. The computer program includes program instructions, and the computer program 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 embodiment of the above method.

[0187] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor executes the following steps:

[0188] Obtain a verification request with the original transaction code; perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system; obtain a reversal request when the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system; query the main transaction flow according to the reversal request; determine the processing flow according to the transaction status of the main transaction flow, and perform processing; for transactions with a successful transaction status but a wrong account in business, cancel the transaction.

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

[0190] The aggregation service orchestrates the process of service calls and configures compensation and reversal services for each calling service. When an exception occurs, the state engine is driven to use the Saga transaction compensation model to reversely execute 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 implement the steps of performing transaction verification according to the verification request, generating a verification result, and returning the result to the peripheral system, the processor specifically implements the following steps:

[0192] 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, call the local verification method; determine whether the original transaction serial number is empty; if the original transaction serial number is empty, query the main transaction flow table according to the requester information in the verification request; when the query result is not empty, return the verification result to the peripheral system; 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 flow table according to the original transaction serial number, generate a verification result, and return the verification result to the peripheral system; when the original transaction time is not the current business date and the previous day, set the verification result to empty, and return the verification result to the peripheral system.

[0193] In one embodiment, when the processor executes the computer program to implement the process of determining the processing flow according to the transaction status of the main transaction flow and performing the processing steps, the processor 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 the basic services one by one, and according to the node position of the erroneous basic service in the process, when the verification result is failure and it is the first node, enter the end step, when the verification result is not failure or it is not the first node, send a reversal MQ message for automatic reversal; if the transaction status of the main transaction flow is not unknown, send a reversal MQ message for automatic reversal.

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

[0196] When the peripheral system does not respond, the hedging transaction is verified. When the peripheral system fails to respond, the system is reversed again. When the peripheral system responds successfully, the hedging 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 reversely executing the compensation node corresponding to the successfully executed node to roll back the transaction using the Saga transaction compensation model, the following steps are specifically implemented:

[0198] When the system is in a forward transaction, determine whether the forward transaction is an unknown transaction; if the forward transaction is an unknown transaction, automatically reverse the forward transaction; determine whether the reversal is completed; if the reversal is not completed, perform asynchronous compensation on the forward transaction; when the asynchronous compensation is not completed, perform abnormal processing on the forward transaction by manual intervention.

[0199] In one embodiment, when the processor executes the computer program to implement the step of performing exception handling on the forward transaction by manual intervention when the asynchronous compensation is not completed, the processor specifically implements the following steps:

[0200] When the asynchronous compensation is not completed, manual intervention is used to query the abnormal transaction flow record of the forward transaction, correct the abnormal transaction status, and initiate manual reversal.

[0201] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk, etc., which are computer-readable storage media that can store program codes.

[0202] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

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

[0204] The steps in the method of the embodiment of the present invention can be adjusted in order, combined and deleted according to actual needs. The units in the device of the embodiment of the present invention can be combined, divided and deleted according to actual needs. In addition, the functional units in the various embodiments of the present 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 in the form of 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 is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention.

[0206] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A financial-grade distributed business consistency assurance method, characterized in that: include: Get a verification request with the original transaction code; Perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system; When the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system, obtaining a reversal request; Query the main transaction flow according to the reversal request; Determine the processing flow according to the transaction status of the main transaction flow and perform the processing; For transactions that are in a successful state but are business errors, the transactions are canceled.

2. The financial-grade distributed business consistency assurance method according to claim 1 is characterized in that: After cancelling the transaction whose transaction status is successful but is a business error, the method further includes: The aggregation service orchestrates the process of service calls and configures compensation and reversal services for each calling service; When an exception occurs, the state engine is driven and the Saga transaction compensation model is used to reversely execute the compensation node corresponding to the successfully executed node to roll back the transaction.

3. The financial-grade distributed business consistency assurance method according to claim 1 is characterized in that: The transaction verification is performed according to the verification request, and a verification result is generated and returned to the peripheral system, including: Query the original transaction code; When the original transaction code exists, determining 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, a local verification method is called; Determine whether the original transaction serial number is empty; If the original transaction serial number is empty, query the main transaction serial number table according to 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, when the original transaction time is the current business date or the previous day, the main transaction serial number is queried according to the original transaction serial number, and the verification result is generated and returned to the external system; when the original transaction time is not the current business date or the previous day, the verification result is set to empty and the verification result is returned to the external system.

4. The financial-grade distributed business consistency assurance method according to claim 1 is characterized in that: The process of determining the processing flow according to the transaction status of the main transaction flow and performing the processing includes: Determining whether the transaction status of the main transaction flow is unknown; If the transaction status of the main transaction flow is unknown, verify the basic services one by one, and according to the node position of the erroneous basic service in the process, when the verification result is failure and it is the first node, enter the end step, and when the verification result is not failure or it is not the first node, send a reversal MQ message for automatic reversal; If the transaction status of the main transaction flow is not unknown, a reversal MQ message is sent for automatic reversal.

5. The financial-grade distributed business consistency assurance method according to claim 4 is characterized in that: After sending the reversal MQ message and automatically reversing, the method further includes: When the peripheral system does not respond, the hedging transaction is verified. When the peripheral system fails to respond, the system is reversed again. When the peripheral system responds successfully, the hedging request is processed asynchronously.

6. The financial-grade distributed business consistency assurance method according to claim 1, characterized in that: When an exception occurs, the state engine is driven to reversely execute the compensation node corresponding to the successfully executed node using the Saga transaction compensation model to roll back the transaction, including: When the system is in a forward transaction, determining whether the forward transaction is an unknown transaction; If the positive transaction is an unknown transaction, automatically reversing the positive transaction; Determine whether the reversal is completed; If the reversal is not completed, asynchronous compensation is performed on the forward transaction; When the asynchronous compensation is not completed, the forward transaction is handled abnormally by manual intervention.

7. The financial-grade distributed business consistency assurance method according to claim 6 is characterized in that: When the asynchronous compensation is not completed, the forward transaction is handled abnormally by manual intervention, including: When the asynchronous compensation is not completed, manual intervention is used to query the abnormal transaction flow record of the forward transaction, correct the abnormal transaction status, and initiate manual reversal.

8. Financial-grade distributed business consistency assurance device, characterized in that: include: A verification request acquisition unit, used to acquire a verification request with an original transaction code; A verification unit, used to perform transaction verification according to the verification request, generate verification results, and return them to the peripheral system; A reversal request acquisition unit, used for acquiring a reversal request when the peripheral system does not receive a response, the response is unknown, or an abnormality occurs in the peripheral system; A query unit, used for querying the main transaction flow according to the reversal request; A reversal processing unit, used to determine a processing flow according to the transaction status of the main transaction flow, and perform processing; The revocation unit is used to revoke a transaction that is in a successful state but is a business error.

9. A computer device, characterized in that: The computer device comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images