Transaction consistency verification method and device of distributed system, electronic equipment and storage medium

Abstract

The invention discloses a transaction consistency verification method and device of a distributed system, electronic equipment and a storage medium, and relates to the technical field of data management, and the disclosed transaction consistency verification method of the distributed system comprises the steps that when an execution request of a target transaction is received, a state flag of the target transaction is updated in a preset transaction coordination table; sending transaction execution data to a target server corresponding to the target transaction according to the execution request, and monitoring whether response data returned by the target server is received within a preset time; when the response data is not received, sending inquiry information for the target transaction to a transaction checking interface of the target server, and receiving a transaction landing state returned by the target server; and updating a state flag of the target transaction in the transaction coordination table according to the transaction landing state. The stability and reliability of the distributed system can be improved.

Description

Technical Field

[0001] The present application relates to the field of data management technology, and in particular to a transaction consistency verification method, device, electronic device and storage medium for a distributed system. Background Art

[0002] In today's highly information-based era, distributed systems, as a key architecture supporting large-scale data processing, high availability and load balancing, are becoming increasingly important.

[0003] Currently, in a distributed system, when a client calls multiple servers, transaction inconsistencies between the client and the servers may easily occur due to factors such as network delay fluctuations and server failures, which in turn affects the stability and reliability of the system.

[0004] In summary, how to improve the stability and reliability of distributed systems has become a technical problem that needs to be solved urgently in this field. Summary of the invention

[0005] The main purpose of this application is to provide a transaction consistency verification method, device, electronic device and storage medium for a distributed system, aiming to improve the stability and reliability of the distributed system by solving the problem of transaction inconsistency between the client and each server in the distributed system.

[0006] To achieve the above objectives, the present application proposes a transaction consistency verification method for a distributed system, the method comprising:

[0007] When receiving an execution request of a target transaction, updating a status flag of the target transaction in a preset transaction coordination table;

[0008] Sending transaction execution data to a target server corresponding to the target transaction according to the execution request, and monitoring whether response data returned by the target server is received within a preset time;

[0009] When the response data is not received, sending inquiry information for the target transaction to the transaction verification interface of the target server, and receiving the transaction landing status returned by the target server;

[0010] The status flag of the target transaction in the transaction coordination table is updated according to the transaction landing status.

[0011] In one embodiment, the step of updating the status flag of the target transaction in the transaction coordination table according to the transaction landing status includes:

[0012] When the transaction landing status is landing successfully, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0013] When the transaction landing status is landing in progress, updating the status flag of the target transaction in the transaction coordination table to a pending flag;

[0014] When the transaction landing status is failure, the status flag of the target transaction in the transaction coordination table is updated to a failure flag.

[0015] In one embodiment, after the step of updating the status flag of the target transaction in the transaction coordination table to a failure flag when the transaction landing status is a failure, the step further includes:

[0016] Obtaining the number of retries of the target transaction, and comparing the number of retries with a preset retry threshold;

[0017] When the number of retries does not exceed the retry threshold, the transaction execution data is sent to the target server again, and the state flag of the target transaction in the transaction coordination table is updated to a pending flag;

[0018] When the number of retries exceeds the retry threshold, the status flag of the target transaction in the transaction coordination table is maintained as a failure flag.

[0019] In one embodiment, the step of updating the status flag of the target transaction in the preset transaction coordination table includes:

[0020] Based on the optimistic locking mechanism, in a preset transaction coordination table, the status flag of the target transaction is updated from a pending flag to a processing flag;

[0021] Whether the update operation is successful is confirmed according to the return value of the update operation, wherein the update operation is an operation of updating the status flag of the target transaction.

[0022] In one embodiment, before the step of sending the transaction execution data to the target server corresponding to the target transaction according to the execution request, the step further includes:

[0023] Acquire transaction execution data of the target transaction according to the execution request;

[0024] An expected verification check is performed on the transaction execution data to determine the data rationality of the target transaction.

[0025] In one embodiment, after the step of monitoring whether the response data returned by the target server is received within a preset time, the method further includes:

[0026] When the response data is received, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0027] The transaction data of the target data is updated and recorded.

[0028] In one embodiment, the method further comprises:

[0029] Determine a server type of the target server, the server type being a core server or a non-core server;

[0030] When the target server is the core server, if the status flag of the target transaction is a failure flag, the transaction execution process is blocked, and an abnormal prompt message is output to prompt that the transaction execution is abnormal;

[0031] When the target server is a non-core server, if the status flag of the target transaction is a failure flag, the transaction execution process is continued.

[0032] In addition, to achieve the above purpose, the present application also proposes a transaction consistency verification device for a distributed system, and the transaction consistency verification device for a distributed system includes:

[0033] A first status update module, configured to update a status flag of a target transaction in a preset transaction coordination table upon receiving an execution request of the target transaction;

[0034] A response detection module, used to send transaction execution data to the target server corresponding to the target transaction according to the execution request, and monitor whether response data returned by the target server is received within a preset time;

[0035] A status query module, used for sending inquiry information for the target transaction to the transaction verification interface of the target server when the response data is not received, and receiving the transaction landing status returned by the target server;

[0036] The second status update module is used to update the status flag of the target transaction in the transaction coordination table according to the transaction landing status.

[0037] In addition, to achieve the above objectives, the present application also proposes an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the transaction consistency verification method for a distributed system as described above.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the transaction consistency verification method of the distributed system as described above are implemented.

[0039] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the transaction consistency verification method of the distributed system as described above.

[0040] The present application proposes a transaction consistency verification method for a distributed system. When an execution request for a target transaction is received, the status flag of the target transaction is first updated in a pre-configured transaction coordination table, which serves as the starting point of the transaction processing flow and the basis for status tracking; then, the transaction execution data of the target transaction is sent to the corresponding target server, and it is monitored whether the response data from the target server is successfully received within a preset time; if the response data from the target server is not received on time, an inquiry message is actively sent to the transaction verification interface of the target server to inquire about the actual processing status of the target transaction, that is, whether the target transaction has been successfully implemented; finally, according to the transaction implementation status returned from the target server, the status flag of the target transaction in the transaction coordination table is updated again, thereby ensuring that all target transaction participants in the system maintain a consistent understanding of the final status of the target transaction.

[0041] In summary, this application ensures that every step in the transaction processing process is clearly recorded and verified through real-time updating and status tracking of the transaction coordination table. Even in the face of abnormal situations, the transaction implementation status can be queried through the active inquiry mechanism to accurately determine the implementation result of the transaction, and timely discover transaction execution interruptions or delays caused by network delay fluctuations or server failures, effectively avoiding system crashes or data errors that may be caused by inconsistent transaction status, thereby improving the overall stability and reliability of the distributed system. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0044] Figure 1 This is a schematic diagram of the business processing flow of a traditional distributed system;

[0045] Figure 2 A flowchart of a transaction consistency verification method for a distributed system according to the present invention;

[0046] Figure 3 A schematic diagram of a transaction status update process provided in Example 1 of a transaction consistency verification method for a distributed system of the present application;

[0047] Figure 4 A schematic diagram of a process flow of a target transaction under normal conditions provided in Embodiment 2 of the transaction consistency verification method for a distributed system of the present application;

[0048] Figure 5 A flow chart of the case where the target server responds timeout provided in the second embodiment of the transaction consistency verification method of the distributed system of the present application;

[0049] Figure 6 A schematic diagram of a transaction processing flow of a client coordinating multiple servers provided in Example 2 of a transaction consistency verification method for a distributed system of the present application;

[0050] Figure 7 This is a schematic diagram of the module structure of a transaction consistency verification device of a distributed system according to an embodiment of the present application;

[0051] Figure 8 Schematic diagram of the device structure of the hardware operating environment involved in the transaction consistency verification method of the distributed system in the embodiment of the present application.

[0052] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0053] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0054] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0055] The main solution of the embodiment of the present application is: when an execution request of a target transaction is received, the status flag of the target transaction is updated in a preset transaction coordination table; transaction execution data is sent to the target server corresponding to the target transaction according to the execution request, and whether response data returned by the target server is received within a preset time is monitored; when the response data is not received, query information for the target transaction is sent to the transaction verification interface of the target server, and the transaction landing status returned by the target server is received; and the status flag of the target transaction in the transaction coordination table is updated according to the transaction landing status.

[0056] Currently, in a distributed system, when a client calls multiple servers, it is easy for inconsistent transactions between the client and the servers to occur due to factors such as network delay fluctuations and server failures, which in turn affects the stability and reliability of the system.

[0057] For example, the business process of traditional distributed systems is as follows Figure 1 As described above, when the client initiates a call to the server, the transactions of both parties need to trigger the change of the STATE flag of their respective local transaction update fields from 0 to 1. However, due to the instantaneous instability of the network, the client fails to call the server, and the server may fail to capture this request, resulting in the failure to synchronize the transaction states of both parties, thus falling into a situation of data inconsistency.

[0058] The embodiment of the present application provides a solution, which ensures that each step in the transaction processing process is clearly recorded and verified through real-time updating and status tracking of the transaction coordination table. Even in the face of abnormal situations, the transaction implementation status can be queried through the active inquiry mechanism to accurately determine the implementation result of the transaction, and transaction execution interruptions or delays caused by network delay fluctuations or server failures can be discovered in a timely manner, effectively avoiding system crashes or data errors that may be caused by inconsistent transaction status, thereby improving the overall stability and reliability of the distributed system.

[0059] It should be noted that the execution subject of this embodiment can be an electronic device with data processing, network communication and program running functions, such as a computer, a mobile phone, a tablet, etc., or an electronic device capable of realizing the above functions, etc. The following takes the client in a distributed system as an example to illustrate this embodiment and the following embodiments.

[0060] Based on this, the present application embodiment provides a transaction consistency verification method for a distributed system, referring to Figure 2 , Figure 2 This is a flow chart of the first embodiment of the transaction consistency verification method of the distributed system of the present application.

[0061] In this embodiment, the transaction consistency verification method of the distributed system includes steps S10 to S40:

[0062] Step S10, when receiving the execution request of the target transaction, updating the status flag of the target transaction in the preset transaction coordination table;

[0063] It should be noted that, in this embodiment, the target transaction refers to a series of operations or data changes that need to be performed across multiple servers in a distributed system. These operations or changes are managed and controlled as a whole to ensure data consistency and integrity; the transaction coordination table is a data structure or database table used by the client to record and manage the status of all transactions in a distributed system. It contains information such as the transaction's unique identifier, current status, participating servers, etc., and is the basis for transaction consistency verification and status tracking.

[0064] When receiving the execution request of the target transaction, the client will first update the status flag of the target transaction in its pre-defined and configured transaction coordination table, which serves as the starting point of the transaction processing flow and the basis for status tracking.

[0065] For example, in a feasible implementation, the transaction coordination table is defined as follows:

[0066]

[0067] In actual application scenarios, a business transaction includes multiple transactions, and each transaction is processed by a different server in the distributed system, that is, a business transaction includes multiple target transactions, and each target transaction corresponds to a different server. The client records the business serial number, unique identifier, coordination status, coordination type, number of retries, error information, actual status, last modification time of the data, and submission data for each target transaction in its own configured transaction coordination table to track the life cycle of each target transaction.

[0068] For any target transaction in the business processing process, the update process of its actual status in the transaction coordination table is as follows: Figure 3 As shown, when the execution request of the target transaction is received, the target transaction is started to be executed, and its status flag is updated from W (indicating pending) to R (indicating processing); after the target transaction is successfully executed, its status flag is updated from R to S (indicating successful processing); after the target transaction fails to execute, it is determined whether the number of retries of the target transaction exceeds the preset retry number threshold; if not, its status flag is updated to W for a new execution; if the number of retries exceeds the retry number, its status flag is updated to E (indicating processing failure).

[0069] Step S20, sending transaction execution data to the target server corresponding to the target transaction according to the execution request, and monitoring whether response data returned by the target server is received within a preset time;

[0070] It should be noted that the transaction execution data is specific data or instructions that need to be sent to the target server for processing in order to complete the target transaction. The execution data contains all necessary information required for the execution of the target transaction.

[0071] The transaction execution data of the target transaction is sent to the corresponding target server, and the response data from the target server is monitored to ensure timely communication and feedback during the transaction execution process.

[0072] Step S30, when the response data is not received, sending inquiry information for the target transaction to the transaction verification interface of the target server, and receiving the transaction landing status returned by the target server;

[0073] It should be noted that the transaction verification interface is an interface provided by the target server to the client for querying the transaction processing status. When the client needs to confirm whether the target transaction has been successfully executed or needs to obtain the latest status of the transaction, it sends an inquiry request to the target server through this interface; the transaction landing status refers to the final status of the transaction after it is actually executed on the target server.

[0074] If the target server's response data is not received within the preset time, active inquiry measures are taken to send inquiry information to the target server through a specific transaction verification interface to obtain the latest processing status of the target transaction, that is, the transaction landing status.

[0075] For example, after receiving the query request sent by the client, the transaction verification interface of the target server returns the current status information of the target transaction, and the status information includes the transaction identifier, transaction type, current status, and possible error information. At the same time, in order to further improve the stability of the system, the request frequency of the transaction verification interface is limited by a current limiting algorithm, wherein the current limiting algorithm is a token bucket or leaky bucket algorithm to prevent server crashes caused by a large number of concurrent requests; when the system load is too high or resources are insufficient, the transaction verification interface is downgraded, and the downgrade includes adjusting the returned status information to return cached data, partial data, or default values ​​to ensure the availability of the service; when the target server fails continuously for a preset number of times, the fuse for the target server is opened, and subsequent transaction execution requests directly return failures until the target server returns to normal and then the fuse is closed.

[0076] Step S40: updating the status flag of the target transaction in the transaction coordination table according to the transaction landing status.

[0077] According to the transaction landing status received from the target server, the status flag of the corresponding target transaction in the transaction coordination table is updated again to ensure that all participants in the distributed system have a consistent understanding of the final status of the transaction.

[0078] In summary, the embodiments of the present application ensure that each step in the transaction processing process is clearly recorded and verified through real-time updating and status tracking of the transaction coordination table. Even in the face of abnormal situations, the transaction implementation status can be queried through the active inquiry mechanism to accurately determine the implementation result of the transaction, and transaction execution interruptions or delays caused by network delay fluctuations or server failures can be discovered in a timely manner, effectively avoiding system crashes or data errors that may be caused by inconsistent transaction status, thereby improving the overall stability and reliability of the distributed system.

[0079] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. On this basis, step S40 can include steps S401 to S403:

[0080] Step S401, when the transaction landing status is landing successfully, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0081] When the transaction landing status is confirmed to be successful, the client will update the status flag of the target transaction in the transaction coordination table to a success flag, indicating that the target transaction has been successfully completed and all participants can perform subsequent operations or data processing based on this status.

[0082] Step S402, when the transaction landing status is landing in progress, updating the status flag of the target transaction in the transaction coordination table to a pending flag;

[0083] If the transaction landing status is landing, it means that the transaction is still in the process of execution, but has not yet reached the final completion state. At this time, the client updates the status flag of the target transaction in the transaction coordination table to a pending flag for subsequent monitoring.

[0084] Step S403: when the transaction landing status is failure, update the status flag of the target transaction in the transaction coordination table to a failure flag.

[0085] If the transaction landing status is failed, the error handling process is entered, and the status flag of the target transaction in the transaction coordination table is updated to a failure flag to indicate that the transaction execution failed. At the same time, the client can decide whether to start the retry mechanism based on business needs.

[0086] In a feasible embodiment, step S403 may further include steps S404 to S406:

[0087] Step S404, obtaining the number of retries of the target transaction, and comparing the number of retries with a preset retry threshold;

[0088] Before starting the retry mechanism, first obtain the retry count of the target transaction and compare it with the preset retry threshold to avoid unlimited retry operations, thereby wasting system resources and time.

[0089] Step S405, when the number of retries does not exceed the retry threshold, sending the transaction execution data to the target server again, and updating the state flag of the target transaction in the transaction coordination table to a pending flag;

[0090] If the number of retries does not exceed the preset retry threshold, the transaction execution data is sent to the target server again, and the state flag of the target transaction in the transaction coordination table is updated to a pending flag to wait for a new execution result.

[0091] Step S406: When the number of retries exceeds the retry threshold, the status flag of the target transaction in the transaction coordination table is maintained as a failure flag.

[0092] If the number of retries has reached or exceeded the preset retry threshold, the transaction will no longer be attempted to be re-executed, but the status mark of the target transaction in the transaction coordination table will be maintained as a failure mark. At this time, manual intervention is performed and remedial measures are taken according to the transaction execution scenario.

[0093] In a feasible embodiment, step S10 may include steps S101 to S102:

[0094] Step S101, updating the status flag of the target transaction from a pending flag to a processing flag in a preset transaction coordination table based on an optimistic locking mechanism;

[0095] It should be noted that the optimistic locking mechanism is a concurrency control technology based on an optimistic assumption that conflicts between multiple transactions (i.e., modifying the same data at the same time) are rare when multiple transactions are executed concurrently. Therefore, the optimistic locking mechanism allows transactions to start without immediately locking the accessed data resources. Instead, when the data is submitted for update, a certain mechanism is used to check whether the data has been modified by other transactions after reading.

[0096] Based on the optimistic locking mechanism, an attempt is made to update the status flag of the target transaction from the pending flag to the processing flag in the preset transaction coordination table to indicate that the target transaction has entered the processing stage to avoid concurrent modifications.

[0097] Step S102: confirming whether the update operation is successful according to the return value of the update operation, wherein the update operation is an operation of updating the status flag of the target transaction.

[0098] The update operation is confirmed to be successful based on the return value of the update operation, where the update operation refers to the operation of changing the target transaction status flag from the pending flag to the processing flag. If the return value is greater than zero, it indicates that the update is successful, which means that the client has successfully obtained the processing right of the target transaction. If the return value is less than zero, it indicates that the update failed, and the client needs to take corresponding measures according to the specific design of the system, such as retrying, rolling back or recording errors.

[0099] In this way, in this embodiment, the transaction status in the transaction coordination table is quickly updated through the optimistic lock mechanism, which reduces lock contention and waiting time and improves the efficiency of the transaction processing flow.

[0100] In a feasible embodiment, before step S20, steps A10 to A20 may be further included:

[0101] Step A10, acquiring transaction execution data of the target transaction according to the execution request;

[0102] Based on the received target transaction execution request, all transaction execution data required for the target transaction are extracted or constructed from the request body, database, cache or other data sources. The transaction execution data usually includes key information such as specific business rules, operation objects, operation parameters, etc. required to execute the transaction.

[0103] Step A20, performing an expected verification check on the transaction execution data to determine the rationality of the data of the target transaction.

[0104] After obtaining the transaction execution data, the client will perform a series of expected verification checks on it to ensure the rationality, completeness and consistency of the transaction execution data, so as to avoid transaction failures or system abnormalities due to data errors.

[0105] In a feasible implementation, the expected verification check of the transaction execution data includes data format verification, business rule verification, data consistency verification and dependency verification. Among them, the data format verification refers to checking whether the format of the transaction execution data meets the predefined requirements, such as date format, number range, etc.; the business rule verification refers to verifying whether the transaction execution data meets specific conditions or constraints according to business logic and rules. For example, in a transfer transaction, it is necessary to check whether the balance of the transfer-out account is sufficient; the data consistency verification refers to checking whether the transaction execution data is consistent between different servers for transactions that need to be executed across multiple servers; the dependency verification refers to determining whether the execution of the target transaction depends on the results of other preceding transactions or conditions. If there are dependent transactions or conditions, verify whether the dependency has been met.

[0106] Thus, the client can ensure that the transaction execution data is accurate and meets business requirements before sending it to the target server, ensuring the accuracy and completeness of transaction-related data and reducing repeated processing and system burden caused by data errors.

[0107] In a feasible embodiment, step S20 may further include steps B10 to B20:

[0108] Step B10, when receiving the response data, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0109] The client receives the response data from the target server, indicating that the target transaction has completed the corresponding processing on the target server. The client can update the status flag of the target transaction in its internally maintained transaction coordination table to a success flag to ensure the synchronization and accuracy of the transaction status.

[0110] Step B20: update the transaction data of the target data and record it.

[0111] Update the transaction data associated with the target data and record the transaction data, which includes the execution time, result details, log information, etc. of the target transaction, to facilitate transaction tracking and troubleshooting.

[0112] In one example, the target transaction normally proceeds as follows Figure 4 As shown, the client updates its status flag from W to R through optimistic locking. When the update return value is less than zero, it indicates that the update has failed. When the update return value is greater than zero, the client performs an expected verification check to ensure the accuracy of the data. After the verification check passes, the client uploads the relevant data of the target transaction to the target server, receives the normal response from the server, and updates the status flag of the target transaction to S, that is, COMBINESTATE=YS, indicating that the transaction is executed successfully, updates the local transaction data related to the target transaction, and ensures data consistency by tracking the progress of the transaction.

[0113] In another example, since requests in distributed systems are often affected by network delays and the instantaneous status of server nodes, when the server fails to send a response within the expected time, this may cause uncertainty in the client's transaction status executed by the server. To this end, a dedicated transaction verification interface is set up on the server side. This interface allows the client to confirm and retry the transaction execution status of the server, ensuring that the reliability and consistency of the transaction can be maintained even in the face of unforeseen external interference. For example, Figure 5As shown, when the target server responds overtime, the client sends an inquiry message to the transaction verification interface of the target server, and the target server returns the transaction landing status based on the message. When the transaction landing status is successful, the status flag of the target transaction in the transaction coordination table is updated to a success flag, that is, COMBINESTATE=YS, indicating that the transaction is successfully executed, and the local transaction data related to the target transaction is updated; when the transaction landing status is in progress, the status flag of the target transaction in the transaction coordination table is updated to a pending flag, that is, COMBINESTATE=YP; when the transaction landing status is failed, it is determined whether the target transaction exceeds the number of retries. If not, its status flag is updated to a failed state, and then the target transaction is processed again based on the retry mechanism. If the number of retries exceeds the number of retries, it is determined that the transaction has failed. For the case where the target server returns a transaction landing status of failure, in another embodiment, the status flag of the target transaction in the transaction coordination table may be updated to a failure flag first, and then it is determined whether it exceeds the number of retries. When the number of retries does not exceed the retry threshold, the transaction execution data is sent to the target server again, and the status flag of the target transaction in the transaction coordination table is updated to a pending flag; when the number of retries exceeds the retry threshold, the status flag of the target transaction in the transaction coordination table is maintained as a failure flag.

[0114] Therefore, compensatory measures are taken for servers that encounter abnormalities to ensure smooth transaction processing and achieve the goal of global data consistency.

[0115] In a feasible embodiment, the transaction consistency verification method of the distributed system may further include steps C10 to C30:

[0116] Step C10, determining the server type of the target server, the server type being a core server or a non-core server;

[0117] Identify and determine the type of target server, which can be divided into core servers and non-core servers. Core servers refer to servers in distributed systems that carry key business logic or data and whose stability and reliability are critical to the overall system. Non-core servers refer to servers in distributed systems that handle relatively minor or auxiliary tasks.

[0118] Step C20, when the target server is the core server, if the status flag of the target transaction is a failure flag, blocking the transaction execution process, and outputting abnormal prompt information to prompt the transaction execution abnormality;

[0119] If the target server is identified as a core server and the status flag of the current target transaction is a failure flag, the client will block the further execution process of the transaction and immediately output an exception prompt message to the user to prompt the transaction execution exception.

[0120] Step C30, when the target server is a non-core server, if the status flag of the target transaction is a failure flag, then continue the transaction execution process.

[0121] If the target server is a non-core server and the status mark of the target transaction is a failure mark, the client can allow the transaction execution process to continue to reduce the impact of non-critical service interruptions on the overall system performance.

[0122] For example, in a distributed system, requests often require multiple servers to jointly process data to complete the processing of a business. When a server node fails to send a response within the expected time, this may cause uncertainty in the client's transaction status for subsequent server executions. In this embodiment, when a core critical service is abnormal, the client completes the verification, blocks the subsequent coordination process, and promptly returns the abnormal information to the caller; when a non-core server is abnormal, only the current server coordination record status is updated. For subsequent situations where the server still has the possibility of operation, the client will continue the transaction coordination process.

[0123] For example, the client coordinates the transaction processing flow of multiple servers such as Figure 6As shown, the process involves core servers and non-core servers. The core server is responsible for processing the first target transaction in the business, and the non-core server is responsible for processing the second target transaction in the business. The client updates the status flag of the first target transaction from W to R through optimistic locking. When the update return value is greater than zero, the client performs an expected verification check to ensure the accuracy of the data. After the verification check passes, the relevant data of the first target transaction is uploaded to the core server. If the core server responds with a timeout, an inquiry message is sent to the transaction verification interface of the core server, and the core server returns the transaction landing status based on the message. When the transaction landing status is successful, the client can continue to upload data to the non-core server; when the transaction landing status is in progress, the status flag of the first target transaction in the transaction coordination table is updated to a pending flag and the subsequent steps are continued; when the transaction landing status is failed, after updating its status flag to a failed state, the further execution process of the transaction is blocked, and an abnormal prompt message is immediately output to the user. If the core server responds normally or determines that the first target transaction has been successfully implemented, the data will be uploaded to the non-core server. If the non-core server responds for a timeout, an inquiry message will be sent to the transaction verification interface of the non-core server, and the non-core server will return the transaction implementation status based on the message. At this time, the implementation status of the second target transaction is returned. When the transaction implementation status is successful, the status flag of the second target transaction in the transaction coordination table is updated to a success flag; when the transaction implementation status is in progress, the status flag of the second target transaction in the transaction coordination table is updated to a pending flag and the subsequent steps are continued; when the transaction implementation status is a failure, it is determined whether the second target transaction exceeds the number of retries. If not, its status flag is updated to a failed state, and the target transaction is processed again based on the retry mechanism. If the number of retries is exceeded, it is determined that the transaction implementation of the second target transaction has failed, but the transaction execution process is allowed to continue.

[0124] In this way, by distinguishing between core servers and non-core servers and handling transaction failures differently, the overall stability of the distributed system in the face of failures is further improved.

[0125] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the transaction consistency verification method of the distributed system of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0126] The present application also provides a transaction consistency verification device for a distributed system. Figure 7 , the transaction consistency verification device of the distributed system includes:

[0127] A first status updating module 10, configured to update a status flag of a target transaction in a preset transaction coordination table upon receiving an execution request of the target transaction;

[0128] A response detection module 20 is used to send transaction execution data to a target server corresponding to the target transaction according to the execution request, and monitor whether response data returned by the target server is received within a preset time;

[0129] The status query module 30 is used to send inquiry information for the target transaction to the transaction verification interface of the target server when the response data is not received, and receive the transaction landing status returned by the target server;

[0130] The second status updating module 40 is used to update the status flag of the target transaction in the transaction coordination table according to the transaction landing status.

[0131] Optionally, the second state updating module 40 is further configured to:

[0132] When the transaction landing status is landing successfully, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0133] When the transaction landing status is landing in progress, updating the status flag of the target transaction in the transaction coordination table to a pending flag;

[0134] When the transaction landing status is failure, the status flag of the target transaction in the transaction coordination table is updated to a failure flag.

[0135] Optionally, the second state updating module 40 is further configured to:

[0136] Obtaining the number of retries of the target transaction, and comparing the number of retries with a preset retry threshold;

[0137] When the number of retries does not exceed the retry threshold, the transaction execution data is sent to the target server again, and the state flag of the target transaction in the transaction coordination table is updated to a pending flag;

[0138] When the number of retries exceeds the retry threshold, the status flag of the target transaction in the transaction coordination table is maintained as a failure flag.

[0139] Optionally, the first state updating module 10 is further configured to:

[0140] Based on the optimistic locking mechanism, in a preset transaction coordination table, the status flag of the target transaction is updated from a pending flag to a processing flag;

[0141] Whether the update operation is successful is confirmed according to the return value of the update operation, wherein the update operation is an operation of updating the status flag of the target transaction.

[0142] Optionally, the transaction consistency verification device of the distributed system further includes a data verification module (not shown), and the data verification module is used to:

[0143] Acquire transaction execution data of the target transaction according to the execution request;

[0144] An expected verification check is performed on the transaction execution data to determine the data rationality of the target transaction.

[0145] Optionally, the transaction consistency verification device of the distributed system further includes a third state updating module (not shown), and the third state updating module is used to:

[0146] When the response data is received, updating the status flag of the target transaction in the transaction coordination table to a success flag;

[0147] The transaction data of the target data is updated and recorded.

[0148] Optionally, the transaction consistency verification device of the distributed system further includes a type determination module (not shown), and the type determination module is used to:

[0149] Determine a server type of the target server, the server type being a core server or a non-core server;

[0150] When the target server is the core server, if the status flag of the target transaction is a failure flag, the transaction execution process is blocked, and an abnormal prompt message is output to prompt that the transaction execution is abnormal;

[0151] When the target server is a non-core server, if the status flag of the target transaction is a failure flag, the transaction execution process is continued.

[0152] The transaction consistency verification device for a distributed system provided in the embodiment of the present application adopts the transaction consistency verification method for a distributed system in the above embodiment, which can improve the stability and reliability of the distributed system. Compared with the prior art, the beneficial effects of the transaction consistency verification device for a distributed system provided in the embodiment of the present application are the same as the beneficial effects of the transaction consistency verification method for a distributed system provided in the above embodiment, and other technical features in the transaction consistency verification device for a distributed system are the same as the features disclosed in the transaction consistency verification method for a distributed system in the above embodiment, which will not be described in detail here.

[0153] An embodiment of the present application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the transaction consistency verification method of the distributed system in the above-mentioned embodiment one.

[0154] Reference below Figure 8 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present application. The electronic device in the embodiments of the present application may include but is not limited to mobile terminals such as laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0155] like Figure 8 As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the electronic device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0156] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0157] The electronic device provided in the embodiment of the present application adopts the transaction consistency verification method of the distributed system in the above embodiment, which can improve the stability and reliability of the distributed system. Compared with the prior art, the beneficial effects of the electronic device provided in the embodiment of the present application are the same as the beneficial effects of the transaction consistency verification method of the distributed system provided in the above embodiment, and other technical features in the electronic device are the same as the features disclosed in the transaction consistency verification method of the distributed system in the previous embodiment, which will not be repeated here.

[0158] It should be understood that the various parts disclosed in the embodiments of the present application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0159] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0160] An embodiment of the present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, wherein the computer-readable program instructions are used to execute the transaction consistency verification method of the distributed system in the above-mentioned embodiment.

[0161] The computer-readable storage medium provided in the embodiment of the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0162] The computer-readable storage medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0163] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by an electronic device, the electronic device: when receiving an execution request of a target transaction, updates the status flag of the target transaction in a preset transaction coordination table; sends transaction execution data to a target server corresponding to the target transaction according to the execution request, and monitors whether response data returned by the target server is received within a preset time; when the response data is not received, sends inquiry information for the target transaction to the transaction verification interface of the target server, and receives the transaction landing status returned by the target server; and updates the status flag of the target transaction in the transaction coordination table according to the transaction landing status.

[0164] The computer program code for performing the operation of the embodiment of the present application can be written in one or more programming languages ​​or a combination thereof, and the above-mentioned programming languages ​​include object-oriented programming languages, such as Java, Smalltalk, C++, and also include conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0165] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0166] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0167] The readable storage medium provided in the embodiment of the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the transaction consistency verification method of the above-mentioned distributed system, and can improve the stability and reliability of the distributed system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the embodiment of the present application are the same as the beneficial effects of the transaction consistency verification method of the distributed system provided in the above-mentioned embodiment, and will not be repeated here.

[0168] The present application also provides a computer program product, including a computer program, which implements the steps of the transaction consistency verification method of the distributed system as described above when executed by a processor.

[0169] The computer program product provided by this application can solve the technical problem of transaction consistency verification of distributed systems. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the transaction consistency verification method of the distributed system provided by the above embodiment, which will not be repeated here.

[0170] The above are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A transaction consistency verification method for a distributed system, characterized in that: The method comprises: When receiving an execution request of a target transaction, updating a status flag of the target transaction in a preset transaction coordination table; Sending transaction execution data to a target server corresponding to the target transaction according to the execution request, and monitoring whether response data returned by the target server is received within a preset time; When the response data is not received, sending inquiry information for the target transaction to the transaction verification interface of the target server, and receiving the transaction landing status returned by the target server; The status flag of the target transaction in the transaction coordination table is updated according to the transaction landing status.

2. The transaction consistency verification method of a distributed system according to claim 1, characterized in that: The step of updating the status flag of the target transaction in the transaction coordination table according to the transaction landing status includes: When the transaction landing status is landing successfully, updating the status flag of the target transaction in the transaction coordination table to a success flag; When the transaction landing status is landing in progress, updating the status flag of the target transaction in the transaction coordination table to a pending flag; When the transaction landing status is failure, the status flag of the target transaction in the transaction coordination table is updated to a failure flag.

3. The transaction consistency verification method of a distributed system according to claim 2, characterized in that: After the step of updating the status flag of the target transaction in the transaction coordination table to a failure flag when the transaction landing status is a failure, the method further includes: Obtaining the number of retries of the target transaction, and comparing the number of retries with a preset retry threshold; When the number of retries does not exceed the retry threshold, the transaction execution data is sent to the target server again, and the state flag of the target transaction in the transaction coordination table is updated to a pending flag; When the number of retries exceeds the retry threshold, the status flag of the target transaction in the transaction coordination table is maintained as a failure flag.

4. The transaction consistency verification method of a distributed system according to claim 1, characterized in that: The step of updating the status flag of the target transaction in the preset transaction coordination table includes: Based on the optimistic locking mechanism, in a preset transaction coordination table, the status flag of the target transaction is updated from a pending flag to a processing flag; Whether the update operation is successful is confirmed according to the return value of the update operation, wherein the update operation is an operation of updating the status flag of the target transaction.

5. The transaction consistency verification method of a distributed system according to claim 1, characterized in that: Before the step of sending the transaction execution data to the target server corresponding to the target transaction according to the execution request, the step further includes: Acquire transaction execution data of the target transaction according to the execution request; An expected verification check is performed on the transaction execution data to determine the data rationality of the target transaction.

6. The transaction consistency verification method of a distributed system according to claim 1, characterized in that: After the step of monitoring whether the response data returned by the target server is received within a preset time, the method further includes: When the response data is received, updating the status flag of the target transaction in the transaction coordination table to a success flag; The transaction data of the target data is updated and recorded.

7. The transaction consistency verification method of a distributed system according to any one of claims 1 to 6, characterized in that: The method further comprises: Determine a server type of the target server, the server type being a core server or a non-core server; When the target server is the core server, if the status flag of the target transaction is a failure flag, the transaction execution process is blocked, and an abnormal prompt message is output to prompt that the transaction execution is abnormal; When the target server is a non-core server, if the status flag of the target transaction is a failure flag, the transaction execution process is continued.

8. A transaction consistency verification device for a distributed system, characterized in that: The device comprises: A first status update module, configured to update a status flag of a target transaction in a preset transaction coordination table upon receiving an execution request of the target transaction; A response detection module, used to send transaction execution data to the target server corresponding to the target transaction according to the execution request, and monitor whether response data returned by the target server is received within a preset time; A status query module, used for sending inquiry information for the target transaction to the transaction verification interface of the target server when the response data is not received, and receiving the transaction landing status returned by the target server; The second status update module is used to update the status flag of the target transaction in the transaction coordination table according to the transaction landing status.

9. An electronic device, characterized in that: The electronic device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the transaction consistency verification method for a distributed system as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the transaction consistency verification method of a distributed system as described in any one of claims 1 to 7 are implemented.

Images