Distributed Transaction Processing Method, System, Apparatus, and Readable Storage Medium

Abstract

This application relates to the field of software technology, and more specifically, to a distributed transaction processing method, system, apparatus, and readable storage medium. The method includes creating and initializing a history version table, where the history version table is for recording the data content and version information of each version of a target data entity, the initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity; the service flow processing module sending a first type of operation request for the received target data entity to the insurance securities data management module; and the insurance securities data management module reading the history version table and recording the data content of the second version obtained by performing a first type of operation on the data content of the first version. This application can improve the efficiency of distributed transaction processing and the service rollback ability based on the history version table, which is advantageous for improving the user experience.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and more specifically, to a distributed transaction processing method, system, apparatus, and readable storage medium. (Declaration of Claim of Priority) This application claims the priority of a Chinese patent application filed with the China National Intellectual Property Administration on May 31, 2022, with an application number of 202210611120.X and an application title of "Distributed Transaction Processing Method, System, Apparatus, and Readable Storage Medium", the entire content of which is incorporated herein by reference.

Background Art

[0002] A distributed transaction refers to the situation where the participants in a transaction, the servers supporting the transaction, the resource servers, and the transaction manager are located on different nodes of different distributed systems. Here, a transaction is an execution unit of a program that operates on certain data in a database.

[0003] In general distributed transaction solutions, Seata based on the XA specification is an open-source distributed transaction solution, aiming to provide a high-performance, simple and easy-to-use distributed transaction service under the microservices architecture. Seata provides users with four transaction processing models: AT, TCC (Try-Confirm-Cancel), long transaction model (SAGA), and XA. Among them, AT and XA are models for processing rigid transactions. However, due to the synchronous block of rigid transactions, the processing efficiency is low and it is generally not suitable for distributed scenarios of large-scale websites. TCC and SAGA are models for processing flexible transactions. Flexible transactions allow intermediate states and support the transformation of service layers such as applications (Application, APP). Therefore, in some distributed scenarios of large-scale websites, the TCC and SAGA models are widely used. The TCC model among them provides three service interfaces: the primary operation (Try), the confirmation operation (Confirm), and the cancellation operation (Cancel), which can be called by the main service. Therefore, TCC divides the transaction execution process into a Try and Confirm phase and a Cancel phase that enables the service rollback of the transaction processed by Try and Confirm. SAGA realizes service rollback based on the reverse compensation operations of a series of operations. Taking the insurance service as an example, the aforementioned service rollback is, for example, the operation of modifying the created insurance contract, or the operation of canceling the generated insurance contract (i.e., insurance cancellation).

[0004] However, in such service rollback processing, currently, it is common to complete the rollback by reading the changes before and after the data change in the corresponding Structured Query Language (SQL) for the lowest layer of the database, or to realize the service rollback based on the rollback code. The realization of such service rollback cannot be applied to the service layer (for example, the application program itself), the rollback logic is complex, the realization is difficult, and the development, maintenance, and modification costs involved in realizing the corresponding service rollback function are relatively high.

Summary of the Invention

[0005] Embodiments of the present application provide a distributed transaction processing method, system, apparatus, and readable storage medium. The method can record the version information of the corresponding data entity before and after data operations such as new addition, deletion, change (or modification), and the content before and after the operation. When it is detected that a rollback operation has occurred in the service system, or when an abnormality occurs in the corresponding data operation on the data entity called in the service system, based on the relevant information such as the version number recorded in the history version table, the data content of the history version before the data entity is data-operated can be quickly obtained to realize the rollback. It is beneficial to improve the user experience by improving the service rollback ability of the distributed system.

[0006] In a first aspect, embodiments of the present application provide a distributed transaction processing method, which is used for a system including a service flow processing module, an insurance and securities data management module, and a distributed transaction manager. The method includes the following: The insurance security data management module creates and initializes a history version table, where the history version table is for recording the data content and version information of each version of the target data entity, and the initialized version information includes the first version information, and the first version information corresponds to the data content of the first version of the target data entity; The service flow processing module requests the distributed transaction manager to start a global transaction; The service flow processing module receives a first type of operation request for the target data entity, and sends the first type of operation request to the insurance security data management module, where the first type of operation request is for requesting to execute a first type of operation on the data content of the first version of the target data entity, and the first type of operation includes at least one of addition, deletion, and modification operations; In response to the first type of operation request, the insurance security data management module reads the history version table, records the data content of the second version obtained by executing the first type of operation on the data content of the first version, and registers a transaction branch with the distributed transaction manager, where the transaction branch is a related transaction for executing the first type of operation; The distributed transaction manager notifies the insurance security data management module to commit the transaction branch according to the first request to commit the global transaction sent from the service flow processing module.

[0007] That is, in a system for processing distributed transactions, a history version table can be created by an insurance security data management module that manages data entities related to insurance security data owned by the system itself, and control is performed so that the history version table created in the creation process is the same as the data table structure of the target data entity, that is, it is made easy to achieve isomorphism. In this way, when the system detects an update to the stored content of the data table of the target data entity, the created history version table is used to record the data content before and after the update in a timely manner and write the corresponding version information. As a result, when another service is executed to call the history version table, the data content of the corresponding version can be quickly called based on the version information recorded in the history version table.

[0008] The service flow processing module in the system connects to the distributed service system client, receives a service operation request due to the user's operation on the service system client, and then, according to the request content and request target of the service operation request, can transfer it to the relevant module in the system for execution. For example, the received first type of operation request is transferred to the insurance security data management module for processing. Furthermore, the program code executed by the service flow processing module can request the start of a global transaction from the distributed transaction manager when it is determined that the next operation to be executed needs to be related to multiple different data sources or multiple remote calls and data updates are required. In this way, the classification processing efficiency of the service operation request by the system can be improved. The above-mentioned first type of operation request corresponds to the forward operation described in the embodiments to be described later, and the first type of operation is a forward operation. The above-mentioned first type of operation request may be, for example, an operation request corresponding to a trigger in which an insurance policyholder creates a new insurance security through an operation on the insurance business client and fills in the personal information, insurance amount, address, etc. of the policyholder / insured on the client interface.

[0009] When the distributed transaction manager in the system responds to the first type of operation request transferred by the service flow processing module, it can call the history version table created by the insurance securities data management module. The above-mentioned data content of the first version may be, for example, the initial content of the target data entity. Therefore, the distributed transaction manager can obtain the initial content of the target data entity through the first version information in the history version table and process the first type of operation request based on the obtained initial content. As can be understood, after the insurance securities data management module creates the history version table of the target data entity, if there is an update to the recorded content of the history version table, when the insurance securities data management module responds to the above-mentioned first type of operation request, it can quickly obtain the initial content of the target data entity pointed to by the processing of the corresponding service operation request through the history version table, which is advantageous for improving the service processing efficiency of the distributed transaction manager.

[0010] In a possible implementation of the above first aspect, recording the data content of the second version obtained by reading the history version table and performing the first type of operation on the data content of the first version includes the following: The insurance securities data management module writes the data content of the second version into the history version table and writes the second version information into the history version table corresponding to the data content of the second version; The insurance securities data management module writes the first version information and the second version information into the log for canceling the rollback.

[0011] That is, when processing requests such as new addition, deletion, and modification, the insurance security data management module reads version information using a log for canceling rollback in a distributed transaction, and can further read the data content of the corresponding version based on the history version table. Here, the log for canceling rollback only needs to store the version number as index information, and there is no need to store the complete change content. This can improve the data operation processing efficiency of the insurance security data management module.

[0012] In a possible implementation of the first aspect, the method further includes the following: The service flow processing module obtains abnormal data in the global transaction or a second type of operation request for the received target data entity, and sends a second request to the distributed transaction manager to roll back the global transaction. Among them, the second request is for requesting the rollback of the global transaction so as to update the data content of the target data entity from the data content of the second version to the data content of the first version; The distributed transaction manager notifies the insurance security data management module to roll back the transaction branch in response to the second request; Based on the notification to roll back the transaction branch, the insurance security data management module obtains the data content of the first version based on the first version information recorded in the history version table and restores it to the current data content of the target data entity.

[0013] The above-mentioned second type of operation may be, for example, a rollback operation request initiated by a distributed service system client. The abnormal data within the global transaction obtained by the service flow processing module may be, for example, abnormal data reported on the service system when an abnormality occurs in the corresponding data operation on the called data entity, such as database write failure, network abnormality, etc. When the service flow processing module receives a rollback operation request or obtains abnormal data in the global transaction, it can send a second request to roll back the global transaction, that is, a request to roll back the global transaction, to the distributed transaction manager. The distributed transaction manager can, in response to the request, notify the insurance and securities data management module to roll back the transaction branch. Furthermore, the insurance and securities data management module can read and call the updated history version table to quickly obtain the data content of the history version before the data entity is data-operated, thereby realizing the rollback. In this way, the response processing efficiency for the rollback transaction of the distributed service system can be improved, which is advantageous for improving the rollback ability of the system. It is understood that the version information recorded in this history version table and the content of the target data entity are updated when the distributed transaction manager processes the first type of operation request in the previous step.

[0014] In a possible embodiment of the above first aspect, the log for canceling the rollback includes a rollback log. Obtaining the data content of the first version based on the first version information recorded in the history version table includes the following: The insurance and securities data management module obtains the first version information recorded in the rollback log; The insurance security data management module obtains the data content of the first version based on the correspondence between the first version information recorded in the history version table and the data content of the first version.

[0015] That is, when processing a rollback operation request or an abnormal rollback transaction, the insurance security data management module reads version information using an undo log and can further read the data content of the corresponding version from the history version table. Among these, the undo log only needs to store the version number as index information and does not need to store the complete change content. This can improve the data operation processing efficiency of the insurance security data management module.

[0016] In a possible implementation of the above first aspect, the history version table is created based on creating a history version table with the same structure as the first data table structure from the first data table structure corresponding to the target data entity.

[0017] That is, the history version table created by the insurance security data management module is isomorphic to the data table structure of the target data entity. The above first data table structure is the structure of any data table or any type of data table corresponding to the target data entity.

[0018] In a possible implementation of the above first aspect, the parameter list of the history version table includes a primary key, a type, an initial version, and a service field waiting for recording, and the version information includes the version number recorded in the initial version field of the history version table.

[0019] The above-mentioned primary key and the service field waiting for recording correspond to the data content recorded in the history version table. The primary key is, for example, the ID of the insurance security data, and the service field waiting for recording is, for example, fields such as the insurance amount and address. The type of the above-mentioned history version table can record, for example, the type of operation corresponding to the first type of operation described above, such as new addition, deletion, modification, etc. The initial version of the above-mentioned history version table is, for example, an identification code written according to the version number setting rule preset corresponding to the version information of the recorded data. Note that the version number of the initial version recorded in the history version table (simply the initial version number) corresponds one-to-one with the data content before and after the update every time the data content is updated. That is, in the history version table, the data content of each version corresponds to one initial version number. The initial version number can be used as identification information for obtaining the data content of the corresponding version when the insurance security data management module executes the first type of operation in response to the first type of operation request, or when rolling back the transaction branch based on the notification to roll back the transaction branch of the distributed transaction manager in order to realize the rapid acquisition of the data content.

[0020] As can be understood, the version information such as the initial version number recorded in the history version table can be used to obtain the data content of the corresponding version, replacing the complex call process realized by the original distributed transaction calling the target data entity and the modification log of the target data entity from the database, thereby improving the efficiency of obtaining the corresponding data content and further improving the processing efficiency of the distributed transaction.

[0021] In a possible embodiment of the first aspect, each parameter in the parameter list of the history version table is associated with each parameter in the first data table structure. This association is created by the insurance certificate data management module adding first annotation information to the first data table structure via a preset annotation tool. The first annotation information is used to update each parameter in the history version table in response to changes in each parameter in the first data table structure when analyzed by the storage management engine. The preset annotation tool is @Audit provided by Hibernate Envers, and the storage management engine is Hibernate.

[0022] Since the insurance certificate data management module has the advantage of calling with respect to the content and structure of the target data entity to be managed, after creating the history version table, the insurance certificate data management module can add an annotation to the Java class of the data table structure of the target data entity via the Java class annotation @Audit provided by Hibernate Envers. In this way, after the engine Hibernate responsible for database storage analyzes this annotation in the code, when the content of the corresponding data table of the data entity is updated, the data contents and version information before and after the corresponding update can be recorded in the history version table at the same time. The method of recording the update changes of the data entity by such a history version table has simple logic, convenient operation, a small degree of influence on the original database and the distributed transaction processing flow, and is advantageous for improving the efficiency of distributed transaction processing.

[0023] In a possible embodiment of the first aspect, the first version information is the first version number recorded in the initial version field of the history version table.

[0024] That is, the first version information is the initial version number corresponding to the data content of the first version recorded in the history version table.

[0025] In a possible embodiment of the above first aspect, the obtaining of the history version table by the insurance security data management module includes the following: When the insurance security data management module reads the history version table in response to the first type of operation request, it includes the following: The insurance security data management module reads the history version table based on a preset SQL. Here, the preset SQL includes at least the name of the history version table, the primary key, and the corresponding version number recorded in the initial version field. That is, when the insurance security data management module responds to the first type of operation request, it can complete the query and acquisition response of the history table and the corresponding version of data content through a simple SQL statement. The execution statement of the query process is simple and efficient, and the efficiency of obtaining the corresponding data content can also be improved.

[0026] In a possible embodiment of the above first aspect, the first type of operation request is a distributed transaction operation request written to the bin log event or update log event of MYSQL (registered trademark). The service flow processing module receives the first type of operation request for the target data entity, and the transfer of the first type of operation request to the insurance security data management module includes the following: The service flow processing module determines that the first type of operation request is a distributed transaction operation request written to the bin log event or update log event of MYSQL; The service flow processing module analyzes the received bin log event to obtain bin log data, or analyzes the received update log event to obtain update log data; The service flow processing module identifies distributed transaction operation requests corresponding to addition, deletion, or modification operations based on bin log data or update log data; The service flow processing module transfers the identified distributed transaction operation requests to the insurance certificate data management module as the first type of operation requests.

[0027] By analyzing the MYSQL bin log event or update log event to identify the type of distributed transaction operation request, the changes in the data recorded at the bottom of the database can be obtained by the Java program executed in the application layer. The data acquisition method is simple, direct, and highly timely. Furthermore, this method of obtaining the operation request data can avoid code modification to the server supporting the distributed service system, which is beneficial for reducing the development workload corresponding to the transformation of the server or system.

[0028] In a possible implementation of the above first aspect, the second type of operation request is a distributed transaction operation request written in the MYSQL bin log event. The service flow processing module receives the second type of operation request for the target data entity and sends a second request to roll back the global transaction to the distributed transaction manager, which includes the following: The service flow processing module analyzes the received bin log event to obtain bin log data; The service flow processing module identifies a rollback operation request that requires updating the returned second version of the data content to the first version of the data content based on the bin log data; The service flow processing module sends a second request to roll back the global transaction to the distributed transaction manager based on the identified rollback operation request.

[0029] As described above, by analyzing the bin log events of MYSQL to identify the rollback operation requests or abnormal operation data of distributed transactions, it is necessary to determine whether to execute rollback processing on the data content of the target data entity in the database, and the data changes or abnormal data recorded at the bottom of the database can be obtained by the Java program executed in the application layer. The data acquisition process is simple, direct, highly timely, and is beneficial for reducing the development workload corresponding to the transformation of the server or system.

[0030] In a possible embodiment of the first aspect, the second type of operation request includes canceling the request for the first type of operation or calling the data content of the first version to re-execute the first type of operation.

[0031] The request to cancel the first type of operation is, for example, a distributed transaction rollback request initiated in response to a user performing a rollback operation through the client of the distributed service system. For example, when a user returns to the previously filled insurance certificate information page to reconfirm when paying the insurance amount, it corresponds to triggering a rollback operation request from the client. In other embodiments, the request to cancel the first type of operation described above may also be a restoration request to restore to the initial data content, which is initiated in response to an abnormality of the service system client. There is no limitation here.

[0032] When other users need to call the data content of the first version of the data entity through other clients to execute corresponding service operations, the insurance certificate data management module can also quickly obtain and process the data content of the first version through the first version information recorded in the history version table.

[0033] In a possible embodiment of the first aspect, the target data entity is stored in a database for distributed transactions, and the method includes the following: In the process of executing the first type of operation, the data content of the target data entity stored in the database is made to match the real-time data content of the target data entity operated by the insurance security data management module by the following method: The distributed transaction manager obtains the active transaction list at the current time, where the active transaction list is for marking the execution progress of the first type of operation executed on each data entity in the database, and each data entity in the database includes the target data entity; Based on the active transaction list and the log data corresponding to the target data entity generated by the current database, the distributed transaction manager generates a consistency compensation statement and a compensation instruction and sends them to the database. The compensation instruction is used to instruct the database to execute the consistency compensation statement, and updates the data content of the target data entity in the database with the real-time data content corresponding to the execution progress of the first type of operation.

[0034] That is, when the distributed transaction manager derives the target data entity from the database and performs operations such as new addition, deletion, and modification, it generates a data integrity compensation statement based on the active transaction list and the log corresponding to the target data entity recorded in the database, and instructs the corresponding database to execute the statement to update the data content of the target data entity in the database. In this way, in the process of distributed transaction processing, it is possible to ensure that the data content stored in the database and the data content being operated on are timely consistent. Therefore, when other distributed systems call the corresponding data content in the database, the real-time updated data content can be output. On the other hand, the data content before the corresponding operation can be recorded in the history version table. When it is necessary to roll back to the subsequent distributed transaction operation process, the corresponding data content can be obtained and processed based on the corresponding version information, and there is no need to obtain the historical data content from the corresponding log recorded in the database. Thereby, the efficiency of distributed transactions and the timeliness of updating the data content of the database can be effectively improved.

[0035] In a second aspect, embodiments of the present application provide a system, the system includes a service flow processing module, an insurance security data management module, and a distributed transaction manager. Among them, the insurance security data management module is for creating and initializing a history version table. The history version table is for recording data contents and version information of each version of the target data entity. The initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity. And in response to a first type of operation request, read the history version table, record the data content of the second version obtained by performing a first type of operation on the data content of the first version, and register a transaction branch with the distributed transaction manager. The transaction branch is a related transaction for performing a first type of operation. The service flow processing module receives a first type of operation request for the target data entity and sends the first type of operation request to the insurance security data management module. The first type of operation request is for requesting to perform a first type of operation on the data content of the first version of the target data entity. The first type of operation includes at least one of an addition operation, a deletion operation, and a modification operation. And obtain abnormal data in the global transaction or a second type of operation request received for the target data entity, and send a second request for rolling back the global transaction to the distributed transaction manager. The second request is for requesting a rollback of the global transaction for updating the data content of the target data entity from the data content of the second version to the data content of the first version. The distributed transaction manager receives the notification sent by the service flow processing module to start a global transaction, and receives the request to register a transaction branch from the insurance security data management module, and stores the registration information of the transaction branch; and receives the notification to commit the global transaction sent by the service flow processing module, and notifies the insurance security data management module to commit the transaction branch.

[0036] In a third aspect, an embodiment of the present application provides an apparatus including one or more processors and one or more memories. The one or more memories store one or more programs, and when executed by the one or more processors, cause the apparatus to execute the distributed transaction processing method provided by the first aspect.

[0037] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to execute the distributed transaction processing method according to the first aspect.

Brief Description of the Drawings

[0038]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

DETAILED DESCRIPTION OF THE INVENTION

[0039] To facilitate the understanding of the solution of the present application, some concepts in the technical field related to the embodiment of the present application are described below. (1) A database stores a large amount of data entities. Database design is the process of planning and structuring the data entities in the database and their relationships. (2) In the case of a database, a data entity refers to an individual data set corresponding to a specific type of data object. Each data entity can use a data table structure to record the individual data corresponding to the data object and the associations between the individual data. Therefore, the data table structure of each data entity includes one or more mutually associated data tables, and the primary keys of each data table may be associated with each other. For example, the primary key of one data table may be the foreign key of the other data table. (3) A data table is composed of three parts: a table name, fields of the table, and records of the table. Designing a data table structure (hereinafter simply referred to as a table structure) is to define the data table file name, determine which fields the data table contains, the field name, field type, and width of each field, and input these data into a computer. (4) The primary key refers to a combination of one or more columns in a data table, and its value can uniquely identify each row in the table. The primary key of one data table can be associated with the foreign key of another data table to associate operations such as addition, deletion, modification / change of field text, etc. in the other data table. (5) The ACID properties refer to four properties required for a database management system (DBMS) to ensure that transactions are accurate and reliable during the process of data writing or updating, namely, atomicity (or indivisibility), consistency, isolation, and durability.

[0040] Figure 1 shows a schematic diagram of an application scenario of a distributed service system according to an embodiment of the present application. As shown in Figure 1, in this scenario, communication is carried out between the terminal devices 100a and 100b and the server 200. Here, the server 200 may include a plurality of databases and a transaction manager that processes distributed transactions to provide distributed data services to each terminal device.

[0041] The user or the platform operator of the corresponding service system can execute a service system application or a web-based service system application via the terminal device 100a. This service system may be, for example, an insurance service system. A user who wishes to subscribe to insurance can register a system account with the insurance service system on which the terminal device 100a operates, and can select insured items, fill in personal information, create insurance certificates, pay insurance premiums, etc. In the process of the user performing a series of operations on the terminal device 100a, the corresponding operation data accesses the corresponding database of the server 200. When it is necessary to correct the operations completed by the user, for example, when correcting personal information in the insurance certificate, or when the user wants to return to the previous page from the currently displayed page of the terminal device 100a or perform an operation in the previous step, the service system operating on the terminal device 100a at this time executes a rollback of the corresponding service to support the user's rollback or correction operation.

[0042] Similarly, another user or the platform operator of the corresponding service system can also connect to the service system via another terminal device 100b. For example, an insurance service staff can log in to the insurance service system via the terminal device 100b and can view or approve the content of the insurance certificate. At this time, the terminal device 100b can obtain the corresponding insurance certificate data from the insurance certificate database on the server 200 and display it on the screen of the terminal device 100b. In addition, the insurance service staff can also modify or cancel the already generated insurance certificate according to the user's request. The service system operating on the terminal device 100b at this time also needs to have a service rollback function to support the insurance service staff's modification or cancellation operation.

[0043] In the current distributed transaction solution, whether it is a service rollback function realized by reading the changes in the data before and after the change in the SQL statement corresponding to the underlying layer of the database, or a service rollback function realized based on the rollback code, the implementation logic is relatively complex, and it is necessary to perform a relatively large transformation on the distributed service system, and the corresponding development and maintenance costs are relatively high.

[0044] To solve the above technical problems, the present application provides a distributed transaction processing method. Specifically, in database design, by adding a history version table isomorphic to the data table structure of the target data entity, the version information before and after data operations such as new addition, deletion, change (or modification) of the target data entity, and the content before and after the operation are recorded. Note that this history version table can be made isomorphic to the data table structure of the target data entity, for example, by adding fields such as version number and version type to the basic data table structure corresponding to the target data entity, and there is no limitation here.

[0045] In this way, in the communication scenario between the server and the terminal device shown in FIG. 1 above, when the server 200 detects that a rollback operation has occurred in the service system running on the terminal device 100a or 100b, or when an abnormality occurs in the corresponding data operation on the data entity called on the service system, the server 200 can quickly obtain the data content of the historical version before the data entity is data-operated based on the related information such as the version number recorded in the historical version table and perform a rollback. Also, based on this historical version table, the server 200 can quickly restore the version of the operated data even when the user performs a forward operation again on the service system where the terminal device 100a or 100b is running. That is, the solution of this application can support a fast rollback operation of distributed transactions on a distributed service system and can quickly restore the recorded historical operation data when a forward operation is executed again on the corresponding service system of the user.

[0046] The distributed transaction processing method according to this application realizes the recording of version information and data content, etc. of the data entity before and after the application layer executes the corresponding data operation by adding a historical version table isomorphic to the data table structure of the target data entity in the database of the server. Here, the application layer is, for example, the Java program layer that communicates with the terminal device executed in the server 200, and there is no limitation. Furthermore, the server 200 can apply the historical version table in which the version information and data content, etc. of the data entity before and after the execution of the corresponding operation are recorded to the data rollback function of the distributed transaction.

[0047] Furthermore, the above-mentioned history version table can be adaptively designed for various distributed service systems connected to the application layer. For example, the data table structure corresponding to the data entity of the corresponding distributed service system is designed to be isomorphic for reading table information during subsequent calls. Furthermore, the implementation process of the distributed transaction processing method according to the embodiment of the present application can support various types of databases regardless of the type of the database at the bottom of the server 200 system, has high scene adaptability, and does not cause additional performance loss to the server.

[0048] The distributed transaction processing method according to the embodiment of the present application is applicable to devices including, but not limited to, the above-mentioned server 200, as well as mobile phones, tablets, desktops, laptops, handheld computers, netbooks, and augmented reality (AR) / virtual reality (VR) devices, wearable devices such as smart TVs and smart watches, mobile email devices, in-vehicle devices, portable game consoles, portable music players, reader devices, TVs with one or more processors incorporated or coupled thereto, or other devices accessible to the network.

[0049] Hereinafter, taking the server 200 in the scenario shown in FIG. 1 as an example, the specific implementation procedure of the distributed transaction processing method provided by the embodiment of the present invention will be described in detail with reference to the drawings. Based on the scenario shown in FIG. 1 described above, FIG. 2 is an overview diagram of the implementation flow of the distributed transaction processing method according to the embodiment of the present application. Note that the execution subject of each step shown in FIG. 2 may be the server 200 in the scenario shown in FIG. 1. Specifically, it includes the following steps: 201: Create a homogeneous history version table based on the table structure of the data entity in the database.

[0050] For example, when creating a database required for a certain distributed service system on server 100, in the database design stage, a history version table can be added to the structure of the database. Here, the table structure of the added history version table may be the same as the table structure of the target data entity in the database, that is, it may be "isomorphic" as described above. Similarly, for the database created on server 200, the database interface can be called, and a history version table isomorphic to each data entity in the database can be added in association, and the original version in the corresponding database can be initialized by data migration. Note that the data items recorded in the history version table may include the primary key of the target data entity table, the version information before and after modification, and the content before and after modification, and based on the content before and after modification, the type of operation (new addition, deletion, change) can be identified.

[0051] Here, an exemplary format of the history version table can be referred to Table 1 below.

[0052]

Table 1

[0053] As shown in Table 1, the "primary key" in the history version table may be the primary key of each data table corresponding to the data entity, or may be an identification character string such as an ID, for example. The "Field 1" and "Field 2" of the history version table may be service fields or the like recorded in each data table corresponding to the data entity. For example, in "Field 1", name, address, insurance amount, etc. may be recorded, and in "Field 2", version type, modification type, etc. may be recorded. The "initial version" of the history version table is the version number corresponding to the data content before a certain data operation on the target data entity, and the "end version" is the version number of the data content generated after that data operation. For example, in the record of the first row shown in Table 1 above, the initial version "1" is the version number of the data content before a certain data operation, and the end version "2" is the version number of the data content generated after a certain data operation. Note that after a certain data operation, the primary key, Field 1, initial version, end version, Field 2, etc. corresponding to the data entity after the operation may be recorded in another row of the history version table. For example, in the record of the second row shown in Table 1 above, the initial version of the second row is "2".

[0054] When no data operation is performed on the target data entity, the version number of the "end version" in the history version table shown in Table 1 above may be a null value such as "NULL" shown in Table 1 above.

[0055] Taking the database corresponding to the insurance service as an example, FIG. 3 is a schematic diagram showing the history version added to some data entities of the insurance certificate database according to the embodiment of the present application.

[0056] As shown in FIG. 3, a part of the original table structure of the data entity in the corresponding database can refer to, for example, the "Policy" table and the "Address" table. Referring to FIG. 3, the primary key of the "Policy" table is ID, and the field of the record is the specific amount of the "guarantee amount". For example, the initial version with ID 100 is "1", and the corresponding "guarantee amount" data is 1000. The primary key of the "Address" table is also ID, and the field of the record is the specific content of the "address". For example, the "address" data with ID 101 is "SH", and the "address" data with ID 102 is "BJ".

[0057] Continuing to refer to FIG. 3, the isomorphic history version tables created based on the table structures of the above-mentioned data entities can refer to the "Policy Log" table and the "Address Log" table shown in FIG. 3. Here, the "Policy Log" table has an additional version number field (for example, the initial version shown in FIG. 3) and "version type" field compared with the above-mentioned "Policy" table. The "type" field of the "Policy Log" table is, for example, "Field 1" in Table 1 above, and the "version type" field is, for example, "Field 2" in Table 1 above, and here it is not limited. Similarly, in the "Address Log" table, an "initial version" field and a "version type" field are added compared with the above-mentioned "Address".

[0058] The isomorphic history version tables can fully store the change history of the data, facilitating reading and writing via SQL when the recorded history versions are called in subsequent steps. The specific role played by the version number field added to the above-mentioned history version tables in the rollback transaction started by, for example, the execution of subsequent rollback operations will be described in detail in step 203 below, so the description is omitted here.

[0059] For the data entities that need to be recorded in the history version table, add an annotation to support record modification, and initialize the history version table information. As an example, in order for the server 200 to support recording the modification process of the content of the target data entity, that is, to support record modification, an annotation is added to the data entity that needs to be recorded in the history version table. As an example, the annotation can be added to the data structure Java class of the target data entity, for example, through "@Audit" provided by the Hibernate Envers tool. Then, when the engine (Hibernate) responsible for database storage analyzes that there is this annotation in the code, it can record the change history in the history version table when the data table of the target data entity is updated. Specifically, the procedure for adding an annotation to the Java class of the target data entity by @Audit is as follows.

[0060] TIFF2025520102000003.tif125166

[0061] As shown in FIG. 3, like the history version table "Policy Log" and the data table "Policy", the history version data recorded by the @Audit annotation and the data table of the data entity are isomorphic. Therefore, the parameter list annotated by @Audit may include some service fields such as "ID", "operation type", and "insurance amount". In addition to ID and Type, each service field may exist, but program parameters and user information at the time of call are not included. After the annotation is completed, the server 200 can initialize the data content of the target data entity in the generated history version table and record the corresponding initial version number.

[0062] Hibernate Envers is generally a framework for auditing entities. @Audit is one of the annotation components used in the Hibernate Envers tool and is a Java annotation. @Audit is commonly used to annotate entity classes or Java classes that call attributes in order to support the modification of data records. In the embodiments of this application, the Hibernate Envers tool can be used to record the version number information of each data entity in the database and store it in a corresponding historical version table that accommodates data changes caused by data operations.

[0063] In other embodiments, other tools can be used to add an annotation of "supporting record modification" to data entities, but it is not limited to this.

[0064] 203: When a forward operation request for a data entity is detected, record the data content of the target data entity in the historical version table and write the version information before and after the operation. For example, the server 200 can receive the call of the data entity started by the service system in which the terminal device is operating and the operation requests generated in response to operations such as new addition, deletion, and modification on the called data entity, that is, the above-mentioned forward operation requests. The server 200 can, in response to this forward operation request, record the data content, version information, etc. before and after the target data entity in the database is operated based on the operation content in the corresponding historical version table.

[0065] In some embodiments, this forward operation request may be, for example, a distributed transaction operation request written to a binary log (bin log) event or an update log event of a relational database management system (MYSQL). Here, the bin log can store all actions that modify table data in the database and may include all updated data or all statements of data that may be updated. In some embodiments, the bin log type can be started using the - log - bin[= file _ name] option, and MYSQL writes a log file of SQL commands including all updated data.

[0066] The update log can provide query information, but can only provide queries that modify the content of the database. In some embodiments, the - log - update server option can be used to enable the update log. When the log type is enabled, MySQL creates a file named HOSTNAME.nnn under the data directory. Based on the bin log data obtained by bin log event analysis, it is possible to analyze the specific type of the received operation request, for example, whether it is an operation such as a new addition, deletion, or change of the initial data content of the target data entity.

[0067] Taking the TCC model for processing distributed transactions as an example, the forward operations that the service system calls and executes on the data entity involve new addition, deletion, and change operations related to the two stages of the initial operation (Try) and the confirmation operation (Confirm) in the TCC mode. Taking the SAGA model for processing distributed transactions as an example, the forward operations that the service system calls and executes on the data entity are operations such as new addition, deletion, and change in this model. There is no limitation here.

[0068] As an example, as shown in FIG. 3 described above, in the "Policy Log" table, the "insurance amount" field with ID (i.e., the primary key) = 100 is recorded. The version number under the "initial version" field of the record in the first row is "1", corresponding to the case where the amount of the "insurance amount" field with the "initial version" of the "Policy Log" table being "1" is "1000".

[0069] When a forward operation is detected as a new data addition operation for the data entity where the "initial version" of the "Policy Log" table with the "primary key" = 100 (i.e., ID = 100) is "1", as shown in FIG. 3, the type "new addition" is recorded under the "version type" field of the record in the first row of the history version table "Policy Log". The version number "2" is written into the "initial version" field of the record in the second row, and the data entity - related information after the new addition of data with the "guaranteed amount" being "1500" is written into the record in the second row. In other embodiments, the history version table created based on this application may further include an "end version" field that may be recorded to indicate the basis of the modified data content of the data entity when the version number under the "initial version" field is updated, which is not limited here.

[0070] Similarly, after the above - mentioned new data addition operation, when other types of data operations are performed, such as continuing with a data modification operation, referring to the "Policy Log" table shown in FIG. 3, the data with the "initial version" of the record in the first row being "1" is called, recorded as the initial data in the third row of the "Policy Log" table, the type "modification" is written under the "version type" of the record in the third row, the version number "3" is written under the "initial version", and the "guaranteed amount" is updated to "1000".

[0071] When the data correction operation is completed, information about the corrected data entity is written in the fourth row record of the "Policy Log" table. Below the "Version Type" field of the fourth row record, the "Correction" type is written. Below the "Initial Version" field, the version number "5" is written. The corrected "Insurance Amount" is written as "2000", etc.

[0072] 204: When a rollback operation request for the target data entity is detected, the historical version information in the historical version table is retrieved and the data content of the corresponding historical version is updated.

[0073] For example, the server 200 receives an operation request for rolling back the data content of one or several data entities transmitted from the terminal device, and in response to the request, queries the corresponding history version table using a preset query statement, so as to obtain the version number information of the target data entity recorded in the history version table, for example, the version number of the "initial version" recorded in the corresponding history version table, etc. Further, the server 200 can update the data content of the corresponding version to the target data entity based on the obtained version number information. For example, by restoring the data content with the initial version of "1" to the target data entity, the service system can display the corresponding page after the service rollback, for example, the data content of the updated initial version on the page, but is not limited thereto. Note that the service system may generate the above rollback operation request to be sent to the server 200 based on, for example, a rollback operation performed by the user on the service system interface. In other embodiments, when the server 200 detects abnormal data reported by a global transaction, it can also roll back the global transaction. As an example, when the server 200 queries the data with the primary key = 100 and the history version 1, for example, the query can be performed using the following SQL.

[0074] Select * from XXX _ LOG where "primary key" = 100 "initial version" <= 1 Here, "XXX_LOG" is the name of the history version table of the target data entity, and may be, for example, the "Policy Log" table or the "Address Log" table shown in FIG. 3 above. The "primary key" may be, for example, the ID of the "Policy Log" table or the "Address Log" table shown in FIG. 3 described above. Therefore, the SQL in the above example can query the "Policy Log" table where the "primary key" = 101, and obtain the data of the "insurance amount" field with the initial version number of "Policy Log" being "1", that is, "1000".

[0075] That is, based on the initial version number "1" queried by the SQL in the above example, the "insurance amount" data on the service system interface can be quickly updated to the insurance amount "1000" corresponding to the initial version number "1" in "Policy Log".

[0076] Similarly, in the distributed system of the insurance business, when a user operates and modifies the "address" information, "insured person" information, "insured person information" of the insurance certificate generated by the service system interface, and the service system generates a corresponding rollback operation request according to the user's operation and sends it to the server 200, the server 200 executes this step 204, and based on information such as the version number recorded in the history version table corresponding to the target data entity, quickly obtains the corresponding initial version data entity to be rolled back, and can update it to the data content of the initial version according to the rollback operation request of the service system.

[0077] Based on the distributed transaction processing method shown in FIG. 2 described above, by means of a homogeneous history version table created corresponding to the data entity, the content and changes before and after the operation of the data entity are recorded. For a program module that supports the rollback function of the service system of the terminal device on the server 200, if a small amount of code such as SQL-related code for calling the history version table is added to the data access layer, the rollback ability of the distributed service system, or the data compensation ability corresponding to operations such as modification and cancellation can be realized. In addition, since the distributed transaction processing method according to the embodiment of the present application is an improvement realized in the server 200 connected to each terminal device, it can be applied to rollback operations of distributed service systems of various complexities, that is, the same data rollback logic corresponding to the flow shown in FIG. 2 described above can be adopted for various distributed service systems. Therefore, the work load of the development and maintenance of the related service system is also simplified to a certain extent, and no limitation is set here.

[0078] FIG. 4 is a schematic block diagram showing the software configuration of the server 200 according to the embodiment of the present invention. As shown in FIG. 4, taking the server to which the insurance service system is correspondingly connected as an example, the server 200 includes a service flow processing module 201, an insurance security data management module 202, a distributed transaction manager 203, and a database 204.

[0079] Here, the service flow processing module 201 responds to calls from the service system in which the terminal device operates to data entities in the database 204, and receives operation requests such as forward operation requests and rollback operation requests from the service system in which the terminal device operates. The service flow processing module 201 transmits the received operation requests to the insurance and securities data management module 202 for corresponding processing. Also, when the service flow processing module 201 determines that the operation to be executed next requires either a plurality of different data sources or multiple remote calls and data updates, it can be responsible for requesting the distributed transaction manager 203 to start a global transaction.

[0080] The insurance and securities data management module 202 is used to call and manage the insurance and securities data entities in the database 204. Based on the data table structure of the corresponding insurance and securities data entities in the database 204, it creates a corresponding history version table for the insurance and securities data entities, and is used to record version information before and after operations such as new addition, deletion, and change of insurance and securities data, and is further used to record data contents changed by the data operation. In other embodiments, in the case of non-insurance and securities data, the server 200 may also include a non-insurance and securities data management module 202 for managing non-insurance and securities data in the database 204, but is not limited thereto. The history version table created by the insurance and securities data management module 202 is synchronized with the distributed transaction manager 203, and can record data operations detected by the distributed transaction manager 203. For specific generation procedures, please refer to the related description of step 201 above, and the description is omitted here.

[0081] In addition, in response to the data operation request transferred by the service flow processing module 201, the insurance security data management module 202 executes operation requests for forward operations such as newly adding, deleting, and changing the requested target data entity, calls the requested target data entity in the database 204, and executes corresponding operations on the data entity. At the same time, the insurance security data management module 202 can also record the version information of the data entity before and after the corresponding operation, the specific data content before and after the data entity is operated, etc. based on the created history version table. Then, based on the version information recorded in the history version table during the forward operation of the target data entity, the data content corresponding to the initial version is read and restored to the target data entity, etc.

[0082] The distributed transaction manager 203 processes information regarding the opened global transaction and the registered transaction branches, is responsible for scheduling between the service flow processing module 201 and the insurance security data management module 202. For example, in accordance with the commit notification of the global transaction sent from the service flow processing module 201, it notifies the insurance security data management module 202 to commit the transaction branch, and in accordance with the rollback notification of the global transaction sent from the service flow processing module 201, it adjusts and notifies the insurance security data management module 202 to roll back the transaction branch.

[0083] The database 204 is used to store and manage a large number of data entities. Each data entity can be created in the database 204 to meet the data call requirements of the distributed service system. For example, in the case of an insurance service system, the data table structure can be created as shown in FIG. 3 above corresponding to the insurance amount and address data in the insurance certificate. Note that the data table structures corresponding to each data entity may be the same or different.

[0084] FIG. 5 is a schematic diagram showing the communication flow between partial structures in the server 200 during the implementation of the distributed transaction processing method according to the embodiment of the present application. As shown in FIG. 5, this communication flow includes the following steps.

[0085] 501: The insurance certificate data management module 202 creates a history version table of the same type for the data entity. Here, "of the same type" means that the created history version table is the same as or similar to the data table structure of the target data entity. For the specific generation procedure, please refer to the related description in step 201 above, and the description is omitted here.

[0086] 502: The insurance certificate data management module 202 adds an annotation that supports record modification to the insurance certificate data entity that needs to be recorded in the history version table, and initializes the history version table information. Note that for the process of adding an annotation that supports record modification to the insurance certificate data entity and the process of initializing the history version table, reference can be made to the related description in step 202 above, and the description is omitted here.

[0087] The process in which the insurance certificate data management module 202 creates and initializes the history version table may be synchronized, that is, the content executed by steps 501 and 502 above may be executed in one step without limitation.

[0088] 503: The service flow processing module 201 requests the distributed transaction manager 203 to start a global transaction.

[0089] For example, the program code executed by the service flow processing module 201 can determine whether there are operations that need to be executed next, whether multiple different data sources need to be involved, or whether multiple remote calls and data updates are required. If so, it requests the distributed transaction manager 203 to start a global transaction.

[0090] 504: The service flow processing module 201 receives forward operation requests such as new addition, deletion, and modification from the distributed service system. The forward operation refers to an operation performed on the target data entity of the initial version such as the above new addition, deletion, and modification. Specifically, since the relevant description in step 203 above can be referred to, the description is omitted here.

[0091] In some embodiments, the forward operation requests such as new addition, deletion, and modification sent by the distributed service system may be distributed transaction operation requests written to the MYSQL bin log event or update log event. In contrast, the service flow processing module 201 can analyze the received bin log event to obtain bin log data, or analyze the received update log event to obtain update log data, and thereby recognize forward operation requests such as addition, deletion, or modification from the obtained update log data.

[0092] 505: The service flow processing module 201 sends the received forward operation request to the insurance securities data management module 202.

[0093] For example, in step 503 above, after receiving an operation request for a forward operation such as new addition, deletion, modification, etc., the service flow processing module 201 can call the application programming interface (API) interface of the insurance and securities data management module 202, such as a network API interface based on the Restful interface, and can send the received forward operation request and the complete insurance and securities data of the requested operation to the insurance and securities data management module 202. The insurance and securities data management module 202 is responsible for executing the operation request and the update operation of the target data entity in the database.

[0094] 506: The insurance and securities data management module 202 executes operations such as new addition, deletion, and modification of the target data entity.

[0095] For example, in response to the received forward operation request, the insurance and securities data management module 202 can call the database interface to execute operations such as addition, deletion, and modification corresponding to the data content of the target data entity.

[0096] Among these, when processing requests such as new addition, deletion, and modification, the insurance security data management module 202 mirrors (i.e., copies) the data before and after the corresponding operation update of the target data entity and compiles it into an undo log, and utilizes the ACID characteristics of the local transaction to commit the update of the service data and the writing of the undo log to the same local transaction, thereby ensuring that there is an undo log corresponding to the committed update of the service data. Also, since a history version table is created, the undo log only needs to store the version number as index information and does not need to store the complete change content. When the insurance security data management module 202 executes a forward operation or a subsequent rollback operation on the data content of the target data entity, the undo log can read the data content of the corresponding version based on the version information provided by the history version table. Thereby, the data operation processing efficiency of the insurance security data management module 202 can be improved.

[0097] In this way, in the execution of the subsequent step 509, when the service flow processing module 201 determines to commit the global transaction, the insurance security data management module 202 notifies to commit the transaction branch through the distributed transaction manager 203. When completing the commit of the transaction branch, it does not require synchronous cooperation processing and only needs to clean up the undo log asynchronously. In this way, the commit can be completed quickly.

[0098] In other embodiments, Hibernate Interceptor (i.e., the interceptor) can be used to intercept all database update operations such as modification and deletion of target data entities. Hibernate can save the data-mirrored content in memory before and after the change of the data entity, and the interceptor can read the data content before and after these changes and write it to the local undo log table to realize data mirroring in the undo log, but it is not limited to this. In this way, the operation of reading the data mirroring before and after the change by SQL can be omitted, and the operability can be improved.

[0099] 507: The insurance securities data management module 202 records the version information before and after the operation, the operation type, the content, etc. in the corresponding history version table. Specifically, for the process of recording version information in the history version table, the relevant description in step 203 above can be referred to, so the description here is omitted.

[0100] In some embodiments, when executing step 503 described above, the service flow processing module 201 may send the analyzed bin log data or update log data to the distributed transaction manager 203. The distributed transaction manager 203 can update the corresponding version of the data content and the corresponding version information of the target data entity in the obtained history version table based on the received bin log data or update log data.

[0101] 508: The insurance securities data management module 202 registers the transaction branch with the distributed transaction manager 203. For example, after the insurance certificate data management module 202 executes the above step 507 and completes the recording of relevant fields and version information in the history version table, it can trigger the registration of a transaction branch to the distributed transaction manager 203. By registering the transaction branch, the insurance certificate data management module 202 temporarily stores some call information in the distributed transaction manager 203, so that when the global transaction is committed or rolled back, the distributed transaction manager 203 can perform a callback based on this temporarily stored call information.

[0102] 509: When the service flow processing module 201 confirms that there is no abnormality in the global transaction, it sends a request to the distributed transaction manager 203 to commit the global transaction. As an example, the service flow processing module 201 can obtain abnormalities reported on each interface or proxy node during the processing of the global transaction, such as database write failure, network abnormality, etc. If there is no abnormality, the service flow processing module 201 can call the commit interface of the distributed transaction manager 203 to request the commitment of the global transaction.

[0103] 510: The distributed transaction manager 203 notifies the insurance certificate data management module 202 to commit the transaction branch. For example, in response to the received request to commit the global transaction, the distributed transaction manager 203 can notify the insurance certificate data management module 202 to commit by committing the transaction branch. Based on the commit notification, the insurance certificate data management module 202 can delete the local undo log record.

[0104] After the service flow processing module 201 determines to commit a global transaction, the insurance security data management module 202 can notify the distributed transaction manager 203 to commit a transaction branch via the distributed transaction manager 203. At the same time, it does not require synchronous cooperation processing and only needs to asynchronously clean up the rollback log, that is, the process of committing the transaction branch can be completed quickly.

[0105] In some embodiments, in order to achieve the data content consistency of the import and export target data entities in the corresponding database, the distributed transaction manager 203 can obtain a list of active transactions at the current time. Among them, the active transaction list is for marking the completion degree of the import and export operations of the data tables of each data entity in the current database. The execution of the import and export operations on the data table of the target data entity is for realizing operations such as new addition, deletion, and modification on the corresponding data table. Further, when the distributed transaction manager 203 derives the target data entity from the database and performs operations such as new addition, deletion, and modification, it generates a data consistency compensation statement based on the active transaction list and the log of the database, and instructs the corresponding database to execute the statement, so that in the process of performing operations such as new addition, deletion, and modification on the target data entity, the data content of the target data entity imported and exported from the database is consistent. The log of this database may be, for example, the log data obtained by the service flow processing module 201 analyzing bin log events and update log events in step 503 above.

[0106] In other embodiments, the distributed transaction manager 203 may, in other ways, ensure that the data content is consistent when the data entities being operated on are imported and exported from the corresponding databases, which is not limited herein.

[0107] 511: When the service flow processing module 201 confirms an abnormality in the global transaction, it sends a request to the distributed transaction manager 203 to roll back the global transaction. For example, when the service flow processing module 201 receives a rollback operation request from the distributed service system or obtains abnormal data such as a database write failure or a network abnormality, it confirms that there is an abnormality in the global transaction and can call the rollback interface of the distributed transaction manager 203 to request a rollback of the global transaction.

[0108] When the service flow processing module 201 confirms a rollback of the global transaction, the rollback may be adjusted by the distributed transaction manager. For example, the distributed transaction manager 203 may execute step 512 of notifying the insurance securities data management module 202 to roll back the transaction branch.

[0109] In other embodiments, the service flow processing module 201 may also receive a rollback operation request sent by the distributed service system in response to a user operation, generate a rollback request for the global transaction, and enable a fast rollback of the service data. There is no limitation herein.

[0110] Here, the rollback operation request from the distributed service system may be, for example, a distributed transaction operation request recorded in the bin log event of MYSQL. In contrast, the service flow processing module 201 can analyze the received bin log event to obtain bin log data, such as a rollback operation request. Furthermore, the service flow processing module 201 can identify the rollback operation request based on the analyzed bin log data.

[0111] 512: The distributed transaction manager 203 notifies the insurance and securities data management module 202 to roll back the transaction branch. For example, in response to a request to roll back the received global transaction, the distributed transaction manager 203 can notify the insurance and securities data management module 202 to roll back the transaction branch and notify the insurance and securities data management module 202 of the rollback. Based on the rollback notification, the insurance and securities data management module 202 can perform a data restoration operation based on the version information recorded in the history version table. It is more efficient, faster, and more direct to perform a data restoration operation based on the version information recorded in the history version table.

[0112] 513: The insurance and securities data management module 202 reads the data content of the corresponding version from the database based on the historical version information before the change and restores it to the called target data entity. Note that the historical version information may be, for example, the initial version number. Specifically, for the process of obtaining the historical version information, reference can be made to the relevant description in step 204 above, but it is not limited here.

[0113] When the insurance security data management module 202 receives a rollback notification from the distributed transaction manager 203, it finds the corresponding rollback log record via the global transaction id (i.e., XID) and the transaction branch id (i.e., Branch ID), reads the corresponding data content in the history version table based on the history version information in the rollback log record, and can further generate and execute reverse update SQL to complete the rollback of the transaction branch.

[0114] Therefore, the distributed transaction processing technology based on the history version table according to the present application can enable the insurance security data management module 202 to realize the functions of shortcut operations and rollbacks based on the history version, and there is no need to reread and store the data content before and after the change. It can be realized only by reading or recording the history version ID corresponding to the corresponding insurance security data (i.e., the target data entity).

[0115] When the insurance security data management module 202 restores the data content to the target data entity based on the history version information, the interface display content of the corresponding distributed service system is also updated to the data content of the corresponding history version. Specifically, reference can be made to the related description of step 204 above, which is not limited here.

[0116] FIG. 6 is a schematic diagram showing the hardware configuration of the server 200 according to an embodiment of the present invention. As shown in FIG. 6, in some embodiments, the server 200 may include one or more processors 604, system control logic 608 connected to at least one of the processors 604, system memory 612 connected to the system control logic 608, non-volatile memory (NVM) 616 connected to the system control logic 608, and a network interface 620 connected to the system control logic 608.

[0117] In some embodiments, the processor 604 may include one or more single-core or multi-core processors. In some embodiments, the processor 604 may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments where the server 200 uses an eNB (Evolved Node B) 101 or a RAN (Radio Access Network) controller 102, the processor 604 may be configured to execute various compatible embodiments, such as one or more of the embodiments shown in FIGS. 2-5.

[0118] In some embodiments, the system control logic 608 may include any suitable interface controller to provide any suitable interface to at least one of the processors 604 and / or any suitable device or component that communicates with the system control logic 608.

[0119] In some embodiments, the system control logic 608 may include one or more memory controllers that provide an interface connected to the system memory 612. The system memory 612 can be used to load and store data and / or instructions. In some embodiments, the memory 612 of the server 200 may include any suitable volatile memory, such as a suitable dynamic random access memory (DRAM). The NVM / memory 616 may include one or more tangible non-transitory computer-readable media for storing data and / or instructions. In some embodiments, the NVM / memory 616 may include any suitable non-volatile memory, such as flash memory, and / or at least one of any suitable non-volatile storage device, such as a hard disk drive (HDD), a compact disc (CD) drive, or a digital versatile disc (DVD) drive. The NVM / memory 616 may include a portion of the storage resources on the device on which the server 200 is installed, or the NVM / memory 616 may not necessarily be part of the device but can be accessed by the device. For example, the NVM / storage 616 may be accessed via a network through the network interface 620.

[0120] In particular, the system memory 612 and the NVM / memory 616 may each include a temporary copy and a permanent copy of the instructions 624. The instructions 624 may include instructions that cause the server 200 to execute methods as shown in FIGS. 3-4 when executed by at least one of the processors 604. In some embodiments, the instructions 624, the hardware, the firmware, and / or its software components may be additionally / alternatively disposed within the system control logic 608, the network interface 620, and / or the processor 604.

[0121] The network interface 620 provides a wireless interface to the server 200 and may include a transceiver for communicating with any other suitable device (e.g., a front-end module, an antenna, etc.) via one or more networks. In some embodiments, the network interface 620 may be integrated with other components of the server 200. For example, the network interface 620 may be integrated with at least one of the processor 604, the system memory 612, the NVM / memory 616, and a firmware device (not shown) having instructions, and the server 200 may execute the methods shown in FIGS. 2-5 above when at least one of the processors 604 executes the instructions. The network interface 620 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output wireless interface. For example, the network interface 620 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0122] In one embodiment, at least one of the processors 604 may be packaged with the logic of one or more controllers of the system control logic 608 to form a system package (SiP). In one embodiment, at least one of the processors 604 may be integrated on the same die as the logic of one or more controllers of the system control logic 608 to form a system-on-chip (SoC).

[0123] The server 200 may further include an input / output (I / O) device 632. The I / O device 632 may include a user interface that enables a user to communicate with the server 200, and the design of the peripheral component interface enables peripheral components to also communicate with the server 200. In some embodiments, the server 200 further includes a sensor for determining at least one of the environmental conditions and location information associated with the server 200.

[0124] In some embodiments, the user interface may include, but is not limited to, a display (e.g., a liquid crystal display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., a light emitting diode flash), and a keyboard.

[0125] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0126] In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of the network interface 620 or communicate with the network interface 620 to communicate with components of a positioning network (such as Global Positioning System (GPS) satellites).

[0127] References to "one embodiment" or "an embodiment" in this specification mean that at least one exemplary embodiment or technique disclosed in accordance with the embodiments of this application includes the particular features, structures, or characteristics described in connection with the embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment.

[0128] The disclosure of embodiments of this application also relates to an apparatus for performing operations within a text. The apparatus may in particular be constructed for a desired purpose, or may include a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored on a computer-readable medium such as, but not limited to, a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application specific integrated circuit (ASIC), or any type of disk suitable for storing electronic instructions, each of which may be coupled to a computer system bus. Further, the computers referred to herein may include a single processor or may be architectures that use multiple processors for increased computing capabilities.

[0129] Furthermore, the language used herein has been principally selected for readability and for the purpose of guidance, and may not have been selected to depict or limit the disclosed subject matter. Accordingly, the disclosure of embodiments of this application is intended to exemplify the scope of the concepts discussed herein and not to limit it.

Claims

1. A distributed transaction processing method applied to a system including a service flow processing module, an insurance security data management module, and a distributed transaction manager, comprising: The insurance security data management module creates and initializes a history version table, where the history version table is for recording data contents and version information of each version of a target data entity. The initialized version information includes first version information, and the first version information corresponds to the data contents of the first version of the target data entity; The service flow processing module requests the distributed transaction manager to start a global transaction; The service flow processing module receives a first type of operation request for the target data entity and sends the first type of operation request to the insurance security data management module. The first type of operation request is for requesting to execute a first type of operation on the data contents of the first version of the target data entity, and the first type of operation includes at least one of addition, deletion, and modification operations; The insurance security data management module, in response to the first type of operation request, reads the history version table, records the data contents of the second version obtained by executing the first type of operation on the data contents of the first version, and registers a transaction branch with the distributed transaction manager. The transaction branch is a related transaction for executing the first type of operation; The distributed transaction manager, in response to a first request to commit the global transaction sent by the service flow processing module, notifies the insurance security data management module to commit the transaction branch. A distributed transaction processing method characterized by including the above.

2. Reading the history version table and recording the data contents of the second version obtained by executing the first type of operation on the data contents of the first version is: The insurance security data management module writes the data content of the second version to the history version table, and writes second version information to the history version table corresponding to the data content of the second version, The insurance security data management module writes the first version information and the second version information to a log for canceling the rollback, and the distributed transaction processing method according to claim 1, characterized in that it includes this.

3. The service flow processing module obtains abnormal data in the global transaction or a second type of operation request for the target data entity received, and sends a second request for rolling back the global transaction to the distributed transaction manager, where the second request is for updating the data content of the target data entity from the data content of the second version to the data content of the first version, and is for requesting to roll back the global transaction. The distributed transaction manager notifies the insurance security data management module to roll back the transaction branch in response to the second request. The insurance security data management module further includes obtaining the data content of the first version based on the first version information recorded in the history version table, and restoring it to the current data content of the target data entity, based on the notification to roll back the transaction branch, and the distributed transaction processing method according to claim 2, characterized in that it includes this.

4. The log for canceling the rollback includes a rollback log, and obtaining the data content of the first version based on the first version information recorded in the history version table of the above The insurance security data management module obtains the first version information recorded in the rollback log. The insurance security data management module obtains the data content of the first version based on the correspondence between the first version information recorded in the history version table and the data content of the first version, and the distributed transaction processing method according to claim 3, characterized in that it includes this.

5. The history version table is created by a method of creating a history version table identical to the first data table structure based on the first data table structure corresponding to the target data entity, and is characterized in that it is the distributed transaction processing method according to claim 4.

6. The parameter list of the history version table includes a primary key, a type, an initial version, and a service field waiting for recording, and the version information includes a version number recorded in the initial version field of the history version table, and is characterized in that it is the distributed transaction processing method according to claim 5.

7. Each parameter in the parameter list of the history version table is associated with each parameter in the first data table structure, and the association is created by adding first annotation information to the first data table structure by an annotation tool preset in the insurance certificate data management module, and when the first annotation information is analyzed by the storage management engine, it is used to update each parameter of the history version table according to the change of each parameter of the first data table structure, and is characterized in that it is the distributed transaction processing method according to claim 6.

8. The preset annotation tool is @Audit provided by Hibernate Envers, and the storage management engine is Hibernate, and is characterized in that it is the distributed transaction processing method according to claim 7.

9. The first version information is the first version number recorded in the initial version field of the history version table, and is characterized in that it is the distributed transaction processing method according to claim 5.

10. When the insurance certificate data management module reads the history version table in response to the first type of operation request, it includes that the insurance certificate data management module reads the history version table based on a preset SQL including at least the name, primary key, and version number recorded corresponding to the initial version field of the history version table, and is characterized in that it is the distributed transaction processing method according to claim 5.

11. The first type of operation request is a distributed transaction operation request written in the bin log event or update log event of MYSQL, That the service flow processing module receives the first type of operation request for the target data entity and sends the first type of operation request to the distributed transaction manager That the service flow processing module determines that the first type of operation request is a distributed transaction operation request written in the bin log event or update log event of MYSQL That the service flow processing module analyzes the received bin log event to obtain bin log data, or analyzes the received update log event to obtain update log data That the service flow processing module identifies a distributed transaction operation request corresponding to an addition, deletion, or modification operation based on the bin log data or the update log data That the service flow processing module sends the identified distributed transaction operation request to the insurance certificate data management module as the first type of operation request, and the distributed transaction processing method according to any one of claims 1 to 10 is characterized by including this

12. The second type of operation request is a distributed transaction operation request written in the bin log event of MYSQL, That the service flow processing module receives the second type of operation request for the target data entity and sends a second request to roll back the global transaction to the distributed transaction manager That the service flow processing module analyzes the received bin log event to obtain bin log data That the service flow processing module identifies a rollback operation request that requires updating the data content of the returned second version to the data content of the first version based on the bin log data The service flow processing module includes sending, to the distributed transaction manager, a second request to roll back a global transaction based on the identified rollback operation request, and is characterized in that it is the distributed transaction processing method according to any one of claims 3 to 10.

13. The second type of operation request includes a request to cancel the first type of operation, and a request to call the data content of the first version and re-execute the first type of operation, and is characterized in that it is the distributed transaction processing method according to claim 10.

14. The target data entity is stored in a database for distributed transactions, in the process of executing the first type of operation, the distributed transaction manager obtains the active transaction list at the current time, where the active transaction list is for marking the execution progress of the first type of operation executed on each data entity in the database, and each data entity in the database includes the target data entity; and the distributed transaction manager generates a consistency compensation statement and a compensation instruction based on the active transaction list and the log data corresponding to the target data entity generated by the current database, and sends them to the database, where the compensation instruction is for instructing the database to execute the consistency compensation statement to update the real-time data content corresponding to the execution progress of the first type of operation to the data content of the target data entity in the database, thereby matching the data content of the target data entity stored in the database with the real-time data content of the target data entity operated by the insurance and securities data management module, and is characterized in that it is the distributed transaction processing method according to claim 1.

15. A distributed transaction processing system including a service flow processing module, an insurance and securities data management module, and a distributed transaction manager, where the insurance and securities data management module Creating and initializing a history version table, where the history version table is for recording data contents and version information of each version of a target data entity, the initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity, and In response to a first type of operation request, reading the history version table, recording the data content of the second version obtained by performing a first type of operation on the data content of the first version, and registering a transaction branch with the distributed transaction manager, where the transaction branch is a related transaction for performing the first type of operation, and is used for The service flow processing module Receiving a first type of operation request for the target data entity and sending the first type of operation request to the insurance and securities data management module, where the first type of operation request is for requesting to perform a first type of operation on the data content of the first version of the target data entity, and the first type of operation includes at least one of addition, deletion, and modification operations, and Obtaining abnormal data in the global transaction or a second type of operation request for the target data entity received, and sending a second request for rolling back the global transaction to the distributed transaction manager, where the second request is for requesting a rollback of the global transaction in order to update the data content of the target data entity from the data content of the second version to the data content of the first version, and is used for The distributed transaction manager Receiving a notification sent by the service flow processing module to start a global transaction, and receiving a request to register a transaction branch from the insurance and securities data management module, and storing the registration information of the transaction branch, and Based on a notification to commit a global transaction sent by the service flow processing module, notifying the insurance security data management module to commit a transaction branch, and being used for A distributed transaction processing system characterized by the above.

16. An apparatus comprising One or more processors and one or more memories, The one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the apparatus is caused to execute the distributed transaction processing method according to any one of claims 1 to 14. An apparatus characterized by that.

17. A computer-readable storage medium, The storage medium stores instructions for causing a computer to execute the distributed transaction processing method according to any one of claims 1 to 14 when executed by the computer. A computer-readable storage medium characterized by that.

Images