A method and device for processing business data consistency in a distributed system

Abstract

This article relates to the field of automatic programming technology, and in particular to a method and device for processing business data consistency in a distributed system. The method includes performing a first consistency process based on the service execution result fed back by the sub-service providing system, and recording the status of the sub-service call request in the local service execution history table; performing a second consistency process on the sub-service call request in a first specific state, and updating the status of the sub-service call request based on the service execution result; performing a third consistency process on the sub-service call request in the second specific state in the local service execution history table; returning to the first consistency process step, and receiving the service execution result fed back by the sub-service providing system based on the third consistency process. By using the embodiments of this article, the consistency of data in the distributed system can be further ensured by combining different consistency processes.

Description

Technical Field

[0001] The present invention relates to the field of automatic programming technology, and in particular to a method and device for processing business data consistency in a distributed system. Background Art

[0002] With the continuous development of the Internet era, the business scale of the financial industry has continued to expand, and the system has become more and more complex. The service of a single node can no longer meet the needs, so people split the system or data, and distributed systems came into being. However, how to ensure that the information, work progress, and status of each subsystem are consistent and work in a coordinated and orderly manner has become a major problem for distributed systems. If strong consistency is to be achieved, it may lead to poor overall system performance, affected scalability, and extremely complex architecture. Therefore, in the Internet field, in many cases, strong consistency is sacrificed to achieve high availability. The system often only needs to ensure "eventual consistency" as long as this final time is within the acceptable range for users. However, the financial field involves financial security and needs to ensure 100% accuracy. Therefore, how to solve the data consistency of financial distributed systems in the existing technology is an urgent problem to be solved. Summary of the invention

[0003] In order to solve the problem that financial data consistency requirements are high and the existing technology cannot ensure high consistency of business data in financial distributed systems, the embodiments of this article provide a distributed system business data consistency processing method and device, which achieves high business success rate and good business data consistency in financial distributed systems by combining multiple business data consistency processing methods.

[0004] The embodiment of this article provides a distributed system service data consistency processing method, including:

[0005] According to the business needs, at least one sub-service call request is generated and sent to the corresponding sub-service providing system;

[0006] Performing a first consistency process according to the service execution result fed back by the sub-service providing system, and recording the state of the sub-service call request after the first consistency process in a local service execution history table;

[0007] Performing a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and updating the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system;

[0008] Performing third consistency processing on the sub-service call request in the second specific state in the local service execution history table;

[0009] Return to the first consistency processing step, and receive the service execution result fed back by the sub-service providing system according to the third consistency processing.

[0010] The embodiment of the present invention also provides a distributed system business data consistency processing system, including a service calling system and a sub-service providing system;

[0011] The service calling system further comprises:

[0012] A sub-service call request generating unit, used to generate at least one sub-service call request according to business requirements and send it to a corresponding sub-service providing system;

[0013] A first consistency processing unit, configured to perform a first consistency processing according to the service execution result fed back by the sub-service providing system, and record the state of the sub-service call request after the first consistency processing in a local service execution history table;

[0014] A second consistency processing unit, configured to perform a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and to update the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system;

[0015] The third consistency processing unit is used to perform third consistency processing on the sub-service call request in the second specific state in the local service execution history table; return to the first consistency processing unit to receive the service execution result fed back by the sub-service providing system according to the third consistency processing.

[0016] The embodiments of the present invention further provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above method when executing the computer program.

[0017] The embodiments of the present invention also provide a computer-readable storage medium on which computer instructions are stored. When the computer instructions are executed by a processor, the above method is implemented.

[0018] By utilizing the embodiments of this article, by combining different consistency processing, the consistency of data in the distributed system can be further ensured, and by performing the first consistency processing, the second consistency processing, the third consistency processing and the fourth consistency processing simultaneously, the possibility of a failed sub-service call request trying to execute again in the sub-service providing system and succeeding can be increased. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of this article or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of this article. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0020] Figure 1 The figure shows a schematic diagram of the system structure of TCC distributed transactions in the prior art;

[0021] Figure 2 The figure is a flow chart of a method for processing business data consistency in a distributed system according to an embodiment of the present invention;

[0022] Figure 3 The figure is a schematic diagram of the structure of a distributed system business data consistency processing system according to an embodiment of this invention;

[0023] Figure 4 The figure shows a detailed structural diagram of a distributed system business data consistency processing system according to an embodiment of this invention;

[0024] Figure 5 The figure is an overall flow chart of a method for processing business data consistency in a distributed system according to an embodiment of this invention;

[0025] Figure 6 Shown with Figure 5 The schematic diagram of the system structure corresponding to the embodiment of this article is shown;

[0026] Figure 7 The figure shows a schematic diagram of the device structure of the service calling system and the sub-service providing system according to the embodiment of this article.

[0027]

Description of Figure Numbers

[0028] 101. Main business server;

[0029] 102. Business subsystem;

[0030] 103. Business Activity Manager;

[0031] 300. Service calling system;

[0032] 301. Subservice call request generating unit;

[0033] 302, a first consistency processing unit;

[0034] 3021, first processing module;

[0035] 3022, second processing module;

[0036] 30221, computing module;

[0037] 30222, reverse sub-service call request module;

[0038] 3023, third processing module;

[0039] 303, second consistency processing unit;

[0040] 3031, fourth processing module;

[0041] 3032, fifth processing module;

[0042] 3033, sixth processing module;

[0043] 304, a third consistency processing unit;

[0044] 3041, seventh processing module;

[0045] 3042, eighth processing module;

[0046] 3043, ninth processing module;

[0047] 305. fourth consistency processing unit;

[0048] 3051, tenth processing module;

[0049] 3052, eleventh processing module;

[0050] 3053, twelfth processing module;

[0051] 400. Sub-service providing system;

[0052] 401, message middleware;

[0053] 402, execution unit;

[0054] 403. Comparison unit;

[0055] 601. Service calling system;

[0056] 602. Sub-service providing system;

[0057] 603. Message queue;

[0058] 604. File processing system;

[0059] 702. Computing equipment;

[0060] 704. Processing equipment;

[0061] 706. Storage resources;

[0062] 708, driving mechanism;

[0063] 710, input / output module;

[0064] 712. Input devices;

[0065] 714. Output devices;

[0066] 716. Presentation equipment;

[0067] 718. Graphical user interface;

[0068] 720, network interface;

[0069] 722. Communication link;

[0070] 724. Communication bus. DETAILED DESCRIPTION

[0071] The following will be combined with the drawings in the embodiments of this article to clearly and completely describe the technical solutions in the embodiments of this article. Obviously, the described embodiments are only part of the embodiments of this article, not all of the embodiments. Based on the embodiments of this article, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this article.

[0072] like Figure 1 The figure shows a schematic diagram of the system structure of TCC distributed transactions in the prior art. This figure describes the idea of ​​TCC distributed transaction processing in the prior art, which is used to maintain the consistency of each subsystem in the distributed system. TCC distributed transaction processing refers to dividing transaction processing into three stages, namely the Try stage, the Confirm stage and the Cancel stage. TCC is composed of the first letters of these three stages. Among them, the Try stage is used to detect the business system and reserve resources; the Confirm stage is used to confirm and submit the business system. When the Try stage is executed successfully and the Confirm stage begins to execute, the Confirm stage will not go wrong by default, that is: as long as the Try succeeds, the Confirm will succeed; the Cancel stage is used to cancel the executed business and release the reserved resources when the business execution fails and needs to be rolled back.

[0073] exist Figure 1In the distributed system shown, the main business server 101 initiates the entire business activity, which may involve multiple sub-businesses to cooperate to complete a main business. The main business server 101 starts to call the link to different business subsystems 102 in turn to execute the Try logic to perform sub-business detection and resource reservation; the business activity manager 103 controls the consistency of business activities in each business subsystem 102, registers business activity operations and records business activity logs; if the Try logic is processed normally in all business subsystems 102, the business activity manager 103 executes the Confirm logic and calls different sub-businesses to complete the main business; if there is a problem with the Try logic processing of a sub-service, the TCC distributed transaction processing system will advance the execution of the Cancel logic of each business subsystem 102 to cancel the various operations previously executed. In order to solve the consistency problem in the TCC distributed transaction processing system, each business subsystem 102 is required to execute the Try logic first and then execute Confirm, which makes the entire system bloated and complex, the application is highly invasive, and the transformation cost is high; and, in such Figure 1 In the example shown, if there is a problem with the Try logic processing, when the Cancel logic is executed in different business subsystems 102, some business subsystems (such as Figure 1 Business subsystem A) receives the Cancel command, while some business subsystems (such as Figure 1 If business subsystem B) in the process does not receive the Cancel command, business subsystem A will be rolled back successfully, but business subsystem B will not be rolled back, and the entire system will be in an inconsistent state.

[0074] like Figure 2 The flowchart of a distributed system business data consistency processing method in an embodiment of this invention is shown. In this figure, it is described that a simple, effective and more convenient way is achieved to ensure the consistency of business data in a distributed system by combining and crossing business data consistency processing means. The embodiment of this figure mainly describes the process method of the service call system. Each step in the process method may be performed by a software program or a general chip, specifically including:

[0075] Step 201, generating at least one sub-service call request according to business requirements and sending it to a corresponding sub-service providing system;

[0076] Step 202: Perform a first consistency process according to the service execution result fed back by the sub-service providing system, and record the state of the sub-service call request after the first consistency process in a local service execution history table;

[0077] Step 203, performing a second consistency processing on the sub-service call request in the first specific state in the local service execution history table that has undergone the first consistency processing, and updating the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system;

[0078] Step 204, performing a third consistency process on the sub-service call request in the second specific state in the local service execution history table;

[0079] Step 205, returning to the first consistency processing step, receiving the service execution result fed back by the sub-service providing system according to the third consistency processing.

[0080] Through the synchronous first consistency processing and the second consistency processing and the asynchronous third consistency processing in the method in the embodiments of this article, the success rate of sub-service calls in the distributed system can be improved, and the consistency of business data in each subsystem can be ensured, so that the distributed system can achieve the final consistency of the entire system in a simple and effective way, with a high degree of automatic repair.

[0081] As one aspect of the embodiments of this document, generating at least one sub-service invocation request and sending it to a corresponding sub-service providing system further includes: the sub-service invocation request includes a unique identifier.

[0082] In this step, the unique identifier of the sub-service invocation request is used to uniquely identify the sub-service invocation request in all sub-service providing systems and service invocation systems.

[0083] As one aspect of the embodiments of this document, the service execution result fed back by the sub-service providing system includes a success state where the sub-service call request is successfully executed, and a failure state where the sub-service call request is failed to be executed.

[0084] In this step, the sub-service call request is executed in the sub-service providing system. If the execution is successful, the sub-service providing system will feedback a success status, otherwise it will feedback a failure status, and no timeout status will be fed back. The timeout status is modified to a timeout status by the service calling system after the service calling system sends out the sub-service call request and does not receive any feedback from the sub-service providing system about the success or failure status of the sub-service call request within a predetermined time. The timeout status is stored in the local service execution history table.

[0085] As one aspect of the embodiments of this document, the first consistency processing includes:

[0086] Record the sub-service call request in a successful state in the local service execution history table, and end;

[0087] Recording the failed sub-service call request in the local service execution history table, resending the sub-service call request to the corresponding sub-service providing system, and receiving the service execution result fed back by the sub-service providing system;

[0088] If the sub-service providing system does not feed back the service execution result within a predetermined time, the sub-service call request in the timeout state is recorded as a timeout state in the local service execution history table.

[0089] In this step, if the sub-service providing system does not make any error, it can correctly execute the sub-service call request and feed back the service execution result, that is, the information that the sub-service call request is in a successful state, to the service calling system; if the sub-service providing system makes an error, it will not correctly execute the sub-service call request and feed back the service execution result, that is, the information that the sub-service call request is in a failed state, to the service calling system, and the service calling system will resend the sub-service call request to the sub-service providing system based on the service execution result, so as to retry to execute the sub-service call request, thereby completing all sub-services described in the entire business; if the sub-service providing system does not feed back the service execution result to the service calling system for more than a predetermined time, the service calling system will only modify the local service execution history table, change the status of the sub-service call request to a timeout state, and will not perform any other processing on the sub-service call request in the first consistency processing.

[0090] As one aspect of the embodiment of this invention, the step of resending the sub-service invocation request to the corresponding sub-service providing system and receiving the service execution result fed back by the sub-service providing system further includes:

[0091] The time for resending the sub-service invocation request is calculated. If the time exceeds the first time threshold and the status of the sub-service invocation request is a failure status, an error is reported and the request is exited.

[0092] In this step, the first time threshold can be a time interval of 30 seconds, 50 seconds, etc. If the sub-service call request cannot be successfully executed by the sub-service providing system within a reasonable long time, an error will be triggered and the consistency processing method of this article will be exited. An error message can be sent to the sub-service providing system, which may include a unique identifier of the sub-service call request and the reason for the error, that is, multiple attempts to execute the sub-service have failed, and the sub-service providing system is requested to feedback the reason for the execution failure, and the manual management interface of the sub-service providing system is notified to analyze the reason for the failure of the sub-service call request.

[0093] In other embodiments, the calculation may be performed based on the number of times the sub-service call request is repeatedly sent to the sub-service providing system. If the number of times the sub-service call request is repeatedly executed exceeds a predetermined threshold, an error is reported and the system exits.

[0094] As one aspect of the embodiment of this document, the error reporting and exiting also includes:

[0095] A reverse subservice call request is sent to the subservice providing system corresponding to other subservice call requests associated with the subservice call request that caused the error exit, so that the corresponding subservice providing system executes the reverse subservice call request to roll back the subservice call request that has been successfully executed.

[0096] In this step, the reverse sub-service call request has the opposite execution order of the atomic service call request. For example, if the atomic service call request is to add new customer information, then the reverse sub-service call request is to delete the customer information. When a business demand contains multiple self-service call requests, some of which are successfully executed in the corresponding sub-service provision system, but some or a certain sub-service call request fails to execute, and the repeated failures exceed the threshold value, it is necessary to reversely execute the atomic service call request in all sub-service provision systems related to the business demand, so that the data in all sub-service provision systems is consistent with the data in the service call system, thereby further and better ensuring the data consistency of the entire distributed system.

[0097] As one aspect of the embodiment of this document, performing a second consistency processing on the sub-service call request in the first specific state in the local service execution history table after the first consistency processing further includes:

[0098] Generate a query request for the sub-service call request in the local service execution history table whose status is timed out;

[0099] Sending the query request to the corresponding sub-service providing system;

[0100] Receive the service execution result fed back by the corresponding sub-service providing system.

[0101] In this step, the query request includes a unique identifier of the sub-service call request in the timeout state. After sending the query request to the corresponding sub-service providing system, the sub-service providing system queries the unique identifier of the sub-service call request in the service execution status table. The service execution status table only records two states of the sub-service call request, namely, the success state and the failure state. The sub-service providing system feeds back the execution result of the queried sub-service call request to the service calling system. The service calling system can update the state of the sub-service call request in the local service execution history table according to the execution result, for example, changing the state of the sub-service call request in the local service execution history table from the timeout state in the first consistency processing to the success state or the failure state.

[0102] As one aspect of the embodiment of this invention, receiving the service execution result fed back by the corresponding sub-service providing system further includes:

[0103] If the service execution result fed back by the corresponding sub-service providing system is not received within the second time threshold, the sub-service call request in the local service execution history table that is in the timeout state remains in the timeout state, and the query request is resent to the corresponding sub-service providing system;

[0104] If no service execution result fed back by the corresponding sub-service providing system is received before the third time threshold is reached, an error report is issued and the system exits.

[0105] In this step, the second time threshold may be, for example, 10 seconds, 15 seconds, etc. After repeatedly sending multiple query requests, for example, 1 minute, 2 minutes, etc., no service execution result is received from the corresponding sub-service providing system, then an alarm message will be sent to the manual management interface of the service call system, which may include a unique identifier of the sub-service call request, as well as the number and time of retransmission attempts and the final timeout status, so that the manual management interface of the service call system can analyze the reason for the execution timeout of the sub-service call request.

[0106] As one aspect of the embodiment of this document, performing a third consistency processing on the sub-service call request in the second specific state in the local service execution history table further includes:

[0107] Read the sub-service call request in the local service execution history table whose status is timeout or failure;

[0108] Send the read sub-service call request to the message queue;

[0109] The sub-service providing system obtains the sub-service calling request in the message queue;

[0110] The sub-service providing system executes the sub-service calling request;

[0111] Receive the service execution result of the sub-service providing system.

[0112] In this step, the service call system puts the sub-service call request in the timeout state or the failed state into the message queue through the message management unit. For example, the sub-service call request can be sent to the Kafka message queue in the form of a Kafka message. After the message middleware of the sub-service providing system monitors the message of the new sub-service call request in the Kafka message queue, it will query the status of the corresponding sub-service call request in the service execution status table. If there is no such sub-service call request, the sub-service call request is executed on the sub-service providing system, and the sub-service call request and its status are recorded in the service execution status table; if the status of the sub-service call request recorded in the service execution status table is a successful status, the status of the sub-service call request is fed back through the communication interface for feeding back the service execution result in the first consistency processing; if the status of the sub-service call request recorded in the service execution status table is a failed status, the sub-service call request is re-executed in the sub-service providing system. If the sub-service call request cannot be correctly executed after repeated execution, the failure status of the sub-service call request is fed back through the communication interface for feeding back the service execution result in the first consistency processing.

[0113] A typical message queue is one-way, that is, one party only writes information from the message queue, and then the other party obtains the information from the message queue and executes it, and the result of the message execution is not fed back to the message writer. In the embodiments of this article, the message queue is combined with the first consistency processing step, and the sub-service providing system feeds back the execution result of the sub-service call request in the message queue to the service calling system through the communication interface in the first consistency processing process, thereby realizing an execution result feedback mechanism based on the message queue.

[0114] As one aspect of the embodiment of this document, performing third consistency processing on the sub-service call request in the second specific state in the local service execution history table includes:

[0115] During the first consistency processing and the second consistency processing, the third consistency processing is performed synchronously.

[0116] In this step, during the first consistency processing, for example, after receiving the service execution result fed back by the sub-service providing system, the sub-service call request status in the local service execution history table is updated, and a sub-service call request in a failed state may appear. At this time, before or at the same time as the sub-service call request in the failed state is resent in the first consistency processing, the sub-service call request can be placed in the message queue through the message management unit, and the message middleware of the sub-service providing system obtains the sub-service call request in the message queue. At this time, the sub-service providing system obtains two sub-service call requests with the same unique identifier, one from the sub-service call request resent in the first consistency processing process, and the other from the sub-service call request in the message queue. The sub-service providing system determines whether the unique identifiers of each sub-service call request are the same. If they are the same, only one successful execution result of the sub-service call request is retained. If the sub-service call request is executed multiple times, and the execution results include success and failure, then the sub-service call request status is a successful state. If the execution results of multiple sub-service call requests are all failures, then the sub-service call request status is a failed state. That is, when the sub-service providing system receives multiple repeated sub-service call requests, if one succeeds, the service execution result is fed back as a success state, and if all fail, the service execution result is fed back as a failure state.

[0117] In other embodiments, the sub-service providing system may also count the number of sub-service call requests received for repeated execution, accumulate the number of repeated sub-service call requests sent through the first consistency processing and the number of sub-service call requests obtained from the message queue in the third consistency processing, and sort the execution order of the sub-service call requests according to the size of the accumulated values ​​of different sub-service call requests, with the requests with larger accumulated values ​​being executed first and the requests with smaller accumulated values ​​being executed later, so that the sub-service call requests can be re-executed faster to complete the sub-service call request and thus complete the entire business service.

[0118] As one aspect of the embodiments of this document, the method of the embodiments of this document also includes:

[0119] Performing fourth consistency processing on the sub-service call request in the second specific state in the local service execution history table;

[0120] Return to the first consistency processing step, and receive the service execution result fed back by the sub-service providing system according to the fourth consistency processing.

[0121] In this step, during the first consistency processing, the second consistency processing, the third consistency processing, or after a certain processing, the service call system can generate a corresponding data verification file based on the sub-service call request of the second specific status recorded in the local service execution history table, and send the data verification file to the sub-service provider system when the system does not respond to business at the end of the day (or a specific time period), so that the sub-service provider system can compare the data verification file with the sub-service call request recorded in the service execution status table. If the status recorded in the two is inconsistent, for example, the status of the sub-service call request in the service execution status table is a failure status, and the sub-service call request in the data verification file is a timeout status, then the sub-service provider system will feedback the failure status of the sub-service call request through the communication interface that feeds back the service execution result in the first consistency processing.

[0122] As one aspect of the embodiment of this document, performing fourth consistency processing on the sub-service call request in the second specific state in the local service execution history table further includes:

[0123] Extracting sub-service call requests in the local service execution history table that are in a timeout state and a failed state;

[0124] The extracted sub-service call requests are converted into a data verification file and sent to the sub-service providing system;

[0125] The receiving of the service execution result fed back by the sub-service providing system according to the fourth consistency processing further includes:

[0126] Receive the service execution result fed back by the sub-service providing system after comparing the data verification file with the service execution status table.

[0127] In this step, the sub-service call requests that have failed or timed out in the local service execution history table are extracted to generate a data verification file, which is then transmitted through a data file transmission channel. The data transmission channel in this embodiment is different from the instant messaging interface involved in the first consistency processing, the second consistency processing, and the third consistency processing. Since the data verification file is relatively large in size, the data file transmission channel can be used to transmit the data verification file to the sub-service provision system through a wider reserved loan. In the sub-service providing system, the data verification file is compared with the sub-service call request in the service execution status table. If the status of the two is inconsistent, for example, the status of the sub-service call request in the data verification file is a timeout status, and the sub-service call request in the service execution status table in the sub-service providing system is a success status, then the success status of the sub-service call request will be fed back through the communication interface for feeding back the service execution result in the first consistency processing; if the status of the sub-service call request in the data verification file is a failure status, and the sub-service call request in the service execution status table in the sub-service providing system is a failure status (or the sub-service call request does not exist in the service execution status table), then the sub-service call request will be executed in the sub-service providing system, and the service execution result, such as a success status or a failure status, will be fed back through the communication interface for feeding back the service execution result in the first consistency processing.

[0128] Through the method of the above-mentioned embodiment of this article, by combining different consistency processing, the consistency of data in the distributed system can be further ensured, and by performing the first consistency processing, the second consistency processing, the third consistency processing and the fourth consistency processing at the same time, the possibility of a failed sub-service call request trying to execute again in the sub-service providing system and succeeding can be increased.

[0129] like Figure 3 The figure shows a schematic diagram of the structure of a distributed system business data consistency processing system according to an embodiment of the present invention. In this figure, the functions of each unit and module can be implemented by software programs, general chips, separate computers, servers, etc., and a unit or module is not limited to a software program or a hardware circuit. By combining multiple consistency processing units, the business data consistency of the entire distributed system can be further improved. The device specifically includes:

[0130] Service calling system 300, sub-service providing system 400; wherein,

[0131] The service calling system 300 further includes:

[0132] The sub-service call request generating unit 301 is used to generate at least one sub-service call request according to the business requirements and send it to the corresponding sub-service providing system;

[0133] A first consistency processing unit 302, configured to perform a first consistency processing according to the service execution result fed back by the sub-service providing system, and record the state of the sub-service call request after the first consistency processing in a local service execution history table;

[0134] A second consistency processing unit 303 is used to perform a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and update the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system;

[0135] The third consistency processing unit 304 is used to perform a third consistency processing on the sub-service call request in the second specific state in the local service execution history table; return to the first consistency processing unit 302, and receive the service execution result fed back by the sub-service providing system 400 according to the third consistency processing.

[0136] As an aspect of an embodiment of this document, the service execution result includes a success status in which the sub-service call request is successfully executed, and a failure status in which the sub-service call request is failed to be executed; if the sub-service providing system does not feedback the service execution result within a predetermined time, the sub-service call request is in a timeout status.

[0137] As one aspect of the embodiments of this article, Figure 4 The figure shows a detailed structural diagram of a distributed system business data consistency processing system in an embodiment of this invention. In this figure, a more detailed system logical structure is described. The first consistency processing unit 302 further includes:

[0138] The first processing module 3021 is used to record the sub-service call request in the successful state in the local service execution history table, and end;

[0139] The second processing module 3022 is used to record the sub-service call request in the failed state in the local service execution history table, resend the sub-service call request to the corresponding sub-service providing system 400, and receive the service execution result fed back by the sub-service providing system 400;

[0140] The third processing module 3023 is used to record the sub-service call request in the timeout state in the local service execution history table.

[0141] As one aspect of the embodiment of this article, the second processing module 3022 further includes:

[0142] The calculation module 30221 is used to calculate the time for resending the sub-service call request. If the time exceeds the first time threshold and the status of the sub-service call request is a failure status, an error is reported and the system exits.

[0143] As one aspect of the embodiment of this article, the second processing module 3022 further includes:

[0144] The reverse sub-service call request module 30222 is used to send a reverse sub-service call request to the sub-service providing system corresponding to other sub-service call requests associated with the sub-service call request that caused the error exit, so that the corresponding sub-service providing system executes the reverse sub-service call request to roll back the sub-service call request that has been successfully executed.

[0145] As one aspect of the embodiment of this article, the second consistency processing unit 303 further includes:

[0146] The fourth processing module 3031 is used to generate a query request for the sub-service call request whose status is timed out in the local service execution history table;

[0147] The fifth processing module 3032 is used to send the query request to the corresponding sub-service providing system;

[0148] The sixth processing module 3033 is used to receive the service execution result fed back by the corresponding sub-service providing system.

[0149] As one aspect of the embodiment of this invention, the sixth processing module 3033 is further configured to: if the service execution result fed back by the corresponding sub-service providing system is not received within the second time threshold, the sub-service call request in the local service execution history table that is in the timeout state is still in the timeout state, and the fifth processing module 3032 is notified to resend the query request to the corresponding sub-service providing system;

[0150] If no service execution result fed back by the corresponding sub-service providing system is received before the third time threshold is reached, an error report is issued and the system exits.

[0151] As one aspect of the embodiment of this article, the third consistency processing unit 304 further includes:

[0152] The seventh processing module 3041 is used to read the sub-service call request with a timeout state or a failure state in the local service execution history table;

[0153] An eighth processing module 3042 is used to send the read sub-service call request to the message queue;

[0154] The sub-service providing system 400 includes a message middleware 401 and an execution unit 402, wherein:

[0155] The message middleware 401 is used to obtain the sub-service call request in the message queue;

[0156] The execution unit 402 is used to execute the sub-service call request;

[0157] The ninth processing module 3043 is used to receive the service execution result of the sub-service providing system 400.

[0158] As one aspect of the embodiments of this document, the third consistency processing unit 304 performs processing simultaneously with the first consistency processing unit 302 and the second consistency processing unit 303 .

[0159] As an aspect of the embodiments of this document, it also includes a fourth consistency processing unit 305, which is used to perform fourth consistency processing on the sub-service call request in the second specific state in the local service execution history table; receive the service execution result fed back by the sub-service providing system 400 according to the fourth consistency processing, and return it to the first consistency processing unit 302.

[0160] As one aspect of the embodiment of this article, the fourth consistency processing unit 305 further includes:

[0161] A tenth processing module 3051 is used to extract the sub-service call request in the second specific state from the local service execution history table;

[0162] An eleventh processing module 3052 is used to convert the extracted sub-service call request into a data verification file and send it to the sub-service providing system 400;

[0163] The sub-service providing system 400 further includes a comparison unit 403, which is used to compare the data verification file with the service execution status table and then feedback the service execution result;

[0164] The twelfth processing module 3053 is used to receive the service execution result fed back by the sub-service providing system after comparing the data verification file with the service execution status table.

[0165] Through the system of the above-mentioned embodiment of the present invention, by combining different consistency processing, the consistency of data in the distributed system can be further ensured, and by performing the first consistency processing, the second consistency processing, the third consistency processing and the fourth consistency processing at the same time, the possibility of a failed sub-service call request being tried again in the sub-service providing system and being successful can be increased.

[0166] like Figure 5 The figure shows the overall flow chart of a distributed system business data consistency processing method in the embodiment of this article. The figure describes the overall process of the business data consistency processing method in this article. In the embodiment of this article, the user's loan account opening is taken as the overall business service content. The overall business service includes several sub-service call requests, such as calling the bank's core deposit system to deposit the loan amount into the individual's deposit bank card account, adding customer information, etc. When new customer information needs to be added during the loan account opening business process, the customer information is uniformly stored in the sub-service provision system. At this time, the service call system (i.e., the system that executes the loan account opening business) needs to call the sub-service provision system (i.e., the customer information system) to complete the business service needs of the new customer. The system structure corresponding to this method can be referred to in the attached. Figure 6 As shown, the system includes a service calling system 601 and a sub-service providing system 602. In a distributed system, there may be multiple sub-service providing systems that perform the same or different services. In this embodiment, only one sub-service providing system 602 is shown. The embodiment of this article does not limit the number of sub-service providing systems. Each sub-service providing system executes the same process method and also includes a message queue 603 and a file processing system 604. The method executed in the system specifically includes the following steps:

[0167] Step 501: Generate a corresponding sub-service call request according to the business needs of the newly added customer.

[0168] In this step, the generated sub-service invocation request is a request for adding a new customer, and the sub-service invocation request includes a unique serial number and an address of a sub-service providing system that can provide service to the new customer.

[0169] The method of generating a unique serial number may include, consisting of the number of a security node, that is, a computer with encrypted information in the banking system (the encrypted number is, for example, 10000), an identifier of the service call system (such as a machine number), time, a serial number, etc. The time of generating the sub-service call request may be accurate to millisecond level, and may be the time before the loan account opening business begins, or may be the time when each sub-service call request is generated, thereby ensuring the uniqueness of the generated unique serial number.

[0170] Step 502: Send the sub-service invocation request to the corresponding sub-service providing system.

[0171] In this step, the corresponding service call interface is found according to the address of the sub-service provider system, which may include, for example, the port number through which the sub-service provider system receives the service call request, security verification rules and other communication information. Based on these communication information, the service call request including the unique serial number is sent to the corresponding sub-service provider system.

[0172] Step 503: After receiving the sub-service invocation request, the sub-service providing system executes the sub-service invocation request.

[0173] In this step, the sub-service provision system can use specific software and hardware functional modules to implement the service call request for adding new customers. However, since the sub-service provision system needs to handle all business services related to customer information, such as adding new customers, querying customer information, deleting customer information, etc., not every sub-service call request will be executed successfully, or the sub-service call request may need to be suspended and wait for certain high-priority call requests to be executed before the sub-service call request can be executed. Therefore, there is also the possibility of delayed execution.

[0174] The sub-service providing system has a service execution status table, which records the unique serial number of the sub-service call request and the execution result of the sub-service call request, that is, the execution result of the sub-service call request is a success state or a failure state, as shown in Table 1 below:

[0175] Table 1

[0176] Unique serial number Subservice call execution result 12345 Success or failure

[0177] Step 504: the sub-service providing system feeds back the service execution result of the sub-service calling request to the service calling system through the communication interface.

[0178] In this step, the sub-service providing system feeds back the service execution result of the sub-service call request to the service calling system according to the service execution status table. Since the service call request sending and service execution result feedback are based on the real-time communication mechanism, the communication interface can respond to real-time needs and receive and send information in real time.

[0179] However, in this step, due to network delays, communication failures, system problems, program problems and other reasons, the service execution results of the sub-service call request may not be fed back in a timely manner, resulting in the status of the sub-service call request not being able to be fed back to the service call system in a timely manner. This is the reason why the business data inconsistency problem between systems occurs.

[0180] Step 505: The service calling system performs corresponding operations according to the received service execution result.

[0181] In this step, when the sub-service call request in the service execution result is in a successful state, the sub-service call request is recorded in the local service execution history table of the service call system, and the status of the sub-service call request is recorded as a successful state, and the subsequent steps are skipped to end the business data consistency processing method of the embodiment of this article.

[0182] When the sub-service call request in the service execution result is in a failed state, the sub-service call request is recorded in the local service execution history table of the service call system, and the status of the sub-service call request is recorded as a failed state; then the sub-service call request is resent to the communication interface of the sub-service providing system within a period of time, so that the sub-service providing system can repeatedly try to execute the service call request; when the status of the sub-service call request is still in a failed state after a period of time, an error is reported to the manual management interface, and the administrator of the service call system sends a request to analyze the cause of the failure to the administrator of the sub-service providing system, so that the reason for the failure of the sub-service call request can be obtained. At the same time, a reverse sub-service call request will be sent to other sub-service providing systems related to the loan account opening business, requesting these sub-service providing systems to reversely execute the corresponding sub-service call requests, that is, reversely execute the sub-service call requests involved in the loan account opening business that have been successfully executed in other sub-service providing systems, so as to keep the business data of each sub-service providing system and service call system related to the loan account opening business in the distributed system consistent.

[0183] When the service calling system does not receive the service execution result fed back by the sub-service providing system within a period of time, the sub-service calling request is recorded in the local service execution history table of the service calling system, and the status of the sub-service calling request is recorded as a timeout status.

[0184] Step 506: The sub-service providing system performs a reverse operation according to the reverse sub-service calling request sent by the service calling system.

[0185] Since the functional structure of each sub-service providing system is similar, although the sub-service providing system 602 does not necessarily perform reverse operations in this embodiment, in order to illustrate the process method of business data consistency processing, the service calling system issues a reverse sub-service calling request to other sub-service providing systems related to the current loan account opening business, and after the sub-service providing system receives the reverse sub-service calling request, it will perform steps completely opposite to the sub-service calling request processing steps to eliminate the inconsistency in business data. In this embodiment, if the atomic service calling request is to add customer information, then the corresponding reverse sub-service calling request is to delete customer information. Each update-type sub-service calling request, that is, a service calling request for adding, deleting, modifying, etc. operations on the database, will automatically call this reverse sub-service calling request to complete the rollback when an error occurs in the service calling system or an error occurs in the sub-service providing system.

[0186] Step 507: Send a query request to the sub-service providing system according to the status of the sub-service calling request in the local service execution history table of the service calling system.

[0187] In this step, the service call system queries the status of the sub-service call request in the local service execution history table. When the sub-service call request is in a timeout state, a query request is generated, which includes at least the unique serial number of the sub-service call request in the timeout state, and the query request is sent to the sub-service providing system through the real-time query communication interface of the sub-service providing system.

[0188] Step 508: The sub-service providing system queries the service execution status table according to the query request and feeds back the query result.

[0189] Query the status of the sub-service call request with a unique serial number in the service execution status table. Since the sub-service call request in the service execution status table has only two states, namely, success state or failure state, only the service execution results of these two states will be fed back to the service call system.

[0190] Step 509: When the status of the sub-service invocation request is a failure status, the sub-service invocation request is repeatedly executed.

[0191] In this step, when the sub-service providing system finds that the sub-service call request is in a failed state, it can jump back to step 504 and execute the sub-service call request again. If the execution is successful, the status of the sub-service call request in the service execution status table will be rewritten as a successful state; if the sub-service call request is still in a failed state after repeated execution, the status of the sub-service call request in the service execution status table will be kept as a failed state.

[0192] By executing the sub-service call request again, the service execution result, ie, the information of the success or failure status of the sub-service call request, can be fed back to the service call system through the communication interface in step 504 .

[0193] Step 510: If no query result is received from the sub-service providing system within a predetermined time, the query request is sent repeatedly.

[0194] In this step, if the number of times the query request is sent repeatedly or the repetition time exceeds a predetermined threshold, an error is reported and the process exits.

[0195] Step 511: Update the local service execution history table according to the received query result.

[0196] In this step, the status of the corresponding sub-service call request in the local service execution history table is updated according to the success status and failure status of the sub-service call request obtained from the query result.

[0197] Step 512, determining whether the status of the sub-service call request in the local service execution history table is a success status, if it is a success status, the service call ends, otherwise, returning to step 502.

[0198] The business data consistency processing method of the embodiment of this invention also includes step 513 which can be performed simultaneously with the above steps 505 to 512, and reads the sub-service call request with a timeout state or a failure state in the local service execution history table.

[0199] In this step, the sub-service call request in the successful state does not need to be processed again, and only the sub-service call request in the timeout state and the failed state needs to be processed. The sub-service call request in the timeout state or the failed state in the local service execution history table can be read in real time by the message management unit of the service call system, or this step can be performed by sending a notification to the message management unit after the sub-service call request in the failed state is determined in the above step 512.

[0200] Step 514: The message management unit sends the read sub-service call request to the message queue.

[0201] In this step, the message management unit converts the read sub-service call request into a Kafka message format, and sends the converted message to the Kafka message queue.

[0202] Step 515: The message middleware of the sub-service providing system monitors the message queue in real time.

[0203] In this step, the message middleware of the sub-service providing system waits until a new sub-service call request appears in the Kafka message queue, and then reads the sub-service call request.

[0204] Step 516: query the service execution status table for the status of the corresponding sub-service call request.

[0205] Step 517: If the sub-service call request in the message queue is in a timeout state, perform corresponding processing.

[0206] In this step, if the status of the sub-service call request in the service execution history table in the service call system is in a timeout state due to network reasons or other reasons, and the sub-service call request in the query service execution status table is in a successful state, the processing process in step 504 can be returned at this time; if the sub-service call request in the service execution status table is in a failed state, the processing process in step 503 can be returned at this time.

[0207] Step 518: If the sub-service call request in the message queue is in a failed state, perform corresponding processing.

[0208] In this step, if the status of the sub-service call request in the service execution history table in the service call system is a failed status, the processing process returns to step 503 in the sub-service providing system to execute the sub-service call request again.

[0209] In the above steps 517 and 518, when the sub-service providing system executes the sub-service call request again, the corresponding service execution result will be generated, that is, the status of the sub-service call request may change. The status of the sub-service call request in the service execution status table will be updated on the sub-service providing system side, and the status of the sub-service call request will also be fed back to the service call system through the communication interface in step 504.

[0210] The business data consistency processing method of the embodiment of this invention also includes step 519 which can be performed simultaneously with the above steps 505 to 518, and extracts the sub-service call requests in the local service execution history table that are in the timeout state and the failure state.

[0211] In this step, the file processing system 604 extracts the sub-service call requests in the timeout state and the failed state from the local service execution history table of the service call system to form a data verification file.

[0212] Step 520: Send the data verification file to the sub-service providing system through the file transmission channel.

[0213] In this step, after the sub-service call requests of a specific status are extracted from the local service execution history table at the scheduled time, such as 12 noon and 12 midnight every day, they are formed into a data verification file and sent to the sub-service providing system through the file transfer channel.

[0214] Step 521: The sub-service providing system compares the data verification file with the sub-service calling request in the service execution status table.

[0215] Step 522: If the status of the sub-service call request in the data verification file is inconsistent with the status of the sub-service call request in the service execution status table, the status of the sub-service call request in the service execution status table is fed back to the service call system.

[0216] In this step, if the status of the sub-service call request in the data verification file is a timeout status, and the sub-service call request in the service execution status table of the sub-service providing system is a success status, the success status of the sub-service call request will be fed back through the communication interface in step 504.

[0217] Step 523: If the status of the sub-service call request in the data verification file and the status of the sub-service call request in the service execution status table are both failure status, the sub-service call request is executed repeatedly.

[0218] In this step, if the status of the sub-service call request in the data verification file is a failure status, and the sub-service call request in the service execution status table in the sub-service providing system is a failure status (or the sub-service call request does not exist in the service execution status table), then step 503 is entered to execute the sub-service call request in the sub-service providing system, and the service execution result, such as a success status or a failure status, is fed back to the status of the sub-service call request through the communication interface of step 504.

[0219] Through the method of the above-mentioned embodiment of this article, by combining different consistency processing, the consistency of data in the distributed system can be further ensured, and the processing speed when inconsistency problems occur can be improved; by performing multiple business data consistency processing methods at the same time, the possibility of failed sub-service call requests trying to execute again in the sub-service providing system and succeeding can be increased.

[0220] like Figure 7 The device structure diagram of the service calling system and the sub-service providing system of the embodiment of this article is shown. In this embodiment, the device is called a computing device. The computing device 702 may include one or more processing devices 704, such as one or more central processing units (CPUs), and each processing unit may implement one or more hardware threads. The computing device 702 may also include any storage resource 706, which is used to store any kind of information such as code, settings, data, etc. Non-limiting, for example, the storage resource 706 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any storage resource can use any technology to store information. Further, any storage resource can provide volatile or non-volatile retention of information. Further, any storage resource can represent a fixed or removable component of the computing device 702. In one case, when the processing device 704 executes an associated instruction stored in any storage resource or a combination of storage resources, the computing device 702 can perform any operation of the associated instruction. The computing device 702 also includes one or more drive mechanisms 708 for interacting with any storage resources, such as a hard disk drive mechanism, an optical disk drive mechanism, and the like.

[0221] The computing device 702 may also include an input / output module 710 (I / O) for receiving various inputs (via input devices 712) and for providing various outputs (via output devices 714). One specific output mechanism may include a presentation device 716 and an associated graphical user interface 718 (GUI). The computing device 702 may also include one or more network interfaces 720 for exchanging data with other devices via one or more communication links 722. One or more communication buses 724 couple the components described above together.

[0222] The communication link 722 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 722 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0223] The embodiment of the present invention further provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0224] According to the business needs, at least one sub-service call request is generated and sent to the corresponding sub-service providing system;

[0225] Performing a first consistency process according to the service execution result fed back by the sub-service providing system, and recording the state of the sub-service call request after the first consistency process in a local service execution history table;

[0226] Performing a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and updating the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system;

[0227] Performing third consistency processing on the sub-service call request in the second specific state in the local service execution history table;

[0228] Receive the service execution result fed back by the sub-service providing system according to the third consistency processing, and return to the first consistency processing step.

[0229] The computer device provided in the embodiments of this invention can also implement the following Figure 2 , Figure 5 The method in .

[0230] Corresponds to Figure 2 , Figure 5 The method in this article also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are executed.

[0231] The embodiment of the present invention also provides a computer readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figure 2 , Figure 5 The method shown.

[0232] It should be understood that in the various embodiments of this document, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0233] It should also be understood that in the embodiments of this document, the term "and / or" is only a description of the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the associated objects before and after are in an "or" relationship.

[0234] 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 this article.

[0235] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0236] In the several embodiments provided herein, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be electrical, mechanical or other forms of connection.

[0237] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of this article.

[0238] In addition, each functional unit in each embodiment of this invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional unit.

[0239] 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 computer-readable storage medium. Based on this understanding, the technical solution of this article 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 to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of this article. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0240] Specific embodiments are used in this article to illustrate the principles and implementation methods of this article. The description of the above embodiments is only used to help understand the methods and core ideas of this article. At the same time, for general technicians in this field, according to the ideas of this article, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on this article.

Claims

1. A method for processing business data consistency in a distributed system, characterized in that include, According to the business needs, at least one sub-service call request is generated and sent to the corresponding sub-service providing system; Performing a first consistency process according to the service execution result fed back by the sub-service providing system, and recording the state of the sub-service call request after the first consistency process in a local service execution history table; Performing a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and updating the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system; Performing third consistency processing on the sub-service call request in the second specific state in the local service execution history table; Returning to the first consistency processing step, receiving the service execution result fed back by the sub-service providing system according to the third consistency processing; The performing of the second consistency processing on the sub-service call request in the first specific state in the local service execution history table after the first consistency processing further includes: Generate a query request for the sub-service call request in the local service execution history table whose status is timed out; Sending the query request to the corresponding sub-service providing system; Receive the service execution result fed back by the corresponding sub-service providing system; The third consistency processing of the sub-service call request in the second specific state in the local service execution history table further includes: Read the sub-service call request in the local service execution history table whose status is timeout or failure; Send the read sub-service call request to the message queue; The sub-service providing system obtains the sub-service calling request in the message queue; The sub-service providing system executes the sub-service calling request; Receive the service execution result of the sub-service providing system.

2. The method according to claim 1, characterized in that Generating at least one sub-service invocation request and sending it to a corresponding sub-service providing system further includes: the sub-service invocation request includes a unique identifier.

3. The method according to claim 1, characterized in that The service execution result includes a success status in which the sub-service invocation request is successfully executed, and a failure status in which the sub-service invocation request is failed to be executed.

4. The method according to claim 3, characterized in that The first consistency processing includes: Record the sub-service call request in a successful state in the local service execution history table, and end; Recording the failed sub-service call request in the local service execution history table, resending the sub-service call request to the corresponding sub-service providing system, and receiving the service execution result fed back by the sub-service providing system; If the sub-service providing system does not feed back the service execution result within a predetermined time, the sub-service call request is recorded as a timeout state in the local service execution history table.

5. The method according to claim 4, characterized in that The step of resending the sub-service call request to the corresponding sub-service providing system and receiving the service execution result fed back by the sub-service providing system further includes: The time for resending the sub-service invocation request is calculated. If the time exceeds the first time threshold and the status of the sub-service invocation request is a failure status, an error is reported and the request is exited.

6. The method according to claim 5, characterized in that The error exit also includes: A reverse subservice call request is sent to the subservice providing system corresponding to other subservice call requests associated with the subservice call request that caused the error exit, so that the corresponding subservice providing system executes the reverse subservice call request to roll back the subservice call request that has been successfully executed.

7. The method according to claim 1, characterized in that Receiving the service execution result fed back by the corresponding sub-service providing system further includes: If the service execution result fed back by the corresponding sub-service providing system is not received within the second time threshold, the sub-service call request in the local service execution history table that is in the timeout state remains in the timeout state, and the query request is resent to the corresponding sub-service providing system; If no service execution result fed back by the corresponding sub-service providing system is received before the third time threshold is reached, an error report is issued and the system exits.

8. The method according to claim 1, characterized in that Performing a third consistency process on the sub-service call request in the second specific state in the local service execution history table includes: During the first consistency processing and the second consistency processing, the third consistency processing is performed synchronously.

9. The method according to claim 1, characterized in that: The method further comprises, Performing fourth consistency processing on the sub-service call request in the second specific state in the local service execution history table; Return to the first consistency processing step, and receive the service execution result fed back by the sub-service providing system according to the fourth consistency processing.

10. The method according to claim 9, characterized in that The fourth consistency processing of the sub-service call request in the second specific state in the local service execution history table further includes: Extracting sub-service call requests in the local service execution history table that are in a timeout state and a failed state; The extracted sub-service call requests are converted into a data verification file and sent to the sub-service providing system; The receiving of the service execution result fed back by the sub-service providing system according to the fourth consistency processing further includes: Receive the service execution result fed back by the sub-service providing system after comparing the data verification file with the service execution status table.

11. A distributed system business data consistency processing system, characterized in that Including service calling system and sub-service providing system; The service calling system further comprises: A sub-service call request generating unit, used to generate at least one sub-service call request according to business requirements and send it to a corresponding sub-service providing system; A first consistency processing unit, configured to perform a first consistency processing according to the service execution result fed back by the sub-service providing system, and record the state of the sub-service call request after the first consistency processing in a local service execution history table; A second consistency processing unit, configured to perform a second consistency processing on the sub-service call request in the local service execution history table that has undergone the first consistency processing and is in the first specific state, and to update the state of the sub-service call request in the local service execution history table according to the service execution result of the sub-service providing system; A third consistency processing unit, configured to perform a third consistency processing on the sub-service call request in the second specific state in the local service execution history table; Returning to the first consistency processing unit, receiving the service execution result fed back by the sub-service providing system according to the third consistency processing; The second consistency processing unit is further used to generate a query request for the sub-service call request in the local service execution history table whose status is a timeout state; send the query request to the corresponding sub-service providing system; and receive the service execution result fed back by the corresponding sub-service providing system; The third consistency processing unit is further used to read the sub-service call request in the local service execution history table with a timeout status or a failure status; send the read sub-service call request to the message queue; the sub-service providing system obtains the sub-service call request in the message queue; the sub-service providing system executes the sub-service call request; and receives the service execution result of the sub-service providing system.

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

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

Images