WO2023231665A1 - 分布式事务处理方法、系统、设备及可读存储介质 - Google Patents

分布式事务处理方法、系统、设备及可读存储介质 Download PDF

Info

Publication number
WO2023231665A1
WO2023231665A1 PCT/CN2023/091220 CN2023091220W WO2023231665A1 WO 2023231665 A1 WO2023231665 A1 WO 2023231665A1 CN 2023091220 W CN2023091220 W CN 2023091220W WO 2023231665 A1 WO2023231665 A1 WO 2023231665A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
data
type
transaction
request
Prior art date
Application number
PCT/CN2023/091220
Other languages
English (en)
French (fr)
Inventor
施瑜
蔡纯钢
王嘉杰
吴秀群
王广贵
莫元武
Original Assignee
易保网络技术(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 易保网络技术(上海)有限公司 filed Critical 易保网络技术(上海)有限公司
Publication of WO2023231665A1 publication Critical patent/WO2023231665A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the invention relates to the field of software technology, and specifically to a distributed transaction processing method, system, equipment and readable storage medium.
  • Distributed transactions refer to the fact that the participants of the transaction, the server that supports the transaction, the resource server and the transaction manager are located on different nodes in different distributed systems.
  • a transaction is a program execution unit (unit) that operates a certain data item in the database.
  • Seata implemented based on the XA specification, is an open source distributed transaction solution that is committed to providing high-performance and easy-to-use distributed transaction services under a microservice architecture.
  • Seata provides users with four transaction processing models: AT, TCC (Try-Confirm-Cancel), long transaction model (SAGA) and XA.
  • AT and XA are models for processing rigid transactions.
  • TCC and SAGA are models for processing flexible transactions, and flexible transactions allow intermediate states to support the transformation of the business layer, such as applications (Application, APP). Therefore, in the distributed scenarios of some large websites, TCC, The SAGA model is widely used.
  • the TCC model can provide three business interfaces: preliminary operation (Try), confirmation operation (Confirm), and cancellation operation (Cancel) for main business calls. Therefore, TCC divides the transaction running process into the Try and Confirm phases, and the Cancel phase.
  • the Cancel phase can implement business rollback (rollback) of transactions processed by Try and Confirm.
  • SAGA implements business rollback based on reverse compensation operations of a series of operations. Taking the insurance business as an example, the aforementioned business rollback may be a modification operation to a created policy, or a cancellation operation (i.e. surrender) of a generated policy, etc.
  • the rollback is usually completed by reading the changes before and after the data change in the corresponding Structured Query Language (SQL) at the bottom of the database, or based on the rollback code.
  • SQL Structured Query Language
  • Business rollback The implementation of this kind of business rollback cannot be applied to the business layer (such as the application itself).
  • the rollback logic is complex and difficult to implement. The development, maintenance, and transformation costs involved in realizing the corresponding business rollback function are high.
  • Embodiments of the present application provide a distributed transaction processing method, system, device and readable storage medium.
  • the method can record the version information of the corresponding data entity before and after data operations such as addition, deletion, change (or modification) and so on.
  • Related information quickly obtain the historical version of the data content before the data operation was performed on the data entity to implement rollback. Improve the business rollback capability of distributed systems, thus helping to improve user experience.
  • embodiments of the present application provide a distributed transaction processing method, which is used in a system including a business process processing module, a policy data management module and a distributed transaction manager.
  • the method includes:
  • the policy data management module creates and initializes the historical version table, where the historical version table is used to record the data content and version information of each version of the target data entity.
  • the initialized version information includes the first version information, and the first version information corresponds to the target data entity.
  • the business process processing module requests the distributed transaction manager to start a global transaction
  • the business process processing module receives the first type of operation request for the target data entity and sends the first type of operation request to the policy data management module, where the first type of operation request is used to request the first version of the data content of the target data entity.
  • Perform the first type of operation which includes at least one of adding, deleting, and modifying operations;
  • the policy data management module responds to the first type of operation request, reads the historical version table, records the second version of the data content obtained by performing the first type of operation on the first version of the data content, and registers the branch transaction with the distributed transaction manager, where Branch transactions are related transactions that perform the first type of operations;
  • the distributed transaction manager notifies the policy data management module to submit the branch transaction according to the first request from the business process processing module to submit the global transaction.
  • the historical version table can be created through the policy data management module of the system itself that manages data entities related to policy data, so that the created historical version table and the data table of the target data entity can be controlled during the creation process.
  • the structure is the same, that is, isomorphism is achieved.
  • the system detects that the data table storage content of the target data entity is updated, it can use the created historical version table to promptly record the data content before and after the update and write the corresponding version information, so as to facilitate the subsequent execution of other business calls to the system.
  • the data content of the corresponding version can be quickly called based on the version information recorded in the historical version table.
  • the business process processing module in the system can be connected to the distributed business system client to receive business operation requests initiated by users operating on the business system client, and then forward them to relevant parties in the system based on the request content and request target of the business operation request.
  • the module executes, for example, forwarding the received first type operation request to the policy data management module for processing.
  • the program code executed by the business process processing module can request the distributed transaction manager to open when it is determined that the next operation to be performed needs to involve multiple different data sources/or requires multiple remote calls and data updates. Global affairs. In this way, it is helpful to improve the system's efficiency in classifying business operation requests.
  • the above-mentioned first type of operation request is the operation request corresponding to the forward operation described in the embodiment below.
  • the first type of operation is the forward operation.
  • the above-mentioned first type of operation request can be, for example, the insurance user creates a new policy on the insurance business client and fills in the policyholder/insured person's personal information, insurance amount, address, etc. on the client interface. The operation request is triggered accordingly.
  • the distributed transaction manager in the system can call the historical version table created by the policy data management module.
  • the above-mentioned first version data content can be, for example, the initial version of the target data entity. content, so the distributed transaction manager can obtain the initial content of the target data entity through the first version information in the historical version table, and process the first type of operation request based on the obtained initial content. It can be understood that if the policy data management module creates the historical version table of the target data entity and the record content in the historical version table is updated, the policy data management module can quickly use the historical version table when responding to the above first type of operation request. Obtaining the initial content of the target data entity used to process the corresponding business operation request is beneficial to improving distributed transactions. Manager's business processing efficiency.
  • the historical version table is read and the second version data content obtained by performing the first type of operation on the first version data content is recorded, including:
  • the policy data management module writes the second version data content into the historical version table, and writes the second version information into the historical version table corresponding to the second version data content;
  • the policy data management module writes the first version information and the second version information into the log for revocation and rollback.
  • the policy data management module when it processes requests for addition, deletion, change, etc., it can use the log used for undo rollback in distributed transactions to read version information, and then read the data content of the corresponding version according to the historical version table.
  • the log used for undo rollback only needs to store the version number as index information, and does not need to store the complete change content. In this way, the data operation and processing efficiency of the policy data management module can be improved.
  • the above method further includes:
  • the business process processing module obtains abnormal data in the global transaction or receives a 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, where the second request is used to request Roll back the global transaction to update the data content of the target data entity from the second version data content back to the first version data content;
  • the distributed transaction manager notifies the policy data management module to roll back the branch transaction according to the second request;
  • the policy data management module Based on the notification of rolling back the branch transaction, the policy data management module obtains the first version data content based on the first version information recorded in the historical version table and restores it to the current data content of the target data entity.
  • the above-mentioned second type of operation can be, for example, a rollback operation request initiated by the client of the distributed business system.
  • the abnormal data obtained by the business process processing module in the global transaction can be, for example, the corresponding data operation on the called data entity on the business system.
  • the business process processing module may send a second request to roll back the global transaction to the distributed transaction manager, that is, a request to roll back the global transaction.
  • the distributed transaction manager can respond to the request and notify the policy data management module to roll back the branch transaction.
  • the policy data management module can read and call the updated historical version table, and quickly obtain the historical version data content before the data operation is performed on the data entity to implement rollback. In this way, the response processing efficiency of the distributed business system to rollback transactions can be improved, which is beneficial to improving the rollback capability of the system. It can be understood that the version information recorded in the historical 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 steps.
  • the log used for undo rollback includes a rollback log, and the first version data content is obtained according to the first version information recorded in the historical version table, including:
  • the policy data management module obtains the first version of information recorded in the rollback log
  • the policy data management module obtains the first version data content based on the correspondence between the first version information recorded in the historical version table and the first version data content.
  • the policy data management module when it processes rollback operation requests or abnormal rollback transactions, it can use the rollback log (undo log) to read version information, and then read the data content of the corresponding version according to the historical version table.
  • the undo log only needs to store the version number as index information, and does not need to store the complete change content. In this way, the data operation and processing efficiency of the policy data management module can be improved.
  • the historical version table is created in the following manner: according to the first data table structure corresponding to the target data entity, a historical version table with the same structure as the first data table is created.
  • the historical version table created by the policy data management module is has the same structure as the data table of the target data entity.
  • the above-mentioned first data table structure is the structure of any data table or a type of data table corresponding to the target data entity.
  • the parameter list of the historical version table includes primary key, type, starting version and business fields to be recorded, and the version information includes the values recorded in the starting version field of the historical version table. version number.
  • the above-mentioned primary key and the business field to be recorded correspond to the data content recorded in the historical version table, where the primary key can be, for example, the ID of the policy data, and the business field to be recorded can be, for example, insurance amount, address and other fields.
  • the types in the historical version table can record the operation types corresponding to the aforementioned first type of operations, such as adding, deleting, modifying, etc.
  • the initial version in the above historical version table is, for example, an identification symbol written in accordance with the preset version number setting rules corresponding to the recorded data version information. It can be understood that every time the data content is updated, the initial version number (referred to as the initial version number) recorded in the historical version table corresponds one-to-one with the data content before and after the update.
  • the data content of each version corresponds to a starting version number.
  • the starting version number can be used as the basis for obtaining the corresponding version data content when the policy data management module performs the first type of operation in response to the first type of operation request, or rolls back the branch transaction based on the notification of the rollback branch transaction of the distributed transaction manager. Identify information to enable quick access to data content.
  • obtaining the data content of the corresponding version through the version information such as the starting version number recorded in the historical version table can replace the original distributed transaction processing of calling the target data entity from the database and the modification log of the target data entity.
  • the complex calling process can improve the efficiency of obtaining the corresponding data content, thereby improving the processing efficiency of distributed transactions.
  • each parameter in the parameter list of the historical version table is associated with each parameter in the first data table structure, and the association is created in the following way: the policy data management module passes The preset annotation tool adds the first annotation information to the first data table structure.
  • the first annotation information is parsed by the storage management engine, it is used to update the historical version table according to changes in various parameters in the first data table structure.
  • the default annotation tool is @Audit provided by Hibernate Envers, and the storage management engine is Hibernate.
  • the policy data management module has the advantage of calling the content and structure of the target data entity it manages. Therefore, after the policy data management module creates the historical version table, it can use the @Audit Java class annotation provided by Hibernate Envers to check the target data. Add annotations to the Java class of the entity's data table structure. In this way, after Hibernate, the engine responsible for database storage, parses this annotation in the code, it can simultaneously record the data content and version information before and after the corresponding update in the historical version table when the corresponding data table content of the data entity is updated. This method of recording data entity updates and changes through historical version tables has simple logic and easy operation. It has little impact on the original database and distributed transaction processing processes, and can also help improve the efficiency of distributed transaction processing.
  • the first version information is the first version number recorded in the starting version field in the historical version table.
  • the first version information is the starting version number corresponding to the first version data content recorded in the historical version table.
  • obtaining the historical version table from the policy data management module includes:
  • the policy data management module responds to the first type of operation request and reads the historical version table, including:
  • the policy data management module reads the historical version table based on the preset SQL, where the preset SQL at least includes the name of the historical version table, the primary key, and the version number of the corresponding record in the starting version field.
  • the policy data management module when it responds to the first type of operation request, it can complete the response through a simple SQL statement.
  • the query process execution statement is simple and efficient, and the efficiency of obtaining the corresponding data content can also be improved.
  • the first type of operation request is a distributed transaction operation request written in the bin log event or update log event of MYSQL; and, the business process processing module receives the target data
  • the first type of operation request of the entity, and forwarding the first type of operation request to the policy data management module includes:
  • the business process processing module determines that the first type of operation request is a distributed transaction operation request in the bin log event or update log event written to MYSQL;
  • the business process processing module parses the received bin log event to obtain bin log data, or parses the received update log event to obtain update log data;
  • the business process processing module identifies distributed transaction operation requests corresponding to add, delete, or modify operations based on bin log data or update log data;
  • the business process processing module forwards the identified distributed transaction operation request to the policy data management module as a first-type operation request.
  • the data changes recorded at the bottom of the database can be obtained into the Java program executed by the application layer.
  • the data acquisition method is simple, direct and timely.
  • this method of obtaining operation request data can also avoid code modifications to servers that support distributed business systems, which is beneficial to reducing the development workload corresponding to server or system modifications.
  • the second type of operation request is a distributed transaction operation request written in the bin log event of MYSQL; and, the business process processing module receives the second type of operation request for the target data entity.
  • Class operation request sending a second request to roll back the global transaction to the distributed transaction manager, including:
  • the business process processing module parses the received bin log events to obtain bin log data
  • the business process processing module Based on the bin log data, the business process processing module identifies the rollback operation request that requests to update the returned second version data content back to the first version data content;
  • the business process processing module sends a second request to roll back the global transaction to the distributed transaction manager based on the recognized rollback operation request.
  • the above is to identify the rollback operation request or abnormal operation data of distributed transactions by parsing the bin log event of MYSQL to determine whether it is necessary to perform rollback processing on the data content of the target data entity in the database.
  • the data changes recorded at the bottom of the database can be Or the abnormal data is obtained into the Java program executed by the application layer.
  • the data acquisition process is simple, direct and timely, and it is helpful to reduce the development workload corresponding to server or system modification.
  • the second type of operation request includes: a request to cancel the first type of operation, or a request to call the first version of the data content to perform the first type of operation again.
  • the above-mentioned request to cancel the first type of operation is, for example, a distributed transaction rollback request initiated by the user through a rollback operation through the client of the distributed business system. For example, when the user pays the insurance amount, the operation returns to the previously filled policy information page. Confirm again to trigger the rollback operation request initiated by the client, etc.
  • the above-mentioned request to cancel the first type of operation may also be a recovery request initiated when the business system client is abnormal, to request recovery to the original data content. There are no restrictions here.
  • the policy data management module can also quickly use the first version information recorded in the historical version table. Quickly obtain the first version of data content for processing.
  • the target data entity is stored in a database for distributed transactions, and the method includes:
  • the data content of the target data entity stored in the database is consistent with the real-time data content of the target data entity operated by the policy data management module in the following manner: the distributed transaction manager obtains the current moment's data content An active transaction list, where the active transaction list is used to mark the execution progress of the first type of operations performed on each data entity in the database, and each data entity in the database includes the target data entity;
  • the distributed transaction manager generates consistency compensation statements and compensation instructions based on the active transaction list and the log data generated by the current database corresponding to the target data entity and sends them to the database, where the compensation instructions are used to instruct the database to execute the consistency compensation statement. 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.
  • the distributed transaction manager when the distributed transaction manager exports the target data entity from the database to perform operations such as adding, deleting, and changing, it can generate a data consistency compensation statement based on the active transaction list and the log corresponding to the target data entity recorded in the database. And instruct the corresponding database to execute the statement and update the data content of the target data entity in the database. In this way, it can be ensured that during the process of distributed transaction processing, the data content stored in the database is consistent with the data content being operated on in a timely manner, so that when other distributed systems call the corresponding data content in the database, the data content is exported in real time. .
  • the data content before the corresponding operation can be recorded in the historical version table.
  • the corresponding data content can be obtained based on the corresponding version information for processing, without the need to record it from the database.
  • the corresponding log to obtain the historical data content. Based on this, the efficiency of distributed transaction processing and the timeliness of updating database data content can be effectively improved.
  • inventions of this application provide a system.
  • the system includes a business process processing module, a policy data management module, and a distributed transaction manager.
  • the policy data management module is used to create and initialize a historical version table.
  • the historical version table is The version table is used to record each version data content and version information of the target data entity.
  • the initialized version information includes first version information, and the first version information corresponds to the first version data content of the target data entity; and is used to respond to the first version of the target data entity.
  • a type of operation request reads the historical version table, records the second version of the data content obtained by performing the first type of operation on the first version of the data content, and registers a branch transaction with the distributed transaction manager, where the branch transaction is the execution of the first type of operation. Operation related matters;
  • the business process processing module is used to receive the first type of operation request for the target data entity and send the first type of operation request to the policy data management module, where the first type of operation request is used to request the first version of the target data entity.
  • the data content performs the first type of operation.
  • the first type of operation includes at least one of adding, deleting, and modifying operations; and is used to obtain abnormal data in the global transaction or the second type of operation request received for the target data entity. , and sends a second request to roll back the global transaction to the distributed transaction manager, where the second request is used to request to roll back the global transaction to update the data content of the target data entity from the second version data content back to the first version data content;
  • the distributed transaction manager is used to receive notifications from the business process processing module to start global transactions, receive requests from the policy data management module to register branch transactions, and store the registration information of branch transactions; and to receive notifications from the business process processing module.
  • the notification to submit the global transaction notifies the policy data management module to submit the branch transaction.
  • embodiments of the present application provide a device, including: one or more processors; one or more memories; one or more memories store one or more programs. When one or more programs are processed by a When executed by multiple processors, the device executes the distributed transaction processing method provided by the first aspect.
  • embodiments of the present application provide a computer-readable storage medium. Instructions are stored on the storage medium. When the instructions are executed on a computer, they cause the computer to execute the distributed transaction processing method provided in the first aspect.
  • Figure 1 shows a schematic diagram of an application scenario of a distributed business system provided by an embodiment of the present application.
  • Figure 2 shows a schematic flowchart of the implementation of a distributed transaction processing method provided by an embodiment of the present application.
  • Figure 3 shows a historical version representation of the addition of some data entities in the policy database provided by the embodiment of the present application.
  • Figure 4 shows a schematic block diagram of the software structure of a server 200 provided by an embodiment of the present application.
  • Figure 5 shows a schematic diagram of the interaction flow between some structures in the server 200 during the implementation of a distributed transaction processing method provided by an embodiment of the present application.
  • Figure 6 shows a schematic diagram of the hardware structure of a server 200 provided by an embodiment of the present application.
  • Database used to store a large number of data entities.
  • Database design is the process of planning and structuring the data entities in the database and the relationships between these data entities.
  • each data entity can use a data table structure to record the individual data corresponding to the data object and the association between individual data. Therefore, the data table structure of each data entity may include one or more interrelated data tables, and the primary keys of each data table are interrelated. For example, the primary key of one data table may be a foreign key of another data table, etc.
  • the data table consists of three parts: the table name, the fields in the table, and the records of the table. Designing the data table structure (hereinafter referred to as the 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 the computer.
  • Primary key refers to one column or a combination of multiple columns in the data table, whose value can uniquely identify each row in the table.
  • the primary key of one data table can be associated with the foreign key of other tables to associate the addition, deletion, change/modification, etc. of field text in other data tables.
  • ACID characteristics refer to the four characteristics that database management systems (DBMS) must possess in order to ensure that transactions are correct and reliable during the process of writing or updating data: Atomicity (Atomicity) , or indivisibility), consistency (Consistency), isolation (Isolation, also known as independence), and durability (Durability).
  • Figure 1 shows a schematic diagram of an application scenario of a distributed business system according to an embodiment of the present application.
  • this scenario includes interactions between terminal devices 100a, 100b and the server 200.
  • the server 200 may include multiple databases, a transaction manager for processing distributed transactions, etc., to provide distributed data services to each terminal device.
  • the business system may be an insurance business system, such as Users who want to apply for insurance can log in to the system account on the insurance business system running on the terminal device 100a, select insurance items, fill in personal information, generate policies, pay premiums, etc.
  • the corresponding operation data will be accessed into the corresponding database of the server 200.
  • the business system running on the terminal device 100a at this time will perform corresponding business rollback to support the user's return or modification operations.
  • another user or a platform operator of the corresponding business system can also enter the business system through another terminal device 100b.
  • insurance service personnel can log in to the insurance business system through the terminal device 100b to view or approve the policy content.
  • the terminal device 100b can obtain the corresponding policy data from the policy database on the server 200 and display it on the screen of the terminal device 100b.
  • the insurance service personnel can also modify or cancel the generated policy at the user's request.
  • the business system running on the terminal device 100b at this time also needs to have a business rollback function to support the insurance service personnel's modification or cancellation operations.
  • this application provides a distributed transaction processing method. Specifically, this method adds a historical version table that is isomorphic to the data table structure of the target data entity in the database design to record the data operations before and after the target data entity is added, deleted, changed (or modified), etc. Version information and content before and after operations, etc.
  • the historical version table can be isomorphic with the data table structure of the target data entity by adding fields such as version number and version type to the basic data table structure corresponding to the target data entity, which is not limited here.
  • the server 200 when the server 200 detects that a rollback operation occurs in the business system running on the terminal device 100a or 100b, or the business system performs a rollback operation on the called data entity.
  • the server 200 can quickly obtain the historical version data content of the data entity before the data operation was performed based on the version number and other related information recorded in the historical version table to implement rollback.
  • the server 200 can also quickly restore the operated data version when the user performs a forward operation again on the business system running on the terminal device 100a or 100b.
  • the solution of this application can support the rapid rollback operation of distributed transactions on the distributed business system, and can quickly restore the recorded historical operation data when the user performs forward operations again on the corresponding business system.
  • the distributed transaction processing method can realize the data entity versions before and after performing corresponding data operations on the application layer by adding an isomorphic historical version table to the data table structure of the target data entity in the server database.
  • Information and data contents are recorded, and the application layer may be, for example, a Java program layer running in the server 200 that communicates and interacts with the terminal device, and is not limited here.
  • the server 200 can apply the historical version table, which records the data entity version information and data content before and after the execution of the corresponding operation, to the data rollback capability of the distributed transaction.
  • the above historical version table can be adaptively designed for various distributed business systems connected to the application layer.
  • the data table structure corresponding to the data entity of the corresponding distributed business system can be designed isomorphically to facilitate reading during subsequent calls. information in the table.
  • the implementation process of the distributed transaction processing method provided by the embodiments of the present application has nothing to do with the type of database underlying the server 200 system. It can support various types of databases and has greater scene adaptability. Good, and will not cause additional performance loss to the server.
  • the distributed transaction processing method is applicable to devices including but not limited to the above-mentioned server 200, as well as mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, and augmented reality ( Augmented Reality (AR) ⁇ Virtual Reality (VR) equipment, smart TVs, smart watches and other wearable devices, mobile email devices, car equipment, portable game consoles, portable music players, reader devices, embedded in them Or a television coupled to one or more processors, or other device capable of accessing the network.
  • Augmented Reality (AR) ⁇ Virtual Reality (VR) equipment Augmented Reality (AR) ⁇ Virtual Reality (VR) equipment
  • smart TVs smart watches and other wearable devices
  • mobile email devices car equipment
  • portable game consoles portable music players
  • reader devices embedded in them
  • embedded in them or a television coupled to one or more processors, or other device capable of accessing the network.
  • Figure 2 shows a schematic flowchart of the implementation of a distributed transaction processing method according to an embodiment of the present application. It can be understood that the execution subject of each step shown in FIG. 2 may be the server 200 in the scenario shown in FIG. 1 . Specifically, the implementation process may include the following steps:
  • a set of historical version tables can be added to the structure of the database during the database design phase.
  • the table structure of the added historical version table can be the same as the table structure of the target data entity in the database, that is, "isomorphism" as mentioned above.
  • the database interface can also be called to add an isomorphic historical version table corresponding to each data entity in the database, and then initialize the original version in the corresponding database through data migration.
  • the data items recorded in the historical version table may include the primary key of the target data entity table, version information before and after modification, and content before and after modification. Based on the content before and after modification, the operation type (new addition, deletion, change) can be identified.
  • the "primary key” in the historical version table can be the primary key of each data table corresponding to the data entity, for example, it can be an identification string such as ID.
  • "Field 1" and “Field 2" in the historical version table can be business fields recorded in each data table of the corresponding data entity. For example, “Field 1" can record name, address, insurance amount, etc., and “Field 2" can Record version type, modification type, etc.
  • the "start version” in the historical version table can be the version number corresponding to the data content before a certain data operation on the target data entity, and the "end version” can be the version number of the data content generated after the data operation.
  • the starting version "1" is the data content version number before a certain data operation
  • the end version "2" is the data content version number generated after a certain data operation.
  • the primary key, field 1, starting version, and end corresponding to the data entity after the operation can be recorded in another row of the historical version table, such as the second row of records shown in Table 1 above.
  • the starting version of the second row of records is "2".
  • the version number of the "end version” in the historical version table shown in Table 1 above may be a null value, such as "NULL” shown in Table 1 above.
  • Figure 3 shows a historical version representation of the addition of some data entities in the policy database according to an embodiment of the present application.
  • the original table structure of some data entities in the corresponding database can refer to the "Policy” table and the "Address” table, for example.
  • the primary key of the "Policy” table is ID
  • the recorded field is the specific amount of "insured amount”.
  • the initial version with ID 100 is “1” and the corresponding "insured amount” data is 1,000.
  • the primary key of the "Address” table is also ID, and the recorded field is the specific content of the "address”.
  • the "address" data with ID 101 is "SH”
  • the "address” data with ID 102 is "BJ”.
  • the isomorphic historical version table created can refer to the "Policy Log” table and "Address Log” table shown in Figure 3.
  • the "Policy Log” table adds a version number field (such as the starting version shown in Figure 3) and a "version type” field compared to the above-mentioned “Policy” table.
  • the "type” field in the "Policy Log” table is, for example, “Field 1" in the above-mentioned Table 1
  • the "version type” field is, for example, “Field 2" in the above-mentioned Table 1, and is not limited here.
  • the "Address Log” table also adds a "starting version” field and a "version type” field.
  • isomorphic historical version table can completely store the change history of the data, and facilitate subsequent steps to read and write through SQL when calling the recorded historical version.
  • the specific role of the version number field added in the above historical version table in the rollback transaction process initiated by subsequent rollback operations will be described in detail in step 203 below, and will not be described again here.
  • the server 200 adds annotations to the data entities that need to be recorded in the historical version table to support recording the modification process to the content of the target data entity, that is, to support modification records.
  • the engine responsible for database storage parses that there is this annotation in the code, it can record the change history in the historical version table when the data table of the target data entity is updated.
  • the process of adding annotations to the Java class of the target data entity through @Audit can be as follows:
  • the historical version data recorded through the @Audit annotation is isomorphic to the data table of the data entity.
  • the historical version table "Policy Log” shown in Figure 3 is isomorphic to the data table "Policy”, so the parameter list annotated through @Audit is isomorphic. It can include "ID”, "operation type” and some business fields, such as "insured amount”, etc. In addition to ID and type (Type), there can also be other business fields, but they do not include program parameters and user information when calling.
  • the server 200 can initialize the data content of the target data entity in the created historical version table and record the corresponding starting version number.
  • Hibernate Envers is usually 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 usually used to annotate Java classes that call entity classes or properties to support data modification recording.
  • the Hibernate Envers tool can be used to assist in recording the version number information of each data entity in the database, and store the data changes caused by the corresponding data operations into a corresponding set of isomorphic historical version tables.
  • a forward operation request for the data entity is detected, the data content of the target data entity is recorded in the historical version table, and the version information before and after the operation is written.
  • the server 200 may receive a data entity call initiated by the business system running on the terminal device and an operation request generated corresponding to operations such as addition, deletion, and modification performed on the called data entity, that is, the above-mentioned forward operation request. , the server 200 can respond to the forward operation request and record the data content and version information before and after the target data entity in the database is operated based on the operation content in the corresponding historical version table.
  • the forward operation request may be, for example, a distributed transaction operation in a binary log (bin log) event written to a relational database management system (MYSQL) or an update log (update log) event.
  • bin log can store all actions that modify table data in the database, including all statements that update data or potentially update data.
  • the update log (update log) can provide query information, but only provides queries for modifying database content.
  • the –log-update server option can be used to enable the update log.
  • MySQL will create a file named: HOSTNAME.nnn in the data directory. Based on the bin log data obtained through bin log event analysis, the specific type of the received operation request can be analyzed, such as whether it is the addition, deletion, change, etc. of the initial data content of the target data entity.
  • the business system calls forward operations performed by data entities, including the addition, deletion, and change operations involved in the initial operation (Try) and confirmation operation (Confirm) of the TCC model.
  • the forward operations performed by the business system when calling data entities are operations such as adding, deleting, and changing in this mode. There are no restrictions here.
  • the type "New” will be recorded under the "Version Type” field of the first row of records in the historical version table "Policy Log”, and the data entity related data after the new data will be written in the second row of records.
  • Information including writing the version number "2" in the "Starting Version” field in the second row of records, and the "Insured Amount” as "1500".
  • the historical version table created based on this application may also include an "end version” field. When updating the version number under the "start version” field, the end version number may also be recorded to indicate the data entity.
  • the basis of the modified data content is not limited here.
  • a rollback operation request for the target data entity is detected, the historical version information in the historical version table is obtained, and the data content of the corresponding historical version is updated back.
  • the server 200 may receive an operation request from the terminal device to roll back the data content of one or more data entities, and in response to the request, use a preset query statement to query the corresponding historical version table. , you can obtain the version number information of the target data entity recorded in the historical version table, for example, obtain the version number of the "starting version" recorded in the corresponding historical version table, etc. Furthermore, 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, restore the data content with the initial version "1" to the target data entity, and then the business system can display the data content after the business rollback.
  • the corresponding page for example, the updated initial version data content can be displayed on this page, etc., there is no restriction here.
  • the business system may, for example, generate the above-mentioned rollback operation request sent to the server 200 based on the rollback operation performed by the user on the business system interface.
  • "XXX_LOG” is the name of the historical version table of the target data entity, for example, it can be the "Policy Log” table or the "Address Log” table shown in Figure 3 above.
  • the "insured amount” data on the business system interface can be quickly updated back to the starting version number "1" in the "Policy Log".
  • the insured amount is "1000".
  • the server 200 can perform this step 204 to quickly obtain the initial version data entity corresponding to the rollback according to the version number and other information recorded in the historical version table corresponding to the target data entity. , update the data content back to the initial version in response to the rollback operation request of the business system.
  • the distributed transaction processing method provided by the embodiment of the present application is an improvement implemented in the server 200 connected to each terminal device, it can be applied to rollback operations of distributed business systems of various complexity levels, that is, It is said that for various distributed business systems, the same set of data rollback logic corresponding to the process shown in Figure 2 above can be used, which greatly simplifies the development and maintenance workload of related business systems to a certain extent. This will not be discussed here. Make restrictions.
  • FIG. 4 shows a schematic block diagram of the software structure of a server 200 according to an embodiment of the present application.
  • the server 200 may include: a business process processing module 201 , a policy data management module 202 , a distributed transaction manager 203 and a database 204 .
  • the business process processing module 201 is used to respond to calls from the business system running on the terminal device to the data entities in the database 204, and to receive operations such as forward operation requests or rollback operations initiated from the business system running on the terminal device. ask.
  • the business process processing module 201 may send the received operation request to the policy data management module 202 for corresponding processing.
  • the business process processing module 201 determines that the next operation to be performed needs to involve multiple different data sources/or requires multiple remote calls and data updates, it can also be responsible for requesting the distributed transaction manager 203 to start a global transaction. .
  • the policy data management module 202 is used to call and manage policy data entities in the database 204, including creating a corresponding historical version table for the policy data entity according to the data table structure of the corresponding policy data entity in the database 204, for recording the policy Version information before and after data addition, deletion, change and other operations can also be used to record the data content changed due to the aforementioned data operations.
  • the server 200 may also include a non-policy data management module 202 for managing non-policy data in the database 204, etc., which is not limited here.
  • the historical version table created by the policy data management module 202 can be synchronized to the distributed transaction manager 203 to record the data operations detected by the distributed transaction manager 203.
  • For the specific creation process please refer to the relevant description in step 201 above, and will not be described in detail here.
  • the policy data management module 202 is also used to respond to data operation requests forwarded by the business process processing module 201, such as operation requests to perform forward operations such as adding, deleting, and changing the requested target data entity, and calling the requested data in the database 204.
  • Target data entity and perform corresponding operations on the data entity.
  • the policy data management module 202 can also record the data entity version information before and after the corresponding operation according to the created historical version table, as well as the specific data content before and after the data entity is operated, etc. And, according to the version information recorded in the historical version table of the target data entity during the forward operation, the data content corresponding to the initial version is read and restored to the target data entity, etc.
  • the distributed transaction manager 203 is used to process information related to opened global transactions and registered branch transactions, and is responsible for coordinating and scheduling between the business process processing module 201 and the policy data management module 202, for example, according to the business process processing module 201
  • the policy data management module 202 coordinates the notification to submit the branch transaction, and coordinates the notification to the policy according to the notification sent by the business process processing module 201 to roll back the global transaction.
  • the data management module 202 rolls back branch transactions and so on.
  • Database 204 is used to store and manage a large number of data entities.
  • Each data entity can be created in the database 204 corresponding to the data calling requirements of the distributed business system. For example, for the insurance business system, it can correspond to the insured amount and address data in the policy.
  • the created data table structure is as shown in Figure 3 above. data entity. It can be understood that the data table structures corresponding to each data entity may be the same or different.
  • FIG. 5 shows a schematic diagram of the interaction flow between some structures in the server 200 during the implementation of a distributed transaction processing method according to an embodiment of the present application. As shown in Figure 5, the interaction process includes the following steps:
  • the policy data management module 202 creates a isomorphic historical version table for the data entity.
  • isomorphism means that the created historical version table has the same or similar structure as the data table of the target data entity.
  • the policy data management module 202 adds annotations that support modification records to the policy data entities that need to be recorded in the historical version table, and initializes the historical version table information.
  • the process of adding annotations supporting modification records to the policy data entity and the process of initializing the historical version table can be referred to the relevant descriptions in step 202 above, and will not be described in detail here.
  • the business process processing module 201 requests the distributed transaction manager 203 to start a global transaction.
  • the program code executed by the business process processing module 201 can determine whether the operations that need to be performed next need to involve multiple different data sources/or require multiple remote calls and data updates. If so, then Request the distributed transaction manager 203 to start a global transaction.
  • the business process processing module 201 receives forward operation requests such as addition, deletion, and change from the distributed business system.
  • the forward operation refers to the above-mentioned addition, deletion, change and other operations performed on the target data entity of the initial version.
  • the relevant description in step 203 above please refer to the relevant description in step 203 above, which will not be described again here.
  • forward operation requests such as addition, deletion, and change sent by the distributed business system can be distributed transaction operation requests written in the bin log event or update log event of MYSQL.
  • the business process processing module 201 can parse the received bin log event to obtain bin log data, or parse the received update log event to obtain update log data, and then identify additions, deletions, and Or forward operation requests such as changes.
  • the business process processing module 201 sends the received forward operation request to the policy data management module 202.
  • the business process processing module 201 can call the application programming interface (Application Programming Interface, API) of the policy data management module 202.
  • the API interface is, for example, a network API interface based on a Restful interface, which can send the received forward operation request and the complete policy data of the requested operation to the policy data management module 202, which is responsible for executing the operation. Request and perform an update operation on the target data entity in the database.
  • the policy data management module 202 performs operations such as adding, deleting, and changing the target data entity.
  • the policy data management module 202 may respond to the received forward operation request by calling the database interface to perform corresponding operations such as adding, deleting, changing, etc. on the data content of the target data entity.
  • the policy data management module 202 can process the target data when processing requests such as adding, deleting, changing, etc.
  • the data mirror (i.e., copy) of the entity before and after the corresponding operation update is organized into a rollback log (undo log), and the ACID characteristics of local transactions are used to write business data updates and rollback logs in the same local transaction. Submit in, this ensures that any submitted business data updates will have corresponding rollback logs.
  • the historical version table is created, only the version number needs to be stored as index information in the undo log, and the complete change content does not need to be stored.
  • the undo log can read the data content of the corresponding version according to the version information provided by the historical version table. In this way, the data operation and processing efficiency of the policy data management module 202 can be improved.
  • step 509 if the business process processing module 201 determines to submit the global transaction, and then the policy data management module 202 notifies the submission of the branch transaction based on the branch transaction processor 203, and when the submission of the branch transaction is completed, synchronization and coordination processing is not required. Only the rollback log needs to be cleaned asynchronously, so that the commit can be completed quickly.
  • Hibernate Interceptor i.e., interceptor
  • Hibernate Interceptor can also be used to intercept all database update operations, such as intercepting modifications, deletions, and other operations to target data entities. Hibernate will save the data before and after changes to the data entities in memory.
  • the interceptor can read the data content before and after these changes and write them into the local undo log table to implement data mirroring in the undo log. There are no restrictions here. In this way, the operation of reading data mirroring before and after changes through SQL can be omitted, and the operation performance can also be improved.
  • the policy data management module 202 records the version information before and after the operation, operation type, content, etc. in the corresponding historical version table.
  • the process of recording version information in the historical version table please refer to the relevant description in step 203 above, and will not be described in detail here.
  • the business process processing module 201 can also send the parsed bin log data or update log data to the distributed transaction manager 203 when executing the above step 503.
  • the distributed transaction manager 203 can update the corresponding version data content and corresponding version information of the target data entity in the obtained historical version table based on the received bin log data or update log data.
  • the policy data management module 202 registers the branch transaction with the distributed transaction manager 203.
  • the policy data management module 202 may trigger the registration of branch transactions with the distributed transaction manager 203 after completing the above step 507 to record relevant fields and version information in the historical version table. It can be understood that the policy data management module 202 can temporarily store some call information in the distributed transaction manager 203 by registering branch transactions, so that when the global transaction is committed or rolled back, the distributed transaction manager 203 can based on these temporary storage The call information is called back.
  • the business process processing module 201 confirms that there is no exception in the global transaction, and sends a request to submit the global transaction to the distributed transaction manager 203.
  • the business process processing module 201 can capture exceptions reported by each interface or agent node during global transaction processing, such as database writing failure, network exception, etc. If there is no exception, the business process processing module 201 can call the confirmation (commit) interface of the distributed transaction manager 203 to request submission of the global transaction.
  • exceptions reported by each interface or agent node during global transaction processing such as database writing failure, network exception, etc. If there is no exception, the business process processing module 201 can call the confirmation (commit) interface of the distributed transaction manager 203 to request submission of the global transaction.
  • the distributed transaction manager 203 notifies the policy data management module 202 to submit the branch transaction.
  • the distributed transaction manager 203 may submit a branch transaction to the policy data management module 202 to notify the policy data management module 202 to confirm (commit).
  • the policy data management module 202 can delete local undo log records based on the commit notification.
  • the policy data management module 202 can Based on the notification of the branch transaction processor 203 to submit the branch transaction, the submission of the branch transaction is completed. At the same time, no synchronous coordination is required. Only the rollback log needs to be cleaned asynchronously, and the process of submitting the branch transaction can be quickly completed.
  • the distributed transaction manager 203 can obtain the active transaction list at the current moment.
  • the active transaction list is used to mark the completion of the data table import and export operations of each data entity in the current database. It can be understood that the purpose of performing the import and export operations on the data table of the target data entity is to add, delete, and add the corresponding data table. Change operations.
  • the distributed transaction manager 203 when the distributed transaction manager 203 exports the target data entity from the database to perform operations such as adding, deleting, and changing, it can generate a data consistency compensation statement based on the active transaction list and the log of the corresponding database, and instruct the corresponding database to execute the statement to ensure that the data content of the target data entity imported and exported from the database remains consistent during operations such as adding, deleting, and changing the target data entity.
  • the log of the database may be, for example, the log data obtained by parsing the bin log event or update log event by the business process processing module 201 in step 503 above.
  • the distributed transaction manager 203 can also use other methods to ensure that the data content of the operated data entities is consistent when importing and exporting from the corresponding database, which is not limited here.
  • the business process processing module 201 confirms that there is an exception in the global transaction, and sends a request to roll back the global transaction to the distributed transaction manager 203.
  • the business process processing module 201 when the business process processing module 201 receives a rollback operation request from the distributed business system, or captures abnormal data such as database writing failure, network abnormality, etc., it can confirm that there is an abnormality in the global transaction. At this time, it can The rollback interface of the distributed transaction manager 203 is called to request the rollback of the global transaction.
  • the rollback can be coordinated through the distributed transaction manager.
  • the distributed transaction manager 203 can perform the following step 512 to notify the policy data management module 202 to roll back the branch transaction. .
  • the business process processing module 201 may also receive a rollback operation request from the distributed business system in response to a user operation, thereby generating a request to roll back the global transaction to achieve rapid rollback of business data. There are no restrictions here.
  • the rollback operation request sent by the distributed business system can be, for example, a distributed transaction operation request recorded in the bin log event of MYSQL.
  • the business process processing module 201 can parse the received bin log event to obtain bin log data, such as a rollback operation request. Furthermore, the business process processing module 201 can identify the above-mentioned rollback operation request based on the bin log data obtained by parsing.
  • the distributed transaction manager 203 notifies the policy data management module 202 to roll back the branch transaction.
  • the distributed transaction manager 203 may notify the policy data management module 202 to roll back the branch transaction, so as to notify the policy data management module 202 to roll back. Based on the rollback notification, the policy data management module 202 can perform data recovery operations according to the version information recorded in the historical version table.
  • the policy 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.
  • the historical version information may be, for example, the starting version number.
  • the policy data management module 202 can find the corresponding rollback log record through the global transaction id (ie, XID) and the branch transaction id (ie, Branch ID), and According to the historical version information in the rollback log record, the corresponding data content in the historical version table is read, and then the reverse update SQL is generated and executed to complete the rollback of the branch transaction.
  • the distributed transaction processing solution based on the historical version table can enable the policy data management module 202 to implement quick operations and rollback functions based on historical versions, and there is no need to read and store data before and after changes. Content, you only need to read or record the historical version ID corresponding to the corresponding policy data (that is, the target data entity).
  • the interface display content of the corresponding distributed business system will also be updated back to the data content of the corresponding historical version.
  • the relevant description in step 204 above please refer to the relevant description in step 204 above, which is not limited here.
  • Figure 6 shows a schematic diagram of the hardware structure of a server 200 according to an embodiment of the present application.
  • server 200 may include one or more processors 604 , system control logic 608 coupled to at least one of the processors 604 , and system memory coupled to the system control logic 608 612, a non-volatile memory (NVM) 616 connected to the system control logic 608, and a network interface 620 connected to the system control logic 608.
  • processors 604 may include one or more processors 604 , system control logic 608 coupled to at least one of the processors 604 , and system memory coupled to the system control logic 608 612, a non-volatile memory (NVM) 616 connected to the system control logic 608, and a network interface 620 connected to the system control logic 608.
  • NVM non-volatile memory
  • processor 604 may include one or more single-core or multi-core processors. In some embodiments, processor 604 may include any combination of general-purpose processors and special-purpose processors (eg, graphics processors, applications processors, baseband processors, etc.). In an embodiment in which the server 200 adopts an eNB (Evolved Node B, enhanced base station) 101 or a RAN (Radio Access Network, radio access network) controller 102, the processor 604 can be configured to execute various conforming embodiments, For example, one or more of the embodiments shown in Figures 2 to 5.
  • eNB evolved Node B, enhanced base station
  • RAN Radio Access Network
  • system control logic 608 may include any suitable interface controller to provide any suitable interface to at least one of processors 604 and/or any suitable device or component in communication with system control logic 608 .
  • system control logic 608 may include one or more memory controllers to provide an interface to system memory 612 .
  • System memory 612 may be used to load and store data and/or instructions.
  • Memory 612 of server 200 may include any suitable volatile memory in some embodiments, such as suitable dynamic random access memory (DRAM).
  • DRAM dynamic random access memory
  • NVM/memory 616 may include one or more tangible, non-transitory computer-readable media for storing data and/or instructions.
  • NVM/memory 616 may include any suitable non-volatile memory such as flash memory and/or any suitable non-volatile storage device, such as HDD (Hard Disk Drive), CD (Compact Disc) , CD) drive, DVD (Digital Versatile Disc, Digital Versatile Disc) drive at least one.
  • NVM/storage 616 may comprise a portion of storage resources on the device on which server 200 is installed, or it may be accessed by the device but is not necessarily part of the device. For example, NVM/storage 616 may be accessed over the network via network interface 620.
  • system memory 612 and NVM/storage 616 may include temporary and permanent copies of instructions 624, respectively.
  • Instructions 624 may include instructions that, when executed by at least one of processors 604, cause server 200 to implement the methods illustrated in Figures 3-4.
  • instructions 624, hardware, firmware, and/or software components thereof may Additionally/alternatively located in system control logic 608, network interface 620 and/or processor 604.
  • Network interface 620 may include a transceiver for providing a radio interface for server 200 to communicate with any other suitable devices (such as front-end modules, antennas, etc.) over one or more networks.
  • network interface 620 may be integrated with other components of server 200.
  • network interface 620 may be integrated with at least one of processor 604, system memory 612, NVM/storage 616, and a firmware device (not shown) with instructions that when at least one of processor 604 executes said When instructed, the server 200 implements the above-mentioned methods shown in FIGS. 2 to 5 .
  • Network interface 620 may further include any suitable hardware and/or firmware to provide a multiple-input multiple-output radio interface.
  • network interface 620 may be a network adapter, a wireless network adapter, a telephone modem, and/or a wireless modem.
  • At least one of the processors 604 may be packaged with logic for one or more controllers of the system control logic 608 to form a system in package (SiP). In one embodiment, at least one of the processors 604 may be integrated on the same die with logic for one or more controllers of the system control logic 608 to form a system on a chip (SoC).
  • SiP system in package
  • SoC system on a chip
  • Server 200 may further include input/output (I/O) devices 632.
  • the I/O device 632 may include a user interface that enables a user to interact with the server 200; the peripheral component interface is designed to enable peripheral components to also interact with the server 200.
  • the server 200 further includes a sensor for determining at least one of environmental conditions and location information related to the server 200 .
  • 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 video camera), a flashlight (e.g., LED flash) and keyboard.
  • a display e.g., a liquid crystal display, a touch screen display, etc.
  • a speaker e.g., a speaker
  • a microphone e.g., a microphone
  • one or more cameras e.g., a still image camera and/or video camera
  • a flashlight e.g., LED flash
  • peripheral component interfaces may include, but are not limited to, non-volatile memory ports, audio jacks, and power interfaces.
  • sensors may include, but are not limited to, gyroscope sensors, accelerometers, proximity sensors, ambient light sensors, and positioning units.
  • the positioning unit may also be part of or interact with network interface 620 to communicate with components of the positioning network (eg, Global Positioning System (GPS) satellites).
  • GPS Global Positioning System
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • Such computer programs may be stored on a computer-readable medium such as, but not limited to, any type of disk including floppy disk, optical disk, CD-ROM, magneto-optical disk, read-only memory (ROM), random access memory (RAM) , EPROM, EEPROM, magnetic or optical card, application specific integrated circuit (ASIC), or any type of medium suitable for storing electronic instructions, and each may be coupled to a computer system bus.
  • the computers referred to in the specification may include a single processor or may employ an architecture involving multiple processors for increased computing power.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请涉及软件技术领域，具体涉及一种分布式事务处理方法、系统、设备及可读存储介质。该方法包括：创建并初始化历史版本表，其中历史版本表用于记录目标数据实体的各版本数据内容以及版本信息，初始化后的版本信息包括第一版本信息，第一版本信息对应于目标数据实体的第一版本数据内容；业务流程处理模块将接收到的对目标数据实体的第一类操作请求发送给保单数据管理模块；保单数据管理模块读取历史版本表，记录对第一版本数据内容执行第一类操作得到的第二版本数据内容。本申请基于历史版本表能够提高分布式事务处理效率和业务回退能力，有利于提高用户体验。

Description

分布式事务处理方法、系统、设备及可读存储介质
本申请要求于2022年5月31日提交中国专利局、申请号为202210611120.X、申请名称为“分布式事务处理方法、系统、设备及可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及软件技术领域，具体涉及一种分布式事务处理方法、系统、设备及可读存储介质。
背景技术
分布式事务，是指事务(Transaction)的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。其中，事务是操作数据库中某个数据项的一个程序执行单元(unit)。
常见分布式事务解决方案中，基于XA规范实现的Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata为用户提供了AT、TCC(Try-Confirm-Cancel)、长事务模型(SAGA)和XA四种事务处理模型。其中，AT、XA是用于处理刚性事务的模型，而刚性事务由于同步阻塞，处理效率低，一般不适用于大型网站的分布式场景。TCC、SAGA则是用于处理柔性事务的模型，而柔性事务允许有中间状态，支持对业务层，例如应用程序(Application，APP)的改造，因此在一些大型网站的分布式场景中，TCC、SAGA模型的使用较为广泛。其中的TCC模型可以提供初步操作(Try)、确认操作(Confirm)、取消操作(Cancel)三种业务接口，供主业务调用。因此，TCC把事务运行过程分成Try和Confirm阶段、以及Cancel阶段，Cancel阶段可以实现对Try、Confirm所处理事务的业务回退(rollback)。SAGA则是基于一系列操作的反向补偿操作实现业务回退。以保险业务为例，前述业务回退例如可能对创建的保单进行的修改操作、或者是对已生成保单的撤销操作(即退保)等。
但是，在这种业务回退处理中，目前通常是通过对数据库底层读取相应的结构化查询语言(Structured Query Language，SQL)中数据变更前后的变化来完成回退、或者基于回退代码实现业务回退。这种业务回退的实现，无法应用在业务层(例如应用程序本身)，回退逻辑复杂，实现难度较大，实现相应业务回退功能涉及的开发、维护、改造成本较高。
发明内容
本申请实施例提供了一种分布式事务处理方法、系统、设备及可读存储介质，其中的方法能够记录新增、删除、变更(或称修改)等数据操作前后相应数据实体的版本信息及操作前后的内容，并在检测到业务系统发生回退操作时、或者业务系统上在对所调用的数据实体进行相应数据操作出现异常时，能够根据该历史版本表中记录的版本号等 相关信息，快速获取该数据实体被执行数据操作之前的历史版本数据内容实现回退。提高分布式系统的业务回退能力，因而有利于提高用户体验。
第一方面，本申请实施例提供了一种分布式事务处理方法，方法用于包括业务流程处理模块、保单数据管理模块和分布式事务管理器的系统，该方法包括：
保单数据管理模块创建并初始化历史版本表，其中历史版本表用于记录目标数据实体的各版本数据内容以及版本信息，初始化后的版本信息包括第一版本信息，第一版本信息对应于目标数据实体的第一版本数据内容；
业务流程处理模块请求分布式事务管理器开启全局事务；
业务流程处理模块接收到对目标数据实体的第一类操作请求，并将第一类操作请求发送给保单数据管理模块，其中第一类操作请求用于请求对目标数据实体的第一版本数据内容执行第一类操作，第一类操作包括增加、删除、修改操作中的至少一项；
保单数据管理模块响应于第一类操作请求，读取历史版本表，记录对第一版本数据内容执行第一类操作得到的第二版本数据内容，并向分布式事务管理器注册分支事务，其中分支事务为执行第一类操作的相关事务；
分布式事务管理器根据业务流程处理模块发来的提交全局事务的第一请求，通知保单数据管理模块提交分支事务。
即处理分布式事务的系统中，可以通过系统本身具有管理保单数据相关数据实体的保单数据管理模块来创建历史版本表，便于在创建的过程控制所创建的历史版本表与目标数据实体的数据表结构相同，即实现同构。如此，可以方便该系统在检测到目标数据实体的数据表存储内容更新时，利用所创建的历史版本表及时记录更新前后的数据内容并写入相应的版本信息，以便于后续执行其他业务调用该历史版本表时，能够根据历史版本表中记录的版本信息快速调用到相应版本的数据内容。
系统中的业务流程处理模块可以对接分布式业务系统客户端，用于接收用户在业务系统客户端操作发起的业务操作请求，再根据业务操作请求的请求内容以及请求目标，转发给系统中的相关模块执行，例如将接收到的第一类操作请求转发给保单数据管理模块进行处理。并且，业务流程处理模块所执行的程序代码，可以在确定接下来需要执行的操作需要涉及多个不同的数据源/或者需要通过多次远程调用以及数据更新时，向分布式事务管理器请求开启全局事务。如此，有利于提高系统对业务操作请求的分类处理效率。上述第一类操作请求，即下文实施例中描述的正向操作对应的操作请求，第一类操作即正向操作。上述第一类操作请求，例如可以是投保用户在保险业务客户端操作创建新保单，在客户端界面上填写投保人/受保人个人信息、保额、地址等对应触发的操作请求。
系统中的分布式事务管理器在响应业务流程处理模块转发来的第一类操作请求时，可以调用保单数据管理模块创建的历史版本表，上述第一版本数据内容例如可以是目标数据实体的初始内容，因而分布式事务管理器可以通过历史版本表中的第一版本信息获取目标数据实体的初始内容，并基于所获取的初始内容处理第一类操作请求。可以理解，如果保单数据管理模块创建目标数据实体的历史版本表后，该历史版本表中的记录内容有更新，则保单数据管理模块在响应上述第一类操作请求时，能够通过历史版本表快速获取处理相应业务操作请求所作用的目标数据实体的初始内容，有利于提高分布式事务 管理器的业务处理效率。
在上述第一方面的一种可能的实现中，读取历史版本表，记录对第一版本数据内容执行第一类操作得到的第二版本数据内容，包括：
保单数据管理模块将第二版本数据内容写入历史版本表，并对应于第二版本数据内容向历史版本表中写入第二版本信息；
保单数据管理模块将第一版本信息和第二版本信息写入用于撤销回退的日志。
即保单数据管理模块在处理新增、删除、变更等请求时，可以利用分布式事务中用于撤销回退的日志来读取版本信息，进而根据历史版本表读取相应版本的数据内容。其中用于撤销回退的日志中只需要存储版本号作为索引信息，不需要存储完整的变更内容。如此，可以提高保单数据管理模块的数据操作处理效率。
在上述第一方面的一种可能的实现中，上述方法还包括：
业务流程处理模块获取全局事务中的异常数据、或者接收到的对目标数据实体的第二类操作请求，向分布式事务管理器发送回滚全局事务的第二请求，其中第二请求用于请求回滚全局事务，以将目标数据实体的数据内容由第二版本数据内容更新回第一版本数据内容；
分布式事务管理器根据第二请求，通知保单数据管理模块回滚分支事务；
保单数据管理模块基于回滚分支事务的通知，根据历史版本表中记录的第一版本信息获取第一版本数据内容并恢复为目标数据实体的当前数据内容。
上述第二类操作例如可以是分布式业务系统客户端发起的回退操作请求，业务流程处理模块获取全局事务中的异常数据例如可以是业务系统上在对所调用的数据实体进行相应数据操作出现异常时对应上报的异常数据，例如数据库写入失败、网络异常等等。业务流程处理模块在接收到回退操作请求、或者获取全局事务中的异常数据时，可以向分布式事务管理器发送回滚全局事务的第二请求，即回滚全局事务的请求。该分布式事务管理器则可以响应于该请求，通知保单数据管理模块回滚分支事务。进而，保单数据管理模块可以读取调用更新后的历史版本表，快速获取该数据实体被执行数据操作之前的历史版本数据内容实现回退。如此，可以提高分布式业务系统对回退事务的响应处理效率，有利于提高系统的回退能力。可以理解，该历史版本表中记录的版本信息以及目标数据实体的内容，在前述步骤中分布式事务管理器处理第一类操作请求时完成更新。
在上述第一方面的一种可能的实现中，用于撤销回退的日志包括回滚日志，根据历史版本表中记录的第一版本信息获取第一版本数据内容，包括：
保单数据管理模块获取回滚日志中记录的第一版本信息；
保单数据管理模块根据历史版本表中记录的第一版本信息与第一版本数据内容的对应关系，获取第一版本数据内容。
即保单数据管理模块在处理回退操作请求或者异常回滚事务时，可以利用回滚日志(undo log)读取版本信息，进而根据历史版本表读取相应版本的数据内容。其中undo log中只需要存储版本号作为索引信息，不需要存储完整的变更内容。如此，可以提高保单数据管理模块的数据操作处理效率。
在上述第一方面的一种可能的实现中，历史版本表是基于以下方式创建的：根据目标数据实体对应的第一数据表结构，创建与第一数据表结构相同的历史版本表。
即保单数据管理模块所创建的历史版本表与目标数据实体的数据表结构同构。上述第一数据表结构是目标数据实体对应的任一数据表或者一类数据表的结构。
在上述第一方面的一种可能的实现中，历史版本表的参数列表包括主键、类型、起始版本以及待记录的业务字段，并且，版本信息包括历史版本表的起始版本字段中记录的版本号。
上述主键以及待记录的业务字段对应于历史版本表记录的数据内容，其中主键例如可以是保单数据的ID，待记录的业务字段例如可以是保额、地址等字段。上述历史版本表中的类型例如可以记录前述第一类操作对应的操作类型，例如新增、删除、修改等。上述历史版本表中的起始版本，例如是对应于所记录的数据版本信息按照预设的版本号设置规则写入的一种识别符号。可以理解，每一次数据内容更新时，在历史版本表中记录的起始版本版本号(简称起始版本号)是与更新前后的数据内容一一对应的。也就是说，在历史版本表中，每一个版本的数据内容都对应一个起始版本号。该起始版本号可以在保单数据管理模块响应第一类操作请求执行第一类操作、或者基于分布式事务管理器的回滚分支事务的通知回滚分支事务时，作为获取相应版本数据内容的识别信息，以实现快速获取数据内容。
可以理解，通过历史版本表中记录的起始版本号等版本信息，来获取相应版本的数据内容，可以替代原本分布式事务处理从数据库中调用目标数据实体以及目标数据实体的修改日志等实现的复杂调用过程，因而可以提高获取相应数据内容的效率，进而提高分布式事务的处理效率。
在上述第一方面的一种可能的实现中，历史版本表的参数列表中的各项参数与第一数据表结构中的各项参数存在关联，并且关联通过以下方式创建：保单数据管理模块通过预设的注解工具在第一数据表结构中加入第一注解信息，其中第一注解信息被存储管理引擎解析时，用于根据第一数据表结构中各项参数的变化更新历史版本表中的各项参数。预设的注解工具为Hibernate Envers提供的@Audit，存储管理引擎为Hibernate。
可以理解，保单数据管理模块对于所管理的目标数据实体的内容及结构具有调用优势，因此保单数据管理模块在创建历史版本表后，可以通过Hibernate Envers提供的@Audit这一Java类注解对目标数据实体的数据表结构的Java类上加入注解。如此，负责数据库存储的引擎Hibernate解析到代码中有这个注解后，能够在数据实体的相应数据表内容更新时，同时向历史版本表中记录相应更新前后的数据内容以及版本信息。这种通过历史版本表记录数据实体更新变化的方式，逻辑简单，操作方便，对原本的数据库以及分布式事务处理流程影响程度较小，还能够有利于提高分布式事务处理效率。
在上述第一方面的一种可能的实现中，第一版本信息为历史版本表中的起始版本字段中记录的第一版本号。
即第一版本信息为历史版本表中记录的对应于第一版本数据内容的起始版本号。
在上述第一方面的一种可能的实现中，向保单数据管理模块获取历史版本表，包括：
保单数据管理模块响应于第一类操作请求，读取历史版本表，包括：
保单数据管理模块基于预设的SQL，读取历史版本表，其中预设的SQL中至少包括历史版本表的名称、主键以及起始版本字段中对应记录的版本号。
即保单数据管理模块在响应第一类操作请求时，可以通过简单的SQL语句完成响应 历史版本表以及相应版本数据内容的查询和获取，查询过程执行语句简单高效，并且获取相应数据内容的效率也能够得以提高。
在上述第一方面的一种可能的实现中，第一类操作请求，为写入MYSQL的bin log事件或update log事件中的分布式事务操作请求；并且，业务流程处理模块接收到对目标数据实体的第一类操作请求，并将第一类操作请求转发给保单数据管理模块包括：
业务流程处理模块确定第一类操作请求为写入MYSQL的bin log事件或update log事件中的分布式事务操作请求；
业务流程处理模块解析接收到的bin log事件以获取bin log数据、或者解析接收到的update log事件以获取update log数据；
业务流程处理模块基于bin log数据或者update log数据，识别增加、删除、或者修改操作对应的分布式事务操作请求；
业务流程处理模块将识别到的分布式事务操作请求作为第一类操作请求转发给保单数据管理模块。
可以理解，通过解析MYSQL的bin log事件或update log事件来识别分布式事务操作请求的类型，可以将数据库底层记录的数据变化获取到应用层执行的Java程序中，数据获取方式简单、直接且及时性强，另外，这种获取操作请求数据的方式，还能够避免对支持分布式业务系统的服务器进行代码改造，有利于减少服务器或系统改造对应的开发工作量。
在上述第一方面的一种可能的实现中，第二类操作请求，为写入MYSQL的bin log事件中的分布式事务操作请求；并且，业务流程处理模块接收到对目标数据实体的第二类操作请求，向分布式事务管理器发送回滚全局事务的第二请求，包括：
业务流程处理模块解析接收到的bin log事件以获取bin log数据；
业务流程处理模块基于bin log数据，识别请求将返回的第二版本数据内容更新回第一版本数据内容的回退操作请求；
业务流程处理模块基于识别到的回退操作请求，向分布式事务管理器发送回滚全局事务的第二请求。
上述通过解析MYSQL的bin log事件来识别分布式事务的回退操作请求或异常运行数据，来确定是否需要对数据库中的目标数据实体的数据内容执行回退处理，可以将数据库底层记录的数据变化或异常数据获取到应用层执行的Java程序中，数据获取过程简单、直接且及时性强，并且有利于减少服务器或系统改造所对应的开发工作量。
在上述第一方面的一种可能的实现中，第二类操作请求，包括：撤销第一类操作的请求，或者，调用第一版本数据内容再次执行第一类操作的请求。
上述撤销第一类操作的请求，例如是用户通过分布式业务系统的客户端进行回退操作对应发起的分布式事务回滚请求，比如用户在支付保险金额时操作返回之前填写的保单信息页面进行再次确认对应触发客户端发起的回退操作请求等。在另一些实施例中，上述撤销第一类操作的请求，也可以是业务系统客户端异常时对应发起的恢复请求，以请求恢复至初始数据内容。在此不做限制。
可以理解，当另一用户通过另一客户端需要调用数据实体的第一版本数据内容进行相应业务操作时，保单数据管理模块也可以通过历史版本表中记录的第一版本信息，快 速获取第一版本数据内容进行处理。
在上述第一方面的一种可能的实现中，目标数据实体存储在用于分布式事务的数据库中，并且方法包括：
在执行第一类操作的过程中，通过以下方式使得数据库中存储的目标数据实体的数据内容、与保单数据管理模块操作的目标数据实体的实时数据内容一致：分布式事务管理器获取当前时刻的活跃事务列表，其中活跃事务列表用于标记对数据库中各数据实体所执行的第一类操作的执行进度，数据库中各数据实体包括目标数据实体；
分布式事务管理器基于活跃事务列表、以及当前数据库生成的对应于目标数据实体的日志数据，生成一致性补偿语句以及补偿指令并发送给数据库，其中补偿指令用于指示数据库执行一致性补偿语句，将第一类操作的执行进度对应的实时数据内容更新为数据库中目标数据实体的数据内容。
即分布式事务管理器在从数据库中导出目标数据实体执行新增、删除、变更等操作时，可以基于活跃事务列表、以及数据库中记录的对应于目标数据实体的日志生成数据一致性补偿语句，并指令相应数据库执行该语句，更新数据库中目标数据实体的数据内容。如此，可以保障在分布式事务处理过程中，数据库中存储的数据内容与被操作的数据内容及时保持一致，以便在其他分布式系统调用数据库中相应数据内容时，导出的是实时更新的数据内容。而相应操作前的数据内容可以记录在历史版本表中，在后续的分布式事务操作过程中需要回退时，则可以根据相应的版本信息获取对应的数据内容进行处理，无需再从数据库中记录的相应日志来获取历史数据内容。基于此，可以有效提高分布式事务处理的效率以及数据库数据内容更新的及时性。
第二方面，本申请实施例提供了一种系统，系统包括业务流程处理模块、保单数据管理模块、分布式事务管理器，其中，保单数据管理模块，用于创建并初始化历史版本表，其中历史版本表用于记录目标数据实体的各版本数据内容以及版本信息，初始化后的版本信息包括第一版本信息，第一版本信息对应于目标数据实体的第一版本数据内容；以及用于响应于第一类操作请求，读取历史版本表，记录对第一版本数据内容执行第一类操作得到的第二版本数据内容，并向分布式事务管理器注册分支事务，其中分支事务为执行第一类操作的相关事务；
业务流程处理模块，用于接收对目标数据实体的第一类操作请求，并将第一类操作请求发送给保单数据管理模块，其中第一类操作请求用于请求对目标数据实体的第一版本数据内容执行第一类操作，第一类操作包括增加、删除、修改操作中的至少一项；以及用于获取全局事务中的异常数据、或者接收到的对目标数据实体的第二类操作请求，并向分布式事务管理器发送回滚全局事务的第二请求，其中第二请求用于请求回滚全局事务，以将目标数据实体的数据内容由第二版本数据内容更新回第一版本数据内容；
分布式事务管理器，用于接收业务流程处理模块发来的通知开启全局事务，并接收保单数据管理模块注册分支事务的请求，存储分支事务的注册信息；以及用于根据业务流程处理模块发来的提交全局事务的通知，通知保单数据管理模块提交分支事务。
第三方面，本申请实施例提供了一种设备，包括：一个或多个处理器；一个或多个存储器；一个或多个存储器存储有一个或多个程序，当一个或者多个程序被一个或多个处理器执行时，使得设备执行上述第一方面提供的分布式事务处理方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，存储介质上存储有指令，指令在计算机上执行时，使计算机执行上述第一方面提供的分布式事务处理方法。
附图说明
图1所示为本申请实施例提供的一种分布式业务系统的应用场景示意图。
图2所示为本申请实施例提供的一种分布式事务处理方法的实施流程示意图。
图3所示为本申请实施例提供的一种对保单数据库中部分数据实体增加的历史版本表示意图。
图4所示为本申请实施例提供的一种服务器200的软件结构示意框图。
图5所示为本申请实施例提供的一种分布式事务处理方法实施过程中，服务器200中部分结构之间的交互流程示意图。
图6所示为本申请实施例提供的一种服务器200的硬件结构示意图。
具体实施方式
为了便于理解本申请方案，下面先对本申请实施例涉及的部分技术领域的概念进行解释。
(1)数据库，用于存储大量的数据实体。数据库设计则是将数据库中的数据实体及这些数据实体之间的关系,进行规划和结构化的过程。
(2)数据实体，就数据库而言，实体往往指某类数据对象对应个体数据集合。每个数据实体可以采用一种数据表结构记录数据对象对应的个体数据、以及个体数据之间的关联关系。因此，每个数据实体的数据表结构可以包括一个或多个相互关联的数据表，并且各数据表的主键相互关联，例如其中一个数据表的主键可以是另一个数据表的外键等。
(3)数据表，是由表名、表中的字段和表的记录三个部分组成的。设计数据表结构(以下简称表结构)就是定义数据表文件名，确定数据表包含哪些字段，各字段的字段名、字段类型、及宽度，并将这些数据输入到计算机当中。
(4)主键，指的是数据表中一个列或多列的组合，其值能唯一地标识表中的每一行。一个数据表的主键可以与其他表的外键关联，以关联其他数据表中的字段文本等的新增、删除、变更/修改等。
(5)ACID特性，是指数据库管理系统(Database Systems，DBMS)在写入或更新资料的过程中，为保证事务(Transaction)是正确可靠的，所必须具备的四个特性：原子性(Atomicity，或称不可分割性)、一致性(Consistency)、隔离性(Isolation，又称独立性)、以及持久性(Durability)。
图1根据本申请实施例示出了一种分布式业务系统的应用场景示意图。
如图1所示，该场景包括终端设备100a、100b与服务器200之间进行交互。其中，服务器200可以包括多个数据库，以及用于处理分布式事务的事务管理器等，以向各终端设备提供分布式数据服务。
用户或者相应业务系统的平台运营人员可以通过终端设备100a运行业务系统应用程序或者基于web的业务系统应用。作为示例，该业务系统例如可以是保险业务系统，想 要投保的用户可以在终端设备100a运行的保险业务系统上登录系统账号，选择参保项目、填写个人信息、生成保单、支付保费等。用户在终端设备100a进行一系列操作的过程中，相应操作数据会接入服务器200的相应数据库中，如果用户需要对已完成的操作进行修改，例如修改保单中的个人信息等；又或者用户想要在终端设备100a当前显示的页面基础上返回上一页或者上一步进行操作，终端设备100a此时运行的业务系统则会执行相应的业务回退，支持用户的返回或修改操作。
同样地，另一用户或者相应业务系统的平台运营人员也可以通过另一终端设备100b进入该业务系统。例如保险服务人员可以通过终端设备100b登录保险业务系统，查看或者审批保单内容，此时终端设备100b可以从服务器200上的保单数据库中获取相应的保单数据，并显示在终端设备100b的屏幕上。另外，保险服务人员也可以应用户要求对已生成的保单进行修改或撤销操作，终端设备100b此时运行的业务系统也需要具有业务回退功能，支持保险服务人员的修改或撤销操作。
在目前的分布式事务解决方案中，无论是通过对数据库底层读取相应的SQL语句中数据变更前后的变化来实现的业务回退能力、还是基于回退代码实现的业务回退能力，实现逻辑都比较复杂，而且需要对分布式业务系统进行较大的改造，相应的开发、维护成本较大。
为了解决上述技术问题，本申请提供了一种分布式事务处理方法。具体地，该方法通过在数据库设计中增加与目标数据实体的数据表结构同构的历史版本表，以用于记录目标数据实体经新增、删除、变更(或称修改)等数据操作前后的版本信息及操作前后的内容等。其中，该历史版本表例如可以通过在目标数据实体对应的基础数据表结构上增加版本号、版本类型等字段，实现与目标数据实体的数据表结构同构，在此不做限制。
如此，在上述图1所示的服务器与终端设备交互的场景中，当服务器200检测到终端设备100a或100b上运行的业务系统发生回退操作时、或者业务系统上在对所调用的数据实体进行相应数据操作出现异常时，服务器200能够根据该历史版本表中记录的版本号等相关信息，快速获取该数据实体被执行数据操作之前的历史版本数据内容实现回退。另外，基于该历史版本表，服务器200还能够响应用户在终端设备100a或100b运行的业务系统上再次执行正向操作时，快速恢复被操作后的数据版本。也就是说，本申请方案能够支持分布式业务系统上分布式事务的快速回退操作、并能够在用户相应业务系统上再次执行正向操作时，快速恢复已记录的历史操作数据。
可以理解，本申请所提供的分布式事务处理方法，通过在服务器的数据库中目标数据实体的数据表结构中添加同构的历史版本表，能够实现对应用层执行相应数据操作前后的数据实体版本信息及数据内容等进行记录，其中该应用层例如可以是服务器200中运行的与终端设备通信交互的Java程序层，在此不做限制。进而，服务器200能够将记录有相应操作执行前后的数据实体版本信息以及数据内容等的历史版本表，应用于分布式事务的数据回退能力。
另外，上述历史版本表可以针对应用层对接的各种分布式业务系统进行适应性设计，例如对应于相应分布式业务系统的数据实体的数据表结构进行同构设计，以便于后续调用时读取表中信息。另外，本申请实施例所提供的分布式事务处理方法的实现过程，与服务器200系统底层的数据库的类型无关，能够支持各种类型的数据库，场景适应性较 好，且不会对服务器造成额外的性能损耗。
可以理解，本申请实施例所提供的分布式事务处理方法，所适用的设备包括但不限于上述服务器200，以及手机、平板电脑、桌面型、膝上型、手持计算机、上网本，以及增强现实(Augmented Reality，AR)\虚拟现实(Virtual Reality，VR)设备、智能电视、智能手表等可穿戴设备、移动电子邮件设备、车机设备、便携式游戏机、便携式音乐播放器、阅读器设备、其中嵌入或耦接有一个或多个处理器的电视机、或能够访问网络的其他设备。
下面以图1所示场景中的服务器200为例，结合附图详细介绍本申请实施例提供的分布式事务处理方案的具体实现过程。
基于上述图1所示场景，图2根据本申请实施例示出了一种分布式事务处理方法的实施流程示意图。可以理解，图2所示各步骤的执行主体可以是图1所示场景中的服务器200。具体地，该实施流程可以包括以下步骤：
201：基于数据库中数据实体的表结构，创建同构的历史版本表。
示例性地，在服务器100中创建某分布式业务系统所需的数据库时，可以在数据库设计阶段，在数据库的结构中增设一套历史版本表。其中，所增加的历史版本表的表结构可以与数据库中目标数据实体的表结构相同，即如上所述的“同构”。同样地，对于服务器200上已创建的数据库，也可以调用数据库接口，对该数据库中各数据实体对应添加同构的历史版本表，再通过数据迁移的方式对相应数据库中原本的版本进行初始化。可以理解，历史版本表中记录的数据项可以包括目标数据实体表的主键、修改前后的版本信息以及修改前后的内容，基于修改前后的内容，可以识别操作类型(新增、删除、变更)。
其中，历史版本表的示例形式可以参考下述表1：
表1
如表1所示，历史版本表中的“主键”可以是对应数据实体的各数据表的主键，例如可以是ID等识别字符串。历史版本表中的“字段1”、“字段2”可以是对应数据实体的各数据表中记录的业务字段等，例如“字段1”可以记录姓名、地址、保额等，“字段2”可以记录版本类型、修改类型等。历史版本表中的“起始版本”可以是对目标数据实体某一项数据操作之前的数据内容对应的版本号，“结束版本”则可以是该项数据操作之后生成的数据内容的版本号，例如上述表1所示的第一行记录，起始版本“1”为某项数据操作之前的数据内容版本号，结束版本“2”为某项数据操作之后生成的数据内容版本号。其中，某项数据操作之后，操作后的数据实体对应的主键、字段1、起始版本、结束 版本以及字段2等可以在历史版本表的另一行中记录，例如上述表1所示的第二行记录，此时第二行记录的起始版本为“2”。
可以理解，若目标数据实体未被执行任何数据操作，则上述表1所示意的历史版本表中“结束版本”的版本号可以为空值，例如上述表1所示的“NULL”。
以保险业务对应的数据库为例，图3根据本申请实施例示出了一种对保单数据库中部分数据实体增加的历史版本表示意图。
如图3所示，在相应数据库中部分数据实体原本的表结构例如可以参考“Policy”表和“Address”表。参考图3所示，“Policy”表的主键为ID，记录的字段是“保额”的具体金额，例如ID为100的起始版本为“1”对应的“保额”数据为1000。“Address”表的主键也是ID，记录的字段是“地址”的具体内容，例如ID为101的“地址”数据为“SH”，ID为102的“地址”数据为“BJ”。
继续参考图3所示，基于上述数据实体的表结构，创建的同构的历史版本表可以参考图3所示的“Policy Log”表和“Address Log”表。其中，“Policy Log”表相比于上述“Policy”表增加了版本号字段(例如图3所示的起始版本)和“版本类型”字段。可以理解，“Policy Log”表中的“类型”字段例如是上述表1中的“字段1”、“版本类型”字段例如是上述表1中的“字段2”，在此不做限制。同样地，“Address Log”表相比于上述“Address”，也增加了“起始版本”字段和“版本类型”字段。
可以理解，同构的历史版本表，可以完整存储数据的变更历史，并且便于后续步骤调用所记录的历史版本时通过SQL读写。上述历史版本表中增加的版本号字段在后续执行回退操作等发起的回滚事务过程中所起到的具体作用，将在下述步骤203中详细描述，在此不做赘述。
202：对需要记录到历史版本表中的数据实体，添加支持修改记录的注解、并初始化历史版本表信息。
示例性地，服务器200对需要记录到历史版本表中的数据实体添加注解，以支持记录对目标数据实体的内容的修改过程，即支持修改记录。作为示例，例如可以通过Hibernate Envers工具提供的“@Audit”对目标数据实体的数据结构Java类上加入注解。之后，负责数据库存储的引擎(Hibernate)解析到代码中有这个注解后，可以在目标数据实体的数据表更新时，向历史版本表中记录变更历史。具体通过@Audit对目标数据实体的Java类上加入注解的过程可以参考如下方式：

可以理解，通过@Audit注解记录的历史版本数据和数据实体的数据表同构，比如图3所示历史版本表“Policy Log”与数据表“Policy”同构，因而通过@Audit注解的参数列表可以包括“ID”、“操作类型”以及一些业务字段，例如“保额”等。除了ID，类型(Type)之外还可以有其他各个业务字段，但是不包含调用时的程序参数以及用户信息等。完成注解后，服务器200可以在创建的历史版本表中初始化目标数据实体的数据内容，并记录相应的起始版本号。
可以理解，Hibernate Envers通常是用于审核实体的框架，@Audit为Hibernate Envers工具中使用的注解组件之一，是一种Java注解。@Audit通常用于对调用实体类或属性的Java类进行注解，以支持数据修改记录。在本申请实施例中，Hibernate Envers工具可以用于辅助记录数据库中各数据实体的版本号信息，将数据操作对应引起的数据变化存储到相应的一套同构的历史版本表中。
在另一些实施例中也可以采用其他工具实现对数据实体添加“支持修改记录”的注解，在此不做限制。
203：检测到对数据实体的正向操作请求，在历史版本表中记录目标数据实体的数据内容，并写入操作前后版本信息。
示例性地，服务器200可以接收到终端设备所运行业务系统发起的数据实体调用、以及对所调用的数据实体执行的新增、删除、变更等操作对应生成的操作请求，即上述正向操作请求，服务器200则可以响应于该正向操作请求，基于操作内容对数据库中目标数据实体被操作前后的数据内容以及版本信息等，记录在相应的历史版本表中。
在一些实施例中，该正向操作请求例如可以是写入关系型数据库管理系统(MYSQL)的二进制日志(binary log，简称bin log)事件或更新日志(update log)事件中的分布式事务操作请求。其中，bin log可以存储修改数据库中表数据的所有动作，包含所有更新数据或者潜在的待更新数据的所有语句。在一些实施例中，可以使用–log-bin[＝file_name]选项启动bin log类型，MYSQL写入包含所有更新数据的SQL命令的日志文件。
而更新日志(update log)则可以提供查询信息，但只提供修改数据库内容的查询，在一些实施例中可以使用–log-update服务器选项，开启更新日志。当启用该日志类型后，MySQL将在数据目录下创建一个名称为：HOSTNAME.nnn的文件。基于bin log事件解析得到的bin log数据，能够分析接收到的操作请求的具体类型，例如是否为目标数据实体的初始数据内容的新增、删除、变更等操作。
以处理分布式事务的TCC模型为例，业务系统调用数据实体执行的正向操作，包括TCC模式的初始操作(Try)、确认操作(Confirm)两个阶段涉及的新增、删除、变更操作。以处理分布式事务的SAGA模型为例，业务系统调用数据实体执行的正向操作即为该模式下的新增、删除、变更等操作。在此不做限制。
作为示例，参考上述图3所示，“Policy Log”表中记录了ID(即主键)＝100的“保额”字段，第一行记录的“起始版本”字段下的版本号为“1”，对应在“Policy  Log”表中“起始版本”为“1”对应记录的“保额”字段的金额为“1000”。
如果检测到的正向操作为对“Policy Log”表中“主键”＝100(即ID＝100)的“起始版本”为“1”的数据实体进行数据新增的操作，则参考图3所示，历史版本表“Policy Log”中的第一行记录的“版本类型”字段下会记录“新增”这一类型，并在第二行记录中写入数据新增后的数据实体相关信息，包括将第二行记录中的“起始版本”字段写入版本号“2”，“保额”为“1500”。在另一些实施例中，基于本申请创建的历史版本表中还可以包括“结束版本”字段，在更新“起始版本”字段下的版本号时，也可以记录结束版本号，以指示数据实体修改的数据内容基础，在此不做限制。
类似地，在前述数据新增操作之后，如果还执行了其他类型的数据操作，例如继续执行数据修改操作，参考图3所示“Policy Log”表，此时调用第一行记录的“起始版本”为“1”的数据作为起始数据记录在“Policy Log”表的第三行，并将第三行记录下的“版本类型”字段下写入“修改”类型、“起始版本”字段下写入版本号“3”，并更新回“保额”为“1000”。
当数据修改操作完成，“Policy Log”表的第四行记录中写入完成修改的数据实体相关信息，包括在第四行记录的“版本类型”字段下写入“修改”类型、“起始版本”字段下写入版本号“5”，并写入修改后的“保额”为“2000”。
204：检测到对目标数据实体的回退操作请求，获取历史版本表中的历史版本信息，更新回相应历史版本的数据内容。
示例性地，服务器200可以接收到终端设备发来的针对某个或者某一些数据实体的数据内容进行回退的操作请求，并响应于该请求利用预设的查询语句查询到对应的历史版本表，便可以获取该历史版本表中记录的目标数据实体的版本号信息，例如获取相应历史版本表中记录的“起始版本”的版本号等。进而，服务器200可以基于获取的版本号信息将相应版本的数据内容更新给目标数据实体，例如将起始版本为“1”的数据内容恢复到目标数据实体，进而业务系统可以显示业务回退后的相应页面，例如该页面上可以显示更新回的起始版本数据内容等，在此不做限制。其中，业务系统例如可以基于用户在业务系统界面上进行的回退操作，生成向服务器200发送的上述回退操作请求。在另一些实施例中，也可以是服务器200在检测到全局事务上报的异常数据时，回滚全局事务。作为示例，服务器200如果要查询主键＝101，历史版本为1的数据，例如可以通过如下SQL进行查询：
Select*from XXX_LOG where“主键”＝100“起始版本”<＝1
其中，“XXX_LOG”为目标数据实体的历史版本表名称，例如可以是上述图3所示的“Policy Log”表或者“Address Log”表等。“主键”例如可以是上述图3所示“Policy Log”表或者“Address Log”表中的ID。因此，上述示例的SQL，可以通过“主键”＝101查询到图3所示“Policy Log”表，进而可以获取“Policy Log”中起始版本号为“1”的“保额”字段数据，即“1000”。
也就是说，基于上述示例的SQL查询到的起始版本号“1”，可以实现快速将业务系统界面上的“保额”数据更新回“Policy Log”中起始版本号“1”对应的保额“1000”。
类似地，在保险业务的分布式系统中，如果用户在业务系统界面操作修改已生成保单中的“地址”信息、“受保人”信息、“投保人信息”信息等，业务系统根据用户的操 作生成相应的回退操作请求发送给服务器200，则服务器200则可以执行本步骤204，根据目标数据实体对应的历史版本表中记录的版本号等信息，快速获取对应回退的初始版本数据实体，更新回初始版本数据内容，以响应业务系统的回退操作请求。
可以理解，基于上述图2所示的分布式事务处理方法，通过对应数据实体创建的同构历史版本表来记录数据实体的操作前后内容以及变化，服务器200上用于支持终端设备的业务系统回退功能的程序模块中，只需要在数据访问层增加少量的代码，例如调用历史版本表的SQL相关代码等，就可以实现分布式业务系统的回退能力或者说是修改、撤销等操作对应的数据补偿能力。并且，本申请实施例所提供的分布式事务处理方法，由于是在连接各终端设备的服务器200中实现的改进，因此可以适用于各种复杂程度的分布式业务系统的回退操作，也就是说对于各种分布式业务系统，均可以采用上述图2所示流程对应的同一套数据回退逻辑，因而在一定程度上也大大简化了相关业务系统的开发及维护的工作量，在此不做限制。
图4根据本申请实施例示出了一种服务器200的软件结构示意框图。如图4所示，以保险业务系统对应连接的服务器为例，服务器200可以包括：业务流程处理模块201、保单数据管理模块202、分布式事务管理器203以及数据库204。
其中，业务流程处理模块201，用于响应来自终端设备所运行的业务系统对数据库204中数据实体的调用，以及接收来自终端设备所运行的业务系统发起的正向操作请求或者回退操作等操作请求。业务流程处理模块201可以将接收到的操作请求发送给保单数据管理模块202进行相应的处理。并且，业务流程处理模块201在确定接下来需要执行的操作，需要涉及多个不同的数据源/或者需要通过多次远程调用以及数据更新时，还可以负责请求分布式事务管理器203开启全局事务。
保单数据管理模块202，用于调用及管理数据库204中的保单数据实体，包括根据数据库204中相应的保单数据实体的数据表结构，为保单数据实体创建相应的历史版本表，以用于记录保单数据的新增、删除、变更等操作前后的版本信息等，还可以用于记录前述数据操作导致变化的数据内容等。在另一些实施例中，对于非保单数据，服务器200也可以包括非保单数据管理模块202，用于管理数据库204中的非保单数据等，在此不做限制。保单数据管理模块202创建的历史版本表，可以同步至分布式事务管理器203中，以记录分布式事务管理器203检测到的数据操作。具体创建过程可以参考上述步骤201中相关描述，在此不做赘述。
保单数据管理模块202，还用于响应业务流程处理模块201转发的数据操作请求，例如对请求的目标数据实体执行新增、删除、变更等正向操作的操作请求，调用数据库204中被请求的目标数据实体并对该数据实体执行相应操作，同时保单数据管理模块202还可以根据已创建的历史版本表，记录相应操作前后的数据实体版本信息、以及数据实体被操作前后的具体数据内容等。以及，根据目标数据实体在正向操作过程中被记录在历史版本表中的版本信息，读取起始版本对应的数据内容恢复到目标数据实体等。
分布式事务管理器203，用于处理已开启的全局事务和已注册的分支事务相关信息，负责在业务流程处理模块201与保单数据管理模块202之间进行协调调度，例如根据业务流程处理模块201发来的提交全局事务的通知，协调通知保单数据管理模块202提交分支事务，以及根据业务流程处理模块201发来的回滚全局事务的通知，协调通知保单 数据管理模块202回滚分支事务等。
数据库204，用于存储、管理大量的数据实体。其中各数据实体可以对应于分布式业务系统的数据调用需求在数据库204中创建，例如对于保险业务系统，可以对应于保单中的保额和地址数据，创建数据表结构如上述图3所示的数据实体。可以理解，各数据实体对应的数据表结构可以相同也可以不同。
图5根据本申请实施例示出了一种分布式事务处理方法实施过程中，服务器200中部分结构之间的交互流程示意图。如图5所示，该交互流程包括以下步骤：
501：保单数据管理模块202为数据实体创建同构的历史版本表。其中，同构是指创建的历史版本表与目标数据实体的数据表结构相同或相似。具体创建过程可以参考上述步骤201中相关描述，在此不做赘述。
502：保单数据管理模块202对需要记录到历史版本表中的保单数据实体，添加支持修改记录的注解、并初始化历史版本表信息。其中，对保单数据实体添加支持修改记录的注解的过程、以及初始化历史版本表的过程，可以参考上述步骤202中相关描述，在此不做赘述。
可以理解，保单数据管理模块202创建历史版本表并初始化的过程，可以同步完成，即上述步骤501和502所执行的内容可以在一个步骤中实现，在此不做限制。
503：业务流程处理模块201请求分布式事务管理器203开启全局事务。
示例性地，业务流程处理模块201所执行的程序代码，可以确定接下来需要执行的操作，是否需要涉及多个不同的数据源/或者需要通过多次远程调用以及数据更新，如果是，则会请求分布式事务管理器203开启全局事务。
504：业务流程处理模块201接收到分布式业务系统发来的新增、删除、变更等正向操作请求。其中，正向操作是指对起始版本的目标数据实体执行的上述新增、删除、变更等操作，具体可以参考上述步骤203中相关描述，在此不做赘述。
可以理解，在一些实施例中，分布式业务系统发来的新增、删除、变更等正向操作请求，可以是写入MYSQL的bin log事件或update log事件中的分布式事务操作请求。对此，业务流程处理模块201则可以对接收到bin log事件解析得到bin log数据、或者对接收到的update log事件解析得到update log数据，进而从解析得到的update log数据，识别增加、删除、或者变更等正向操作请求。
505：业务流程处理模块201向保单数据管理模块202发送接收到的正向操作请求。
示例性地，业务流程处理模块201执行上述步骤503中接收到新增、删除、变更等正向操作的操作请求后，可以调用保单数据管理模块202的应用程序编程接口(Application Programming Interface，API)接口，该API接口例如是基于Restful接口的网络API接口，可以将接收到的正向操作请求以及请求操作的完整保单数据发送给送到保单数据管理模块202，由保单数据管理模块202负责执行操作请求，并对数据库中的目标数据实体执行更新操作。
506：保单数据管理模块202执行对目标数据实体的新增、删除、变更等操作。
示例性地，保单数据管理模块202可以响应于接收到的正向操作请求，调用数据库接口对目标数据实体的数据内容执行相应的新增、删除、变更等操作。
其中，保单数据管理模块202在处理把新增、删除、变更等请求时，可以将目标数 据实体在相应操作更新前后的数据镜像(即复制)并组织成回滚日志(undo log)，并利用本地事务的ACID特性，将业务数据的更新和回滚日志的写入在同一个本地事务中提交，这样可以保证任何提交的业务数据更新都会有相应的回滚日志存在。另外，由于创建了历史版本表，因此undo log中只需要存储版本号作为索引信息，不需要存储完整的变更内容。在保单数据管理模块202执行对目标数据实体的数据内容的正向操作或者后续的回退操作时，undo log则可以根据历史版本表提供的版本信息读取相应版本的数据内容。如此，可以提高保单数据管理模块202的数据操作处理效率。
如此，在后续执行步骤509，如果业务流程处理模块201确定提交全局事务，进而保单数据管理模块202基于分支事务处理器203通知提交分支事务，完成提交分支事务提交时，则不需要同步协调处理，只需要异步清理回滚日志，如此可以快速完成提交。
可以理解，在另一些实施例中，也可以使用Hibernate Interceptor(即拦截器)拦截所有数据库更新操作，例如拦截对目标数据实体的修改、删除等操作，Hibernate会在内存中保存数据实体变更前后的数据镜像内容，拦截器(Interceptor)则可以读取这些变更前后的数据内容，写入本地的undo log表中，实现在undo log的数据镜像，在此不做限制。如此，可以省略通过SQL读取变更前后数据镜像的操作，也可实现操作性能上的提升。
507：保单数据管理模块202在相应的历史版本表中记录操作前后的版本信息及操作类型、内容等。具体在历史版本表中记录版本信息等过程，可以参考上述步骤203中相关描述，在此不做赘述。
可以理解，在一些实施例中，业务流程处理模块201在执行上述步骤503时也可以将解析得到的所述bin log数据或update log数据发送给分布式事务管理器203。而分布式事务管理器203则可以基于接收到的bin log数据或update log数据，在获取的历史版本表中更新目标数据实体的相应版本数据内容以及相应版本信息。
508：保单数据管理模块202向分布式事务管理器203注册分支事务。
示例性地，保单数据管理模块202可以在执行完上述步骤507完成历史版本表中相关字段以及版本信息的记录后，可以触发向分布式事务管理器203注册分支事务。可以理解，保单数据管理模块202通过注册分支事务，可以将一些调用信息暂存在分布式事务管理器203中，以在全局事务提交时或者回退时，分布式事务管理器203可以基于这些暂存的调用信息进行回调。
509：业务流程处理模块201确认全局事务无异常，发送提交全局事务的请求给分布式事务管理器203。
示例性地，业务流程处理模块201可以抓取全局事务处理过程中各接口或者代理节点上报的异常，例如数据库写入失败，网络异常等。如果无异常，业务流程处理模块201则可以调用分布式事务管理器203的确认(commit)接口请求提交全局事务。
510：分布式事务管理器203向保单数据管理模块202通知提交分支事务。
示例性地，分布式事务管理器203响应于接收到的提交全局事务的请求，则可以向保单数据管理模块202通过提交分支事务，以通知保单数据管理模块202确认(commit)。保单数据管理模块202基于确认(commit)通知可以删除本地的undo log记录。
可以理解，业务流程处理模块201确定提交全局事务后，保单数据管理模块202可 以基于分支事务处理器203通知提交分支事务，完成提交分支事务提交，同时不需要同步协调处理，只需要异步清理回滚日志，即可以快速完成提交分支事务的过程。
可以理解，在一些实施例中，为实现相应数据库中导入导出目标数据实体的数据内容一致，分布式事务管理器203可以获取当前时刻的活跃事务列表。其中，活跃事务列表用于标记当前数据库中各数据实体的数据表导入导出操作的完成度，可以理解对目标数据实体的数据表执行导入导出操作是为了实现对相应数据表的新增、删除、变更等操作。进而，分布式事务管理器203在从数据库中导出目标数据实体执行新增、删除、变更等操作时，可以基于活跃事务列表、以及相应数据库的日志生成数据一致性补偿语句，指令相应数据库执行该语句，以保障对目标数据实体执行新增、删除、变更等操作的过程中，数据库导入导出的目标数据实体的数据内容保持一致。该数据库的日志例如可以是上述步骤503中业务流程处理模块201解析bin log事件或update log事件得到的日志数据。
在另一些实施例中，分布式事务管理器203也可以采用其他方式保障所操作的数据实体从相应数据库中导入导出时的数据内容一致，在此不做限制。
511：业务流程处理模块201确认全局事务存在异常，发送回滚全局事务的请求给分布式事务管理器203。
示例性地，业务流程处理模块201接收到分布式业务系统发来的回退操作请求，或者抓取到数据库写入失败，网络异常等异常数据时，可以确认全局事务存在异常，此时则可以调用分布式事务管理器203的回滚(rollback)接口请求回滚全局事务。
可以理解，如果业务流程处理模块201确认回滚全局事务，则可以通过分布式事务管理器协调回滚，例如分布式事务管理器203可以执行下述步骤512通知保单数据管理模块202回滚分支事务。
在另一些实施例中，业务流程处理模块201也可能会接收到分布式业务系统响应于用户操作发来的回退操作请求，从而生成回滚全局事务的请求，以实现业务数据快速回退。在此不做限制。
其中，分布式业务系统发来的回退操作请求例如可以是MYSQL的bin log事件中记录的分布式事务操作请求。对此，业务流程处理模块201则可以对接收到的bin log事件进行解析得到bin log数据，例如回退操作请求。进而，业务流程处理模块201可以根据解析得到的bin log数据，识别上述回退操作请求。
512：分布式事务管理器203向保单数据管理模块202通知回滚分支事务。
示例性地，分布式事务管理器203响应于接收到的回滚全局事务的请求，则可以向保单数据管理模块202通知回滚分支事务，以通知保单数据管理模块202回滚(rollback)。保单数据管理模块202基于回滚(rollback)通知可以根据历史版本表中记录的版本信息进行数据恢复操作。
可以理解，基于历史版本表中记录的版本信息进行数据恢复操作的效率更高，更加快速直接。
513：保单数据管理模块202根据变更前的历史版本信息，从数据库中读取对应版本的数据内容并恢复给被调用的目标数据实体。其中，历史版本信息例如可以是起始版本号，具体获取历史版本信息的过程，可以参考上述步骤204中相关描述，在此不做限制。
可以理解，保单数据管理模块202接收分布式事务管理器203发来的回滚通知后，可以通过全局事务id(即XID)和分支事务id(即Branch ID)找到相应的回滚日志记录，并根据回滚日志记录中的历史版本信息，读取历史版本表中对应的数据内容，进而生成反向的更新SQL并执行，以完成分支事务的回滚。
因此可以理解，本申请提供的基于历史版本表的分布式事务处理方案，能够使保单数据管理模块202实现基于历史版本的快捷操作及回退的功能，而且无需再读取以及存储变更前后的数据内容，只需要读取或记录相应保单数据(即目标数据实体)对应的历史版本ID即可实现。
保单数据管理模块202根据历史版本信息完成数据内容恢复到目标数据实体后，相应的分布式业务系统的界面显示内容也会更新回相应历史版本的数据内容。具体可以参考上述步骤204中相关描述，在此不做限制。
图6根据本申请实施例示出了一种服务器200的硬件结构示意图。
如图6所示，在一些实施例中，服务器200可以包括一个或多个处理器604，与处理器604中的至少一在个连接的系统控制逻辑608，与系统控制逻辑608连接的系统内存612，与系统控制逻辑608连接的非易失性存储器(NVM)616，以及与系统控制逻辑608连接的网络接口620。
在一些实施例中，处理器604可以包括一个或多个单核或多核处理器。在一些实施例中，处理器604可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在服务器200采用eNB(Evolved Node B，增强型基站)101或RAN(Radio Access Network，无线接入网)控制器102的实施例中，处理器604可以被配置为执行各种符合的实施例，例如，如图2至图5所示的多个实施例中的一个或多个。
在一些实施例中，系统控制逻辑608可以包括任意合适的接口控制器，以向处理器604中的至少一个和/或与系统控制逻辑608通信的任意合适的设备或组件提供任意合适的接口。
在一些实施例中，系统控制逻辑608可以包括一个或多个存储器控制器，以提供连接到系统内存612的接口。系统内存612可以用于加载以及存储数据和/或指令。在一些实施例中服务器200的内存612可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(DRAM)。
NVM/存储器616可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，NVM/存储器616可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如HDD(Hard Disk Drive，硬盘驱动器)，CD(Compact Disc，光盘)驱动器，DVD(Digital Versatile Disc，数字通用光盘)驱动器中的至少一个。NVM/存储器616可以包括安装服务器200的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口620通过网络访问NVM/存储616。
特别地，系统内存612和NVM/存储器616可以分别包括：指令624的暂时副本和永久副本。指令624可以包括：由处理器604中的至少一个执行时导致服务器200实施如图3-4所示的方法的指令。在一些实施例中，指令624、硬件、固件和/或其软件组件可 另外地/替代地置于系统控制逻辑608，网络接口620和/或处理器604中。
网络接口620可以包括收发器，用于为服务器200提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口620可以集成于服务器200的其他组件。例如，网络接口620可以集成于处理器604的，系统内存612，NVM/存储器616，和具有指令的固件设备(未示出)中的至少一种，当处理器604中的至少一个执行所述指令时，服务器200实现上述图2至图5所示的方法。网络接口620可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口620可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。
在一个实施例中，处理器604中的至少一个可以与用于系统控制逻辑608的一个或多个控制器的逻辑封装在一起，以形成系统封装(SiP)。在一个实施例中，处理器604中的至少一个可以与用于系统控制逻辑608的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(SoC)。
服务器200可以进一步包括：输入/输出(I/O)设备632。I/O设备632可以包括用户界面，使得用户能够与服务器200进行交互；外围组件接口的设计使得外围组件也能够与服务器200交互。在一些实施例中，服务器200还包括传感器，用于确定与服务器200相关的环境条件和位置信息的至少一种。
在一些实施例中，用户界面可包括但不限于显示器(例如，液晶显示器，触摸屏显示器等)，扬声器，麦克风，一个或多个相机(例如，静止图像照相机和/或摄像机)，手电筒(例如，发光二极管闪光灯)和键盘。
在一些实施例中，外围组件接口可以包括但不限于非易失性存储器端口、音频插孔和电源接口。
在一些实施例中，传感器可包括但不限于陀螺仪传感器，加速度计，近程传感器，环境光线传感器和定位单元。定位单元还可以是网络接口620的一部分或与网络接口620交互，以与定位网络的组件(例如，全球定位系统(GPS)卫星)进行通信。
在说明书对“一个实施例”或“实施例”的引用意指结合实施例所描述的具体特征、结构或特性被包括在根据本申请实施例公开的至少一个范例实施方案或技术中。说明书中的各个地方的短语“在一个实施例中”的出现不一定全部指代同一个实施例。
本申请实施例的公开还涉及用于执行文本中的操作装置。该装置可以专门处于所要求的目的而构造或者其可以包括被存储在计算机中的计算机程序选择性地激活或者重新配置的通用计算机。这样的计算机程序可以被存储在计算机可读介质中，诸如，但不限于任何类型的盘，包括软盘、光盘、CD-ROM、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁或光卡、专用集成电路(ASIC)或者适于存储电子指令的任何类型的介质，并且每个可以被耦合到计算机系统总线。此外，说明书中所提到的计算机可以包括单个处理器或者可以是采用针对增加的计算能力的多个处理器涉及的架构。
另外，在本说明书所使用的语言已经主要被选择用于可读性和指导性的目的并且可能未被选择为描绘或限制所公开的主题。因此，本申请实施例公开旨在说明而非限制本文所讨论的概念的范围。

Claims (17)

  1. 一种分布式事务处理方法，其特征在于，所述方法用于包括业务流程处理模块、保单数据管理模块和分布式事务管理器的系统，所述方法包括：
    保单数据管理模块创建并初始化历史版本表，其中所述历史版本表用于记录目标数据实体的各版本数据内容以及版本信息，初始化后的版本信息包括第一版本信息，所述第一版本信息对应于所述目标数据实体的第一版本数据内容；
    业务流程处理模块请求分布式事务管理器开启全局事务；
    业务流程处理模块接收到对所述目标数据实体的第一类操作请求，并将所述第一类操作请求发送给所述保单数据管理模块，其中所述第一类操作请求用于请求对目标数据实体的第一版本数据内容执行第一类操作，所述第一类操作包括增加、删除、修改操作中的至少一项；
    保单数据管理模块响应于所述第一类操作请求，读取所述历史版本表，记录对所述第一版本数据内容执行所述第一类操作得到的第二版本数据内容，并向所述分布式事务管理器注册分支事务，其中所述分支事务为执行所述第一类操作的相关事务；
    分布式事务管理器根据所述业务流程处理模块发来的提交全局事务的第一请求，通知所述保单数据管理模块提交分支事务。
  2. 根据权利要求1所述的方法，其特征在于，所述读取所述历史版本表，记录对所述第一版本数据内容执行所述第一类操作得到的第二版本数据内容，包括：
    保单数据管理模块将所述第二版本数据内容写入所述历史版本表，并对应于所述第二版本数据内容向所述历史版本表中写入第二版本信息；
    保单数据管理模块将所述第一版本信息和所述第二版本信息写入用于撤销回退的日志。
  3. 根据权利要求2所述的方法，其特征在于，所述方法还包括：
    业务流程处理模块获取所述全局事务中的异常数据、或者接收到的对所述目标数据实体的第二类操作请求，向分布式事务管理器发送回滚全局事务的第二请求，其中所述第二请求用于请求回滚全局事务，以将所述目标数据实体的数据内容由第二版本数据内容更新回第一版本数据内容；
    分布式事务管理器根据所述第二请求，通知所述保单数据管理模块回滚分支事务；
    保单数据管理模块基于所述回滚分支事务的通知，根据所述历史版本表中记录的第一版本信息获取所述第一版本数据内容，并恢复为所述目标数据实体的当前数据内容。
  4. 根据权利要求3所述的方法，其特征在于，所述用于撤销回退的日志包括回滚日志，并且所述根据所述历史版本表中记录的第一版本信息获取所述第一版本数据内容，包括：
    保单数据管理模块获取所述回滚日志中记录的第一版本信息；
    保单数据管理模块根据所述历史版本表中记录的所述第一版本信息与所述第一版本 数据内容的对应关系，获取所述第一版本数据内容。
  5. 根据权利要求4所述的方法，其特征在于，所述历史版本表是基于以下方式创建的：
    根据所述目标数据实体对应的第一数据表结构，创建与所述第一数据表结构相同的历史版本表。
  6. 根据权利要求5所述的方法，其特征在于，所述历史版本表的参数列表包括主键、类型、起始版本以及待记录的业务字段，并且，
    所述版本信息包括所述历史版本表的起始版本字段中记录的版本号。
  7. 根据权利要求6所述的方法，其特征在于，所述历史版本表的参数列表中的各项参数与所述第一数据表结构中的各项参数存在关联，并且所述关联通过以下方式创建：
    保单数据管理模块通过预设的注解工具在所述第一数据表结构中加入第一注解信息，其中所述第一注解信息被存储管理引擎解析时，用于根据所述第一数据表结构中各项参数的变化更新所述历史版本表中的各项参数。
  8. 根据权利要求7所述的方法，其特征在于，所述预设的注解工具为Hibernate Envers提供的@Audit，所述存储管理引擎为Hibernate。
  9. 根据权利要求5所述的方法，其特征在于，所述第一版本信息为所述历史版本表中的起始版本字段中记录的第一版本号。
  10. 根据权利要求5所述的方法，其特征在于，所述保单数据管理模块响应于所述第一类操作请求，读取所述历史版本表，包括：
    所述保单数据管理模块基于预设的SQL，读取所述历史版本表，其中所述预设的SQL中至少包括所述历史版本表的名称、主键以及起始版本字段中对应记录的版本号。
  11. 根据权利要求1至10中任一项所述的方法，其特征在于，所述第一类操作请求，为写入MYSQL的bin log事件或update log事件中的分布式事务操作请求；并且，
    所述业务流程处理模块接收到对所述目标数据实体的第一类操作请求，并将所述第一类操作请求转发给所述分布式事务管理器包括：
    所述业务流程处理模块确定所述第一类操作请求为写入MYSQL的bin log事件或update log事件中的分布式事务操作请求；
    业务流程处理模块解析接收到的bin log事件以获取bin log数据、或者解析接收到的update log事件以获取update log数据；
    业务流程处理模块基于所述bin log数据或者所述update log数据，识别增加、删除、或者修改操作对应的分布式事务操作请求；
    业务流程处理模块将识别到的分布式事务操作请求作为所述第一类操作请求转发给所述保单数据管理模块。
  12. 根据权利要求3至10中任一项所述的方法，其特征在于，所述第二类操作请求，为写入MYSQL的bin log事件中的分布式事务操作请求；并且，
    所述业务流程处理模块接收到对所述目标数据实体的第二类操作请求，向分布式事务管理器发送回滚全局事务的第二请求，包括：
    业务流程处理模块解析接收到的bin log事件以获取bin log数据；
    业务流程处理模块基于所述bin log数据，识别请求将返回的第二版本数据内容更新回第一版本数据内容的回退操作请求；
    业务流程处理模块基于识别到的回退操作请求，向所述分布式事务管理器发送回滚全局事务的第二请求。
  13. 根据权利要求10中任一项所述的方法，其特征在于，所述第二类操作请求，包括：
    撤销所述第一类操作的请求，或者，
    调用所述第一版本数据内容再次执行所述第一类操作的请求。
  14. 根据权利要求1所述的方法，其特征在于，所述目标数据实体存储在用于分布式事务的数据库中，并且所述方法包括：
    在执行所述第一类操作的过程中，通过以下方式使得所述数据库中存储的目标数据实体的数据内容、与所述保单数据管理模块操作的目标数据实体的实时数据内容一致：
    分布式事务管理器获取当前时刻的活跃事务列表，其中所述活跃事务列表用于标记对数据库中各数据实体所执行的第一类操作的执行进度，所述数据库中各数据实体包括所述目标数据实体；
    分布式事务管理器基于活跃事务列表、以及当前数据库生成的对应于所述目标数据实体的日志数据，生成一致性补偿语句以及补偿指令并发送给所述数据库，其中所述补偿指令用于指示所述数据库执行所述一致性补偿语句，将所述第一类操作的执行进度对应的实时数据内容更新为所述数据库中目标数据实体的数据内容。
  15. 一种分布式事务处理系统，其特征在于，所述系统包括业务流程处理模块、保单数据管理模块、分布式事务管理器，其中，
    保单数据管理模块，用于创建并初始化历史版本表，其中所述历史版本表用于记录目标数据实体的各版本数据内容以及版本信息，初始化后的版本信息包括第一版本信息，所述第一版本信息对应于所述目标数据实体的第一版本数据内容；以及用于响应于第一类操作请求，读取所述历史版本表，记录对所述第一版本数据内容执行第一类操作得到的第二版本数据内容，并向所述分布式事务管理器注册分支事务，其中所述分支事务为执行所述第一类操作的相关事务；
    业务流程处理模块，用于接收对所述目标数据实体的第一类操作请求，并将所述第一类操作请求发送给保单数据管理模块，其中所述第一类操作请求用于请求对目标数据实体的第一版本数据内容执行第一类操作，所述第一类操作包括增加、删除、修改操作中的至少一项；以及用于获取全局事务中的异常数据、或者接收到的对所述目标数据实 体的第二类操作请求，并向分布式事务管理器发送回滚全局事务的第二请求，其中所述第二请求用于请求回滚全局事务，以将所述目标数据实体的数据内容由所述第二版本数据内容更新回第一版本数据内容；
    分布式事务管理器，用于接收所述业务流程处理模块发来的通知开启全局事务，并接收所述保单数据管理模块注册分支事务的请求，存储所述分支事务的注册信息；以及用于根据所述业务流程处理模块发来的提交全局事务的通知，通知所述保单数据管理模块提交分支事务。
  16. 一种设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当一个或者多个程序被所述一个或多个处理器执行时，使得所述设备执行权利要求1至14中任一项所述的分布式事务处理方法。
  17. 一种计算机可读存储介质，其特征在于，所述存储介质上存储有指令，所述指令在计算机上执行时，使所述计算机执行权利要求1至14中任一项所述的分布式事务处理方法。
PCT/CN2023/091220 2022-05-31 2023-04-27 分布式事务处理方法、系统、设备及可读存储介质 WO2023231665A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210611120.X 2022-05-31
CN202210611120.XA CN114925084B (zh) 2022-05-31 2022-05-31 分布式事务处理方法、系统、设备及可读存储介质

Publications (1)

Publication Number Publication Date
WO2023231665A1 true WO2023231665A1 (zh) 2023-12-07

Family

ID=82811760

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/091220 WO2023231665A1 (zh) 2022-05-31 2023-04-27 分布式事务处理方法、系统、设备及可读存储介质

Country Status (2)

Country Link
CN (1) CN114925084B (zh)
WO (1) WO2023231665A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114925084B (zh) * 2022-05-31 2023-07-21 易保网络技术(上海)有限公司 分布式事务处理方法、系统、设备及可读存储介质
CN115373733B (zh) * 2022-10-26 2023-01-24 小米汽车科技有限公司 模型服务的模型版本调整方法、装置和电子设备
CN116756135B (zh) * 2023-07-11 2024-04-23 星环信息科技(上海)股份有限公司 一种数据清理方法、装置、设备及介质
CN116842031B (zh) * 2023-09-01 2023-12-05 北京车与车科技有限公司 数据更新方法、装置以及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090070330A1 (en) * 2007-09-12 2009-03-12 Sang Yong Hwang Dual access to concurrent data in a database management system
CN104216955A (zh) * 2014-08-20 2014-12-17 百度在线网络技术（北京）有限公司 一种操作数据及管理事务的方法、装置及分布式系统
CN106484906A (zh) * 2016-10-21 2017-03-08 焦点科技股份有限公司 一种分布式对象存储系统闪回方法及装置
CN110765178A (zh) * 2019-10-18 2020-02-07 京东数字科技控股有限公司 分布式事务的处理方法及装置、计算机可存储介质
CN111274226A (zh) * 2020-01-20 2020-06-12 西安百想科技有限公司 一种实现业务通用历史数据管理的系统及其方法
CN114925084A (zh) * 2022-05-31 2022-08-19 易保网络技术(上海)有限公司 分布式事务处理方法、系统、设备及可读存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130226891A1 (en) * 2012-02-29 2013-08-29 Red Hat Inc. Managing versions of transaction data used for multiple transactions in distributed environments
CN103714090B (zh) * 2012-10-09 2018-04-10 阿里巴巴集团控股有限公司 多索引数据库事务处理方法及数据库
CN106033439B (zh) * 2015-03-13 2019-10-22 阿里巴巴集团控股有限公司 一种分布式事务处理方法及系统
CN106033437B (zh) * 2015-03-13 2020-01-10 阿里巴巴集团控股有限公司 一种分布式事务处理方法及系统
CN112559140B (zh) * 2020-12-17 2022-07-26 江苏满运物流信息有限公司 数据一致性的事务控制方法、系统、设备及存储介质
CN113254425B (zh) * 2021-06-24 2022-01-11 阿里云计算有限公司 数据库事务保持的方法、设备、系统、程序及存储介质
CN114003644B (zh) * 2021-10-21 2022-11-15 河南星环众志信息科技有限公司 分布式事务处理方法、设备、介质和数据库系统
CN114327799B (zh) * 2021-12-23 2022-08-05 杭州博盾习言科技有限公司 分布式事务处理方法及装置、电子设备、存储介质
CN114327794A (zh) * 2021-12-24 2022-04-12 中国工商银行股份有限公司 事务管理方法、装置、设备、介质和程序产品

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090070330A1 (en) * 2007-09-12 2009-03-12 Sang Yong Hwang Dual access to concurrent data in a database management system
CN104216955A (zh) * 2014-08-20 2014-12-17 百度在线网络技术（北京）有限公司 一种操作数据及管理事务的方法、装置及分布式系统
CN106484906A (zh) * 2016-10-21 2017-03-08 焦点科技股份有限公司 一种分布式对象存储系统闪回方法及装置
CN110765178A (zh) * 2019-10-18 2020-02-07 京东数字科技控股有限公司 分布式事务的处理方法及装置、计算机可存储介质
CN111274226A (zh) * 2020-01-20 2020-06-12 西安百想科技有限公司 一种实现业务通用历史数据管理的系统及其方法
CN114925084A (zh) * 2022-05-31 2022-08-19 易保网络技术(上海)有限公司 分布式事务处理方法、系统、设备及可读存储介质

Also Published As

Publication number Publication date
CN114925084B (zh) 2023-07-21
CN114925084A (zh) 2022-08-19

Similar Documents

Publication Publication Date Title
WO2023231665A1 (zh) 分布式事务处理方法、系统、设备及可读存储介质
CN109906448B (zh) 用于促进可插拔数据库上的操作的方法、设备和介质
US8346747B2 (en) Extending database tables in a multi-tenant environment
EP2874077B1 (en) Stateless database cache
JP2019533854A (ja) 分散イベント処理システムのためのグラフ生成
US8250590B2 (en) Apparatus, system, and method for seamless multiple format metadata abstraction
WO2017028514A1 (zh) 一种数据存储、读取方法及装置
CN104252501B (zh) 一种执行数据库操作命令的计算设备和方法
US11294973B2 (en) Codeless information service for abstract retrieval of disparate data
US20080249981A1 (en) Systems and methods for federating data
JP2015513153A (ja) マルチテナント環境におけるテナント固有のデータ・セットを管理するための、コンピュータで実施される方法、コンピュータ・プログラム製品、およびシステム
US8819050B2 (en) Context-and-version-aware facade for database queries
US20140379631A1 (en) Transactional key-value database with searchable indexes
US9158555B2 (en) Efficient serialization of mutable objects
US10339040B2 (en) Core data services test double framework automation tool
US9922100B2 (en) Systems and methods for facilitating the development of an application that accesses data
US20200065313A1 (en) Extensible content object metadata
US20200104404A1 (en) Seamless migration of distributed systems
JP2009530738A (ja) サービスシーケンス内の変換のための宣言
US11829814B2 (en) Resolving data location for queries in a multi-system instance landscape
WO2024016850A1 (zh) 处理数据冲突的方法、系统、电子设备及计算机可读存储介质
US10620660B2 (en) Efficient timestamp solution for analyzing concurrent software systems
US10503735B2 (en) Methods and apparatuses for improved database design
CN108140043B (zh) 只附加分布式数据库的读写协议
CN115729951A (zh) 数据查询方法、系统、设备及计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23814851

Country of ref document: EP

Kind code of ref document: A1