Transaction data processing method and device based on distributed system, medium and product

Abstract

The invention discloses a transaction data processing method and device based on a distributed system, a medium and a product. The method comprises the following steps: inputting current transaction data into a transaction feature real-time analysis model to obtain a detection result; when the failure probability in the detection result is smaller than a probability threshold value, inputting the current transaction data into the distributed system, and processing the current transaction data cooperatively through each node in the distributed system; when the target node is abnormal for the current transaction data, intercepting a rollback operation executed by the target node for processing the abnormality, and inputting abnormal information into a decision model to obtain an abnormality processing decision; and after the target node is controlled to execute the exception handling decision, if the target node eliminates the exception state, indicating the distributed system to continue to process the current transaction data to obtain a processing result. According to the technical scheme provided by the embodiment of the invention, the normal transaction processing process of the distributed system can be ensured on the premise of reducing the use frequency of the data rollback operation to the greatest extent.

Description

Technical Field

[0001] This invention relates to the field of distributed technology, and in particular to a method, device, medium and product for processing transaction data based on a distributed system. Background Technology

[0002] With economic and technological development, bank transaction systems have become increasingly complex, and transaction volumes have grown significantly. To improve system operational capabilities and meet the daily transaction needs of core business systems, distributed transaction technology has been introduced into banking systems. Distributed transactions break down a complete business transaction into multiple sub-transactions, which are then executed independently on different nodes. Specific protocols and algorithms ensure the consistency of the final state of each sub-transaction.

[0003] In this system architecture, the service nodes in the platform's distributed architecture call each other, and the links can be very long. As transaction volume continues to increase, if any link in the execution fails, there will be a certain delay due to rollback, and the transaction risk will also increase. At the same time, distributed transactions rely on network communication to coordinate the operations of each node. Once network jitter, delay, or node failure occurs, such as the database server of a bank branch going down or the cross-regional dedicated line being interrupted, the transaction may not be able to be committed or rolled back normally, thus causing the transaction to fail. In addition, during the execution of distributed transactions, if there is a communication delay between nodes or network partitioning, data inconsistency may occur. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for processing transaction data based on a distributed system, which can ensure the normal transaction processing process of the distributed system while minimizing the frequency of data rollback operations.

[0005] According to one aspect of the present invention, a transaction data processing method based on a distributed system is provided, comprising:

[0006] The current transaction data to be processed is input into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system;

[0007] When the failure probability in the detection result is less than the probability threshold, the current transaction data is input into the distributed system, and the current transaction data is processed collaboratively by the nodes in the distributed system.

[0008] When a processing anomaly occurs on the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into the decision model to obtain the anomaly handling decision.

[0009] After the target node executes the exception handling decision, if it is determined that the target node has eliminated the exception state, the distributed system is instructed to continue processing the current transaction data until the transaction processing result is obtained.

[0010] According to another aspect of the present invention, a transaction data processing apparatus based on a distributed system is also provided, comprising:

[0011] The detection result acquisition module is used to input the current transaction data to be processed into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system;

[0012] The distributed processing module is used to input the current transaction data into the distributed system when the failure probability in the detection result is less than the probability threshold, and to process the current transaction data through the collaborative processing of the nodes in the distributed system.

[0013] The exception handling decision acquisition module is used to intercept the rollback operation performed by the target node in response to the exception when the target node encounters a processing exception for the current transaction data, and input the exception information into the decision model to obtain the exception handling decision.

[0014] The continued processing module is used to instruct the distributed system to continue processing the current transaction data until the transaction processing result is obtained after the target node has made an exception handling decision.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the transaction data processing method based on a distributed system as described in any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the transaction data processing method based on a distributed system as described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the transaction data processing method based on a distributed system as described in any embodiment of the present invention.

[0021] The technical solution of this invention involves inputting the current transaction data to be processed into a real-time transaction feature analysis model to obtain a detection result indicating whether the current transaction data will fail in the distributed system. When the failure probability in the detection result is less than a probability threshold, the current transaction data is input into the distributed system, and the nodes in the distributed system collaboratively process the current transaction data. When a processing anomaly occurs at the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into a decision model to obtain an anomaly handling decision. After controlling the target node to execute the anomaly handling decision, if it is determined that the target node has eliminated the anomaly state, then... This technique allows a distributed system to continue processing current transaction data until a transaction result is obtained. It effectively filters out transaction data with a high probability of anomalies before the data enters the distributed system. Furthermore, when transaction data enters the distributed system and anomalies occur, it attempts other anomaly handling strategies to eliminate the anomaly without first resorting to data rollback. This ensures the normal transaction processing of the distributed system while minimizing the frequency of data rollback operations, improving the processing performance of the distributed system, reducing the workload of manual intervention, and effectively avoiding the various problems and risks associated with data rollback operations in the distributed system.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0024] Figure 1 This is a flowchart of a transaction data processing method based on a distributed system according to an embodiment of the present invention;

[0025] Figure 2 This is a flowchart of another transaction data processing method based on a distributed system provided by an embodiment of the present invention;

[0026] Figure 3 This is a structural diagram of a specific application scenario to which this invention is applicable;

[0027] Figure 4 This is a schematic diagram of the structure of a transaction data processing device based on a distributed system according to an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of the structure of an electronic device that implements the transaction data processing method based on a distributed system according to an embodiment of the present invention. Detailed Implementation

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

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Figure 1 The flowchart illustrates a transaction data processing method based on a distributed system, which is applicable to situations where transaction data is processed collaboratively by various nodes (also referred to as services or service nodes) included in a distributed system. This method can be executed by a transaction data processing device based on a distributed system. This device can be implemented in hardware and / or software and is generally configured in an electronic device with data processing capabilities.

[0032] Correspondingly, such as Figure 1 As shown, the method may include:

[0033] S110. Input the current transaction data to be processed into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system.

[0034] In this embodiment, a distributed system processes the real-time generated transaction data (i.e., the current transaction data). This distributed system includes multiple nodes (or service nodes), which sequentially process the input transaction data to ultimately obtain a matching result. This transaction data can be understood as a digital record generated during a value transaction process, and it can be triggered by a transaction request.

[0035] In a specific example, the distributed system can be a banking system, and the transaction data can be a cross-border remittance transaction from currency A to currency B. Accordingly, the banking system processes the transaction data sequentially through internal front-end gateway nodes, account verification nodes, foreign exchange clearing nodes, cross-border settlement nodes, and accounting archiving nodes, circulating the processing results between nodes, and finally obtaining and outputting a transaction result matching the transaction data. In this embodiment, whenever current transaction data matching a transaction request is generated, it is not directly input into the distributed system as in existing technologies. Instead, the current transaction data is first input into a real-time transaction feature analysis model, which then obtains a detection result indicating whether the current transaction data will result in transaction processing failure in the distributed system.

[0036] The real-time transaction feature analysis model is a pre-trained machine learning model. Its input is the current transaction data or transaction features extracted from the current transaction data. The output detection result includes the probability of transaction processing failure in the distributed system. The transaction features in the current transaction data can be determined based on the specific data items contained within the current transaction data. For example, these transaction features may include: spatiotemporal features, transaction entity features, transaction type features, transaction asset quantification features, transaction flow features, and transaction compliance features, etc. This embodiment does not impose any limitations on these aspects.

[0037] S120. When the failure probability in the detection result is less than the probability threshold, the current transaction data is input into the distributed system, and the current transaction data is processed through the collaborative efforts of each node in the distributed system.

[0038] As mentioned earlier, after obtaining the failure probability output by the real-time transaction feature analysis model for the current transaction data, this failure probability can be compared with a preset probability threshold (e.g., 80% or 85%). When the failure probability is less than the probability threshold, it indicates that inputting the current transaction data into the distributed system for processing will have a high probability of success. In this case, the current transaction data can be directly input into the distributed system, and the nodes in the distributed system can collaboratively process the current transaction data.

[0039] In contrast, based on the above embodiments, after obtaining the detection result of whether the current transaction data will fail to process in the distributed system, the method may further include:

[0040] When the failure probability in the detection result is greater than or equal to the probability threshold, the current transaction data is prevented from being input into the distributed system, and transaction failure information is generated as feedback to the current transaction data.

[0041] In this optional implementation, when the failure probability is greater than or equal to the probability threshold, it means that the current transaction data will fail to be processed after being input into the distributed system. In this case, in order to avoid the data rollback operation introduced by the distributed system when the current transaction data fails to be processed, the current transaction data will no longer be input into the distributed system, but transaction failure information will be directly generated as the feedback result of the current transaction data.

[0042] By setting up the above, transaction data that is likely to be abnormal can be effectively filtered out before it enters the distributed system, reducing the frequency of data rollback operations in the distributed system and improving the execution efficiency of the distributed system.

[0043] S130. When the target node experiences a processing anomaly in response to the current transaction data, intercept the rollback operation performed by the target node in response to the processing anomaly, and input the anomaly information into the decision model to obtain the anomaly handling decision.

[0044] In this embodiment, after the current transaction data is input into the distributed system, each node in the distributed system processes the current transaction data sequentially. Upon successful processing, each node transmits its processing result along with the current transaction data to the next node in the order it was processed. This process continues until a node combines the processing results of zero, one, or more preceding nodes to generate a final processing result corresponding to the current transaction data and outputs it to the distributed system. This final processing result can be either a successful processing result or a failed processing result.

[0045] In related technologies, when a node in a distributed system experiences a processing error, a compensation mechanism of directly executing a rollback operation is employed. That is, starting from that node, the rollback operation is performed sequentially on each preceding node until all nodes in the distributed system return to their state before processing the current transaction data, effectively ensuring the consistency of data in cross-database and cross-service transactions.

[0046] In contrast, in this embodiment, once an abnormality is detected in the target node's processing of the current transaction data, the rollback operation instruction automatically triggered by the target node based on the aforementioned abnormality will be intercepted, thereby blocking the rollback operation triggered by the target node in response to the abnormality.

[0047] In other words, the technical solution of this invention uses the rollback operation as a last resort compensation mechanism. Before executing the rollback strategy, other methods are first attempted to recover from the processing anomaly of the target node. If recovery is successful, the distributed system can be controlled to continue processing the current transaction data, thereby minimizing the frequency of data rollback operations.

[0048] Specifically, we can first obtain the anomaly information generated by the target node when an anomaly occurs in processing the current transaction data. This information includes, for example, the time of the anomaly, the node's running status at the time of the anomaly, the anomaly type, and the location of the anomaly. After obtaining this anomaly information, we input it into the decision model to obtain an anomaly handling decision.

[0049] In this context, exception handling decisions can be understood as execution strategies that can be used to eliminate exceptions without performing data rollback operations. For example, these exception handling strategies can include: direct re-execution (also known as redo), re-execution after adjusting the input data according to a set format, re-execution after adding processing threads, reconnecting the node and re-execution, re-execution after modifying the configuration items set in the node, and re-execution after transferring to manual processing, etc.

[0050] The decision model is a pre-trained machine learning model. Its input is abnormal information, and its output is an anomaly handling decision derived from the abnormal information.

[0051] S140. After the target node executes the exception handling decision, if it is determined that the target node has eliminated the exception state, the distributed system is instructed to continue processing the current transaction data until the transaction processing result is obtained.

[0052] In this embodiment, after obtaining the anomaly handling strategy output by the decision model, the target node that has the anomaly is first controlled to directly execute the anomaly handling strategy, and it is detected whether the anomaly caused by the target node for the current transaction data can be eliminated after executing the anomaly handling strategy.

[0053] If it is determined that the processing exception can be eliminated, the current transaction data can be controlled to continue to be processed in the next node of the distributed system until all nodes have successfully processed the current transaction data, and then the final successfully processed transaction result is output. Alternatively, if an unavoidable processing exception occurs at a certain node, the final failed transaction result is output.

[0054] Accordingly, based on the above embodiments, after the target node executes the exception handling decision, it may further include:

[0055] If it is determined that the target node has not eliminated the abnormal state, the target node is instructed to perform a rollback operation for handling the abnormality.

[0056] In this embodiment, if it is determined that executing the exception handling strategy cannot eliminate the abnormal state of the target node, then it indicates that only data rollback can guarantee data consistency. When this occurs, the rollback operation, a common compensation mechanism in existing technologies, can be implemented. Through the above settings, when encountering an unavoidable abnormal state, a necessary rollback operation can be performed, using data rollback as a final fallback strategy to effectively ensure data consistency throughout the entire database or transaction system.

[0057] The technical solution of this invention involves inputting the current transaction data to be processed into a real-time transaction feature analysis model to obtain a detection result indicating whether the current transaction data will fail in the distributed system. When the failure probability in the detection result is less than a probability threshold, the current transaction data is input into the distributed system, and the nodes in the distributed system collaboratively process the current transaction data. When a processing anomaly occurs at the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into a decision model to obtain an anomaly handling decision. After controlling the target node to execute the anomaly handling decision, if it is determined that the target node has eliminated the anomaly state, then... This technique allows a distributed system to continue processing current transaction data until a transaction result is obtained. It effectively filters out transaction data with a high probability of anomalies before the data enters the distributed system. Furthermore, when transaction data enters the distributed system and anomalies occur, it attempts other anomaly handling strategies to eliminate the anomaly without first resorting to data rollback. This ensures the normal transaction processing of the distributed system while minimizing the frequency of data rollback operations, improving the processing performance of the distributed system, reducing the workload of manual intervention, and effectively avoiding the various problems and risks associated with data rollback operations in the distributed system.

[0058] Based on the above embodiments, before inputting the current transaction data to be processed into the real-time transaction feature analysis model, the following may also be included:

[0059] Collect abnormal transaction data that occurs during transaction data processing in a distributed system, and extract the abnormal data characteristics of each abnormal transaction data.

[0060] The pre-set machine learning model is trained based on the abnormal data characteristics of each abnormal transaction data to obtain a real-time analysis model of transaction characteristics.

[0061] Accordingly, the current transaction data to be processed is input into the real-time transaction feature analysis model, specifically including:

[0062] Input the current data characteristics of the current transaction data into the real-time transaction characteristic analysis model.

[0063] In this embodiment, a real-time transaction feature analysis model adapted to the distributed system can be pre-trained. By collecting various abnormal transaction data that enter the distributed system and fail to process, and based on the data mining and induction capabilities of the machine learning model, the data features of these abnormal transaction data that inevitably cause transaction processing failures can be learned, and the final real-time transaction feature analysis model can be obtained.

[0064] The machine learning model used to train the real-time analysis model of transaction features can be a deep or reinforcement learning model such as a neuromorphic spiking neural network, an online gradient boosting machine, or a graph attention network.

[0065] With the above settings, the machine learning model can learn autonomously to efficiently and accurately discover the data characteristics of abnormal transaction data. This allows for accurate filtering of transaction data that is likely to cause abnormal processing before it enters the distributed system, thus improving the accuracy of transaction data filtering.

[0066] Based on the above embodiments, after extracting the abnormal data features of each abnormal transaction data, the method may further include:

[0067] By analyzing the historical processing logs generated during the transaction processing of each abnormal transaction data in the distributed system, actual flow information matching each abnormal transaction data is generated.

[0068] The actual flow information includes: the various historical nodes to which the abnormal transaction data flows in the distributed system, and the processing results of each historical node on the abnormal transaction data.

[0069] Accordingly, a pre-defined machine learning model is trained based on the abnormal data characteristics of each abnormal transaction data to obtain a real-time transaction feature analysis model, which may further include:

[0070] Based on the abnormal data characteristics of each abnormal transaction and the actual flow information, a pre-set machine learning model is trained to obtain a real-time transaction feature analysis model.

[0071] In this optional implementation, the trained real-time transaction feature analysis model can not only predict the failure probability of transaction data failing in the distributed system, but also simulate the simulated flow information of transaction data when it is executed by each node in the distributed system.

[0072] The simulated flow information may include: the nodes through which the transaction data passes during execution in the distributed system, and the node processing results obtained by each node when processing the transaction data. The node processing results of each node may also include: the types of anomalies that may occur at the node, and the probability of anomalies occurring.

[0073] To obtain the simulated transaction flow information, it is necessary to analyze the historical processing logs generated during the transaction processing of each abnormal transaction in the distributed system, in order to generate actual flow information that matches each abnormal transaction. Based on the actual flow information and the abnormal data characteristics of each abnormal transaction, a preset machine learning model is trained to obtain the final real-time transaction feature analysis model.

[0074] It is understandable that, in addition to using the actual flow information matched with each abnormal transaction data for model training, the actual flow information of each normal transaction data executed normally in the distributed system can also be used for model training.

[0075] With the above settings, the location of nodes and the type of anomaly that may occur in the current transaction data can be predicted in advance before the real-time generated current transaction data enters the distributed system. This allows for the planning of corresponding anomaly handling strategies in advance, reducing the probability of anomalies and improving the timeliness of anomaly handling.

[0076] Figure 2 This is a flowchart of another transaction data processing method based on a distributed system provided by an embodiment of the present invention. This embodiment is an optimization based on the above embodiments. In this embodiment, after "obtaining simulated flow information that matches the current transaction data output by the real-time analysis model of transaction features", the following operations are further performed in conjunction with the simulated flow information: "when the failure probability in the detection result is less than the probability threshold, extract risk nodes and risk types that match the risk nodes from the simulated flow information; obtain risk handling strategies that match the risk types; and after controlling the risk nodes to execute the risk handling strategies, input the current transaction data into the distributed system".

[0077] Correspondingly, such as Figure 2 As shown, the method may include:

[0078] S210. Input the current transaction data to be processed into the real-time transaction feature analysis model, obtain the detection result of whether the current transaction data will fail to process in the distributed system, and obtain the simulated flow information that matches the current transaction data.

[0079] In this embodiment, before inputting the current transaction data into the real-time analysis model of the transaction features, the current transaction data can first be subjected to data collection, cleaning, inspection and storage operations to avoid dirty data entering the distributed system and causing unnecessary waste of resources to the distributed system.

[0080] As mentioned earlier, after training the real-time analysis model of the transaction features using the abnormal data characteristics of each abnormal transaction data and the actual flow information, the real-time analysis model of the transaction features can generate the corresponding failure probability and simulated flow information based on the data characteristics of the current transaction data.

[0081] S220. When the failure probability in the detection result is less than the probability threshold, extract the risk node and the risk type that matches the risk node from the simulated flow information.

[0082] When the failure probability is less than a probability threshold, it indicates that the current transaction data needs to be input into the distributed system for processing. Therefore, nodes that may cause processing anomalies, i.e., risk nodes, can be extracted from the simulated flow information. Furthermore, it is necessary to simultaneously obtain the anomaly type that may occur when these risk nodes process the current transaction data, i.e., the risk type.

[0083] S230. Obtain a risk handling strategy that matches the risk type, and after controlling the risk node to execute the risk handling strategy, input the current transaction data into the distributed system, and process the current transaction data through the collaborative efforts of each node in the distributed system.

[0084] In this embodiment, a mapping relationship between risk types and risk handling strategies can be established in advance. For example, there is a mapping relationship between risk types such as insufficient resources or processing timeout errors and risk handling strategies such as processing threads or processing resource expansion; or, there is a mapping relationship between risk types such as third-party server request failures and risk handling strategies such as third-party server reconnection.

[0085] After obtaining a risk handling strategy that matches the predicted risk type, the risk node can be directly controlled to execute the risk handling strategy in order to prevent the risk node from experiencing processing anomalies that match the risk type when actually processing the current transaction data.

[0086] S240. When the target node experiences a processing anomaly in response to the current transaction data, intercept the rollback operation performed by the target node in response to the processing anomaly, and input the anomaly information into the decision model to obtain the anomaly handling decision.

[0087] Based on the above embodiments, before inputting the abnormal information into the decision model, it may further include:

[0088] S2401. Collect historical exception information of each node in the distributed system when historical processing exceptions occur, and obtain the exception cause corresponding to each historical exception information, as well as the exception elimination strategy corresponding to each exception cause.

[0089] S2402. Based on the historical anomaly information corresponding to each node and the anomaly elimination strategy, train the preset machine learning model to obtain the decision model.

[0090] With the above settings, the machine learning model can learn autonomously to efficiently and accurately discover the potential correlation between various anomaly handling and anomaly elimination strategies. As a result, after transaction data enters the distributed system, the success rate of anomaly elimination for nodes that have experienced processing anomalies can be improved, further increasing the frequency of data rollback operations.

[0091] S250. After the target node executes the exception handling decision, if it is determined that the target node has eliminated the exception state, the distributed system is instructed to continue processing the current transaction data until the transaction processing result is obtained.

[0092] S260. Obtain the target processing log generated by the distributed system for the current transaction data, and dynamically update the real-time analysis model and decision model of transaction features based on the target processing log.

[0093] Through the above settings, reinforcement learning can be used to continuously optimize the data feature analysis and decision-making capabilities of the real-time transaction feature analysis model and the decision-making model during operation, thereby ensuring long-term and effective accuracy of data feature analysis and decision-making.

[0094] The technical solution of this invention extracts risk nodes and risk types matching the risk nodes from the simulated flow information when the failure probability in the detection result is less than a probability threshold; obtains risk handling strategies matching the risk types; and controls the risk nodes to execute the risk handling strategies before inputting the current transaction data into the distributed system. This implementation method, through the collaborative processing of the current transaction data by the nodes in the distributed system, allows for the early avoidance of factors that may lead to processing anomalies after it is clearly determined that transaction data needs to be input into the distributed system. This is achieved by predicting risk nodes that may cause processing anomalies, further improving the success rate of the distributed system in processing transaction data and maximizing the execution efficiency of the distributed system.

[0095] Specific application scenarios

[0096] Figure 3 This is a structural diagram of a specific application scenario to which this invention is applicable, such as... Figure 3 As shown, after a transaction begins, the real-time generated transaction data undergoes primary filtering via a real-time transaction feature analysis model. Transaction data that meets the failure probability requirements is then input into the distributed system, while transaction data that does not meet the failure probability requirements is directly filtered out, and corresponding error messages are fed back.

[0097] After transaction data enters the distributed system, it is processed relay-wise by nodes 1, 2, ..., n. Each node, after completing its processing, submits its result to the next adjacent node. Simultaneously, each node is configured with a compensation mechanism to handle unavoidable processing anomalies, in which case a data rollback operation is performed tier by tier, starting from that node. Specifically, whenever a node experiences a processing anomaly, it first requests an anomaly handling strategy from the decision model based on the anomaly information. After receiving the anomaly handling strategy from the decision model, the node executes it first. If the anomaly is resolved after the anomaly handling strategy is executed, the node submits the successfully obtained processing result to the next node. However, if the anomaly at a node is not resolved, a data rollback operation is performed tier by tier, starting from that node.

[0098] Finally, after the distributed system obtains the transaction completion information for a transaction, it can dynamically update the real-time analysis model and decision model of the transaction characteristics based on the final transaction processing result.

[0099] Figure 4 This is a schematic diagram of a transaction data processing device based on a distributed system, provided as an embodiment of the present invention. Figure 4 As shown, the device includes: a detection result acquisition module 410, a distributed processing module 420, an anomaly handling decision acquisition module 430, and a continued processing module 440, wherein:

[0100] The detection result acquisition module 410 is used to input the current transaction data to be processed into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system.

[0101] The distributed processing module 420 is used to input the current transaction data into the distributed system when the failure probability in the detection result is less than the probability threshold, and to process the current transaction data through the collaborative processing of each node in the distributed system.

[0102] The exception handling decision acquisition module 430 is used to intercept the rollback operation performed by the target node in response to the exception when the target node encounters a processing exception for the current transaction data, and input the exception information into the decision model to obtain the exception handling decision.

[0103] The continuing processing module 440 is used to instruct the distributed system to continue processing the current transaction data until the transaction processing result is obtained after the target node has made an exception handling decision.

[0104] The technical solution of this invention involves inputting the current transaction data to be processed into a real-time transaction feature analysis model to obtain a detection result indicating whether the current transaction data will fail in the distributed system. When the failure probability in the detection result is less than a probability threshold, the current transaction data is input into the distributed system, and the nodes in the distributed system collaboratively process the current transaction data. When a processing anomaly occurs at the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into a decision model to obtain an anomaly handling decision. After controlling the target node to execute the anomaly handling decision, if it is determined that the target node has eliminated the anomaly state, then... This technique allows a distributed system to continue processing current transaction data until a transaction result is obtained. It effectively filters out transaction data with a high probability of anomalies before the data enters the distributed system. Furthermore, when transaction data enters the distributed system and anomalies occur, it attempts other anomaly handling strategies to eliminate the anomaly without first resorting to data rollback. This ensures the normal transaction processing of the distributed system while minimizing the frequency of data rollback operations, improving the processing performance of the distributed system, reducing the workload of manual intervention, and effectively avoiding the various problems and risks associated with data rollback operations in the distributed system.

[0105] Based on the above embodiments, a data isolation module may also be included, used for:

[0106] After obtaining the detection result of whether the current transaction data will fail in the distributed system, if the failure probability in the detection result is greater than or equal to the probability threshold, the current transaction data is prevented from being input into the distributed system, and transaction failure information is generated as feedback result for the current transaction data.

[0107] Based on the above embodiments, a rollback operation execution module may also be included, used for:

[0108] After the target node makes an exception handling decision, if it is determined that the target node has not eliminated the exception state, the target node is instructed to perform a rollback operation for the exception handling.

[0109] Based on the above embodiments, it may further include a real-time transaction feature analysis model construction module, used for:

[0110] Before inputting the current transaction data to be processed into the real-time transaction feature analysis model, collect abnormal transaction data that occurs during the processing of transaction data in the distributed system, and extract the abnormal data features of each abnormal transaction data.

[0111] The pre-set machine learning model is trained based on the abnormal data characteristics of each abnormal transaction data to obtain a real-time analysis model of transaction characteristics.

[0112] Accordingly, the detection result acquisition module 410 can be specifically used for:

[0113] Input the current data characteristics of the current transaction data into the real-time transaction characteristic analysis model.

[0114] Based on the above embodiments, the real-time transaction feature analysis model construction module can be further used for:

[0115] After extracting the abnormal data characteristics of each abnormal transaction data, the actual flow information matching each abnormal transaction data is generated by analyzing the historical processing logs generated during the transaction processing of each abnormal transaction data in the distributed system.

[0116] The actual flow information includes: the various historical nodes to which the abnormal transaction data flows in the distributed system, and the processing results of each historical node on the abnormal transaction data;

[0117] Based on the abnormal data characteristics of each abnormal transaction and the actual flow information, a pre-set machine learning model is trained to obtain a real-time transaction feature analysis model.

[0118] Based on the above embodiments, it may further include a simulated flow information acquisition module, used for:

[0119] While inputting the current transaction data to be processed into the real-time transaction feature analysis model, the system obtains the detection result of whether the current transaction data will fail to process in the distributed system, and at the same time obtains the simulated flow information output by the real-time transaction feature analysis model that matches the current transaction data.

[0120] Accordingly, the detection result acquisition module 410 can be further used for:

[0121] When the failure probability in the detection results is less than the probability threshold, risk nodes and risk types matching the risk nodes are extracted from the simulated flow information.

[0122] After obtaining a risk management strategy that matches the risk type and controlling the risk node to execute the risk management strategy, the current transaction data is input into the distributed system.

[0123] Based on the above embodiments, a decision model construction module may also be included, used for:

[0124] Before inputting abnormal information into the decision model, collect historical abnormal information of each node in the distributed system when historical processing abnormalities occur, and obtain the abnormal cause corresponding to each historical abnormal information, as well as the abnormal elimination strategy corresponding to each abnormal cause.

[0125] Based on the historical anomaly information corresponding to each node and the anomaly elimination strategy, a pre-set machine learning model is trained to obtain a decision model.

[0126] Based on the above embodiments, a model update module may also be included, used for:

[0127] After inputting the current transaction data into the distributed system, the system obtains the target processing log generated by the distributed system for the current transaction data, and dynamically updates the real-time analysis model of transaction features and the decision model based on the target processing log.

[0128] The transaction data processing device based on a distributed system provided in the embodiments of the present invention can execute the transaction data processing method based on a distributed system provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0129] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solutions of this invention comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0130] Furthermore, the information collected in the various embodiments of the present invention is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0131] Figure 5 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0132] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0133] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0134] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as performing the transaction data processing method based on a distributed system as described in any embodiment of the present invention. That is:

[0135] The current transaction data to be processed is input into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system;

[0136] When the failure probability in the detection result is less than the probability threshold, the current transaction data is input into the distributed system, and the current transaction data is processed collaboratively by the nodes in the distributed system.

[0137] When a processing anomaly occurs on the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into the decision model to obtain the anomaly handling decision.

[0138] After the target node executes the exception handling decision, if it is determined that the target node has eliminated the exception state, the distributed system is instructed to continue processing the current transaction data until the transaction processing result is obtained.

[0139] In some embodiments, the transaction data processing method based on a distributed system as described in any one of the embodiments of the present invention can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the transaction data processing method based on a distributed system as described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the transaction data processing method based on a distributed system as described in any other suitable manner (e.g., by means of firmware).

[0140] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0141] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0142] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0143] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0144] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0145] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0146] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0147] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A transaction data processing method based on a distributed system, characterized in that, include: The current transaction data to be processed is input into the real-time transaction feature analysis model to obtain the detection result of whether the current transaction data will fail to process in the distributed system; When the failure probability in the detection result is less than the probability threshold, the current transaction data is input into the distributed system, and the current transaction data is processed collaboratively by the nodes in the distributed system. When a processing anomaly occurs on the target node for the current transaction data, the rollback operation executed by the target node in response to the processing anomaly is intercepted, and the anomaly information is input into the decision model to obtain the anomaly handling decision. After the target node executes the exception handling decision, if it is determined that the target node has eliminated the exception state, the distributed system is instructed to continue processing the current transaction data until the transaction processing result is obtained.

2. The method according to claim 1, characterized in that, After obtaining the detection result of whether the current transaction data will cause transaction processing failure in the distributed system, it also includes: When the failure probability in the detection result is greater than or equal to the probability threshold, the current transaction data is prevented from being input into the distributed system, and transaction failure information is generated as feedback result to the current transaction data. After controlling the target node to execute exception handling decisions, the following is also included: If it is determined that the target node has not eliminated the abnormal state, the target node is instructed to perform a rollback operation for handling the abnormality.

3. The method according to claim 1, characterized in that, Before inputting the current transaction data to be processed into the real-time transaction feature analysis model, the following steps are also included: Collect abnormal transaction data that occurs during transaction data processing in a distributed system, and extract the abnormal data characteristics of each abnormal transaction data. The pre-set machine learning model is trained based on the abnormal data characteristics of each abnormal transaction data to obtain a real-time analysis model of transaction characteristics. Accordingly, the current transaction data to be processed is input into the real-time transaction feature analysis model, specifically including: Input the current data characteristics of the current transaction data into the real-time transaction characteristic analysis model.

4. The method according to claim 3, characterized in that, After extracting the abnormal data features of each abnormal transaction, the process also includes: By analyzing the historical processing logs generated during the transaction processing of each abnormal transaction data in the distributed system, actual flow information matching each abnormal transaction data is generated. The actual flow information includes: the various historical nodes to which the abnormal transaction data flows in the distributed system, and the processing results of each historical node on the abnormal transaction data; Accordingly, a pre-set machine learning model is trained based on the abnormal data characteristics of each abnormal transaction data to obtain a real-time transaction feature analysis model, which further includes: Based on the abnormal data characteristics of each abnormal transaction and the actual flow information, a pre-set machine learning model is trained to obtain a real-time transaction feature analysis model.

5. The method according to claim 4, characterized in that, The process involves inputting the current transaction data to be processed into the real-time transaction feature analysis model to obtain a detection result indicating whether the current transaction data will fail to process in the distributed system. This also includes: Obtain simulated transaction flow information that matches the current transaction data, output by the real-time transaction feature analysis model; Correspondingly, when the failure probability in the detection result is less than the probability threshold, the current transaction data is input into the distributed system, which also includes: When the failure probability in the detection results is less than the probability threshold, risk nodes and risk types matching the risk nodes are extracted from the simulated flow information. After obtaining a risk management strategy that matches the risk type and controlling the risk node to execute the risk management strategy, the current transaction data is input into the distributed system.

6. The method according to claim 1, characterized in that, Before inputting abnormal information into the decision model, the following steps are also included: Collect historical anomaly information of each node in the distributed system when historical processing anomalies occur, and obtain the anomaly cause corresponding to each historical anomaly information, as well as the anomaly elimination strategy corresponding to each anomaly cause. Based on the historical anomaly information corresponding to each node and the anomaly elimination strategy, a pre-set machine learning model is trained to obtain a decision model.

7. The method according to any one of claims 1-6, characterized in that, After inputting the current transaction data into the distributed system, the following is also included: Obtain the target processing logs generated by the distributed system for the current transaction data, and dynamically update the real-time analysis model and decision model of transaction features based on the target processing logs.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the transaction data processing method based on a distributed system as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the transaction data processing method based on a distributed system as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the transaction data processing method based on a distributed system according to any one of claims 1-7.

Images