Transaction processing method and device, electronic equipment and computer readable medium
By splitting data into database transactions into distributed transactions and using message middleware for confirmation and compensation processing, the problem of difficult data consistency in distributed transactions is solved, and efficient and consistent data processing is achieved.
Patent Information
- Application Number
- CN202410851506.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-27
- Publication Date
- 2024-12-27
AI Technical Summary
In the prior art, data consistency is difficult to ensure when processing distributed transactions, and data inconsistency may be caused by network failure or node failure.
By splitting the data into database transactions into multiple business sub-data, converting them into distributed transactions, and using message middleware for message delivery and compensation processing, ensuring the success and failure processing of each local transaction.
Improve data entry efficiency, and ensure data consistency through secondary confirmation and asynchronous processing, avoiding data inconsistency caused by network or node failure.
Smart Images
Figure CN119201363A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of computer technology, and specifically to a transaction processing method, device, electronic device, and computer-readable medium. Background Art
[0002] Distributed transactions refer to transactions involving multiple independent components or services that are distributed on different computers or network nodes. By executing distributed transactions, data processing efficiency can be greatly improved.
[0003] In the prior art, since various components may perform operations at different times and in different orders during the processing of distributed transactions, network failures, node failures or other problems may occur, making it difficult to ensure data consistency. Summary of the invention
[0004] The embodiments of the present application propose a transaction processing method, device, electronic device and computer-readable medium to solve the technical problem in the prior art that it is difficult to ensure data consistency when processing distributed transactions.
[0005] In a first aspect, an embodiment of the present application provides a transaction processing method, the method comprising: splitting the business data involved in the data warehousing transaction into multiple business sub-data, converting the data warehousing transaction into a distributed transaction, the distributed transaction comprising multiple local transactions, each local transaction being used to warehousing one business sub-data among the multiple business sub-data; starting each local transaction to warehousing the business sub-data corresponding to each local transaction, and obtaining the warehousing result of each business sub-data; based on the warehousing result of each business sub-data, generating a message indicating whether each local transaction is executed successfully, and forwarding the message to a target component via a message middleware; confirming the message indicating the successful execution of the local transaction by the target component, and performing compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
[0006] In the second aspect, an embodiment of the present application provides a transaction processing device, which includes: a conversion unit, which is used to split the business data involved in the data warehousing transaction into multiple business sub-data, and convert the data warehousing transaction into a distributed transaction, wherein the distributed transaction includes multiple local transactions, and each local transaction is used to store one business sub-data of the multiple business sub-data; a warehousing unit, which is used to start each local transaction to store the business sub-data corresponding to each local transaction and obtain the warehousing result of each business sub-data; a forwarding unit, which is used to generate a message indicating whether each local transaction is executed successfully based on the warehousing result of each business sub-data, and forward the message to the target component via the message middleware; a processing unit, which is used to confirm the message indicating the successful execution of the local transaction through the target component, and perform compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
[0007] In a third aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any embodiment of the first aspect.
[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of the first aspect.
[0009] The transaction processing method, device, electronic device and computer-readable medium provided by the embodiment of the present application, by splitting the business data involved in the data warehousing transaction into multiple business sub-data, converting the data warehousing transaction into a distributed transaction, so that each local transaction in the distributed transaction is responsible for warehousing one of the multiple business sub-data; then starting each local transaction to warehousing the business sub-data corresponding to each local transaction, and obtaining the warehousing result of each business sub-data; then based on the warehousing result of each business sub-data, generating a message indicating whether each local transaction is successfully executed, and forwarding each message to the target component via the message middleware; finally, the message indicating the successful execution of the local transaction is confirmed by the target component, and the local transaction corresponding to the message indicating the failure of the local transaction is compensated. In this scheme, on the one hand, since the business data is split into multiple business sub-data and the data warehousing transaction is converted into a distributed transaction, the data warehousing efficiency can be improved. On the other hand, since the message middleware is introduced, the local transaction processing result can be confirmed twice when the local transaction is successfully executed, and the local transaction can be asynchronously processed when the local transaction fails to execute, thereby ensuring the success of each local transaction and ensuring the consistency of the data. In this way, data consistency can be ensured while improving data processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:
[0011] Figure 1 is a flow chart of an embodiment of a transaction processing method according to the present application;
[0012] Figure 2 is a schematic diagram of the business data processing process according to the present application;
[0013] Figure 3 It is a schematic diagram of the transaction compensation processing process and the message confirmation process according to the present application;
[0014] Figure 4 is a schematic diagram of the structure of an embodiment of a transaction processing device according to the present application;
[0015] Figure 5 It is a schematic diagram of the structure of an electronic device used to implement an embodiment of the present application. DETAILED DESCRIPTION
[0016] All actions to obtain signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located, and with the authorization given by the owner of the corresponding device.
[0017] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.
[0018] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0019] Please refer to Figure 1 , which shows a process 100 of an embodiment of a transaction processing method according to the present application. The transaction processing method can be applied to various electronic devices with processing functions, such as servers, server clusters, etc.
[0020] The transaction processing method comprises the following steps:
[0021] Step 101, split the business data involved in the data warehousing transaction into multiple business sub-data, convert the data warehousing transaction into a distributed transaction, the distributed transaction includes multiple local transactions, each local transaction is used to store one business sub-data among the multiple business sub-data.
[0022] In this embodiment, a transaction is a logical group of SQL (Structured Query Language) statements, and also refers to a work unit consisting of a group of operations. This work unit has ACID characteristics, namely, atomicity, consistency, isolation, and durability. The above-mentioned data storage transactions and local transactions all follow the ACID characteristics.
[0023] In this embodiment, a distributed transaction refers to a transaction involving multiple independent components or services, which are distributed on different computers or network nodes. A distributed transaction operation involves multiple components or services being completed in collaboration.
[0024] In this embodiment, the data entry transaction may be a transaction for storing the vehicle management positioning big data into the database. In practice, in the vehicle management production business, the data entry transaction may involve a data volume of nearly 10,000. If it is stored in batches into the database at one time, problems such as large transaction execution timeout may occur. Therefore, the business data involved in the data entry transaction is split into multiple business sub-data, and the data entry transaction is converted into a distributed transaction. The distributed transaction includes multiple local transactions, each of which is used to enter one of the multiple business sub-data into the database.
[0025] As an example, the time required to split the target amount of data into different amounts of sub-data and store them in the database can be simulated in advance to perform performance stress testing. The above target data can be determined based on the data volume of the vehicle management positioning big data storage transaction. See the following table:
[0026] Total data volume Single entry quantity time consuming Is it abnormal? 1W 100 items 0.921 no 1W 500 items 0.623 no 1W 1000 items 0.449 no 1W 5000 0.422s Very rare 1W 10000 0.341s Occasionally
[0027] According to the simulated test data stress test, it can be concluded that it is more reasonable to split the vehicle management positioning big data storage transaction into multiple transactions so that each transaction is used to store 1,000 data, because there is no transaction submission timeout problem at this time, and the overall data storage efficiency is the highest. Therefore, in this example, the data storage transaction for storing 10,000 business data can be converted into a distributed transaction, which includes 10 local transactions, and each local transaction can be responsible for storing 1,000 business sub-data.
[0028] In practice, a custom transaction annotation (recorded as @ItemTransactional) can be created in the data entry interface for processing the above data entry transaction based on the Transactional annotation mode of the Spring architecture, which is used to convert the data entry transaction into a distributed transaction containing multiple local transactions and realize the splitting of business data. Among them, the above Spring architecture is a lightweight Java development framework designed to solve the complexity of enterprise-level application development. It enables developers to focus more on the development of business logic by providing core functions such as Inversion of Control (IoC) and Aspect Oriented Programming (AOP), as well as a series of modular designs, while reducing the coupling between codes and improving the testability and maintainability of the code. Among them, the Transactional annotation is an annotation used to manage transactions in the Spring framework, which allows developers to handle transactions in a declarative manner without explicitly writing transaction management logic in the code. The Transactional annotation can act on interfaces, classes, and class methods.
[0029] Step 102, starting each local transaction to store the business sub-data corresponding to each local transaction into a database, and obtaining the storage result of each business sub-data.
[0030] In this embodiment, each local transaction may be started to store the business sub-data corresponding to each local transaction into the database.
[0031] In some optional implementations of this embodiment, the local transaction is also used to store the local message data, that is, to store the local message data and the business sub-data together. Therefore, step 102 may include:
[0032] The first step is to obtain the local message data corresponding to each local transaction. The local message data includes a main message identifier, a local message identifier and parameter information. The main message identifier is used to indicate the data entry transaction. The local message identifier is used to indicate the local transaction. The parameter information may include specific request parameters of the data entry interface corresponding to the local transaction.
[0033] The second step is to store the business sub-data and local message data corresponding to each local transaction into the database.
[0034] By introducing local message data and storing it together with business sub-data, the purpose of monitoring the storage of business sub-data and making the first confirmation of the storage results can be achieved, thus ensuring the data consistency of local transactions.
[0035] Further, based on the present implementation, if the target component confirms the message indicating successful execution of the local transaction in step 104, the local message data stored in the local transaction can be deleted, thereby asynchronously ensuring that the local message data is deleted, saving server resources.
[0036] Step 103: Based on the storage result of each business sub-data, a message indicating whether each local transaction is successfully executed is generated, and the message is forwarded to the target component via the message middleware.
[0037] In this embodiment, when a database exception or a data entry interface exception occurs, the local transaction may fail to execute. For each local transaction, if the business sub-data corresponding to the local transaction fails to be entered into the database, a failure message indicating that the local transaction failed to execute may be generated. If the business sub-data corresponding to the local transaction is executed successfully, a success message indicating that the local transaction was executed successfully may be generated. The success message and the failure message are forwarded to the target component via the message middleware.
[0038] In this embodiment, the message middleware is a supporting software system based on queue and message passing technology that provides synchronous or asynchronous, reliable message transmission for application systems in a network environment. The message middleware uses an efficient and reliable message passing mechanism to exchange data independently of the platform, and integrates distributed systems based on data communication. By providing message passing and message queuing models, it can expand inter-process communication in a distributed environment. The target component can be a program for consuming messages in the message middleware.
[0039] Step 104: confirm the message indicating the successful execution of the local transaction through the target component, and perform compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
[0040] In this embodiment, if a message indicates that a local transaction has failed, the target component can be used to compensate for the local transaction that failed. It should be noted that the message indicating the failure of a local transaction may include specific request parameters of the data entry interface corresponding to the local transaction, basic information of the data entry interface, main message identifier, local message identifier and other information. By using the target component to compensate for the local transaction that failed, the business sub-data involved in the local transaction that failed can be re-entered into the database, ensuring the successful execution of each local transaction and ensuring data consistency.
[0041] In this embodiment, if a message indicates that the local transaction is successfully processed, the message can be confirmed by the target component. If the local message data is stored together with the business sub-data during the execution of the local transaction, the message indicating the successful execution of the local transaction can be confirmed by the target component, so as to achieve the purpose of secondary confirmation of the execution result of the local transaction. If all messages indicate that the local transaction is successfully executed, it can be determined that the distributed transaction is successfully executed and all business data is successfully stored and consistent, thereby further improving the consistency of the data.
[0042] It should be noted that after the target component performs compensation processing on the failed local transaction and confirms the message indicating the successful execution of the local transaction, the target component can also return the processing result information to the message middleware. If the processing result information indicates that the target component is successfully executed, the message in the message queue can be removed through the confirmation consumption interface provided by the message middleware. If the processing result information indicates that the target component fails to execute, the message confirmation is not performed to ensure the normal processing of transaction compensation.
[0043] The method provided by the above embodiment of the present application is to convert the data entry transaction into a distributed transaction by splitting the business data involved in the data entry transaction into multiple business sub-data, so that each local transaction in the distributed transaction is responsible for entering one business sub-data in the multiple business sub-data into the warehouse; then start each local transaction to enter the business sub-data corresponding to each local transaction into the warehouse, and obtain the entry result of each business sub-data; then based on the entry result of each business sub-data, generate a message indicating whether each local transaction is successfully executed, and forward each message to the target component via the message middleware; finally, the message indicating the successful execution of the local transaction is confirmed by the target component, and the local transaction corresponding to the message indicating the failure of the local transaction is compensated. In this scheme, on the one hand, since the business data is split into multiple business sub-data and the data entry transaction is converted into a distributed transaction, the data entry efficiency can be improved. On the other hand, since the message middleware is introduced, the local transaction processing result can be confirmed twice when the local transaction is successfully executed, and the local transaction can be asynchronously processed when the local transaction fails to execute, thereby ensuring the success of each local transaction and ensuring the consistency of the data. In this way, data consistency can be ensured while improving data processing efficiency.
[0044] In some optional embodiments, the operation of starting each local transaction in step 102 may be performed by the following steps:
[0045] The first step is to call the data entry interface corresponding to each local transaction. Here, the data entry interface is added with a target annotation, which is used to indicate that a pre-operation is performed before the data is entered into the database. The pre-operation includes starting a local transaction.
[0046] The second step is to execute the pre-operations indicated by the target annotation to start each local transaction.
[0047] Furthermore, in some optional embodiments, the target annotation is also used to perform post-operation after the business sub-data is successfully stored in the database, and the post-operation includes: submitting the local transaction, generating a success message indicating that the local transaction is successfully executed when the local transaction is successfully submitted, and sending the success message to the message middleware. On this basis, step 103 may include:
[0048] For each local transaction, if the business sub-data involved in the local transaction is successfully stored in the database, the post-operation indicated by the target annotation is executed to commit the local transaction. When the local transaction is successfully committed, a success message is generated and sent to the message middleware.
[0049] For each local transaction, if the business sub-data involved in the local transaction fails to be stored in the database, a failure message indicating the failure of the local transaction execution is generated and sent to the message middleware.
[0050] In practice, the target annotation can adopt the @Around annotation of the Spring architecture. The @Around annotation can be used to implant enhancement actions before the target method, i.e., pre-operation, or after the target method is executed, i.e., post-operation, so as to determine when and how the target method is executed, or even completely prevent the execution of the target method, change the parameter values of the target method, or change the return value after the target method is executed.
[0051] As an example, the processing logic is shown in the following pseudo code:
[0052] @Around
[0053] public Object pointAround(List <t>data){
[0054] / / Pre-operation starts local transaction
[0055] try{
[0056] / / Business sub-data storage method
[0057] }catch(Throwable e){
[0058] / / Log collection and message forwarding for failed storage
[0059] }
[0060] / / Post-operation forwarding message
[0061] }
[0062] See also Figure 2 , Figure 2 This is a schematic diagram of the business data processing process of this application. Figure 2 As shown, first, by calling the data entry interface with a custom transaction annotation (for example, the above-mentioned @ItemTransactional), the data entry transaction is converted into a distributed transaction containing multiple local transactions, and the business data is split. For each local transaction, the data entry interface with a target annotation (for example, the above-mentioned @Around annotation based on the AOP aspect) for processing the local transaction can be called to perform the pre-operation to start the local transaction. After the local transaction is started, the business method can be executed, that is, the business sub-data and local message data corresponding to the local transaction are entered into the warehouse to ensure the consistency of the data of the local transaction. If the business method is executed successfully, the post-operation can be continued to be executed, the local transaction is committed, and the success message indicating the successful execution of the local transaction is sent to the message middleware. If the business method fails to execute, the failure log can be recorded and a failure message can be sent to the message middleware.
[0063] By setting a target annotation for the data entry interface of each local transaction, the pre-operation in the target annotation can be used to ensure the opening of each local transaction, thereby ensuring the execution of the business sub-data entry logic and the forwarding of messages when the entry fails. The post-operation in the target annotation can also be used to ensure the forwarding of messages and secondary confirmation when the local transaction is successfully processed.
[0064] In some optional embodiments, the above step 104 may be specifically performed by the target component according to the following steps:
[0065] The first step is to configure target processing rules for each message received based on the type of the message.
[0066] The target processing rule is a transaction compensation rule or a message confirmation rule. The target processing rule includes a rule chain and a component script. The rule chain is used to describe the business execution process. The component script is used to load the component associated with the rule chain. Each component business logic script can connect the business expression of the entire rule chain in series.
[0067] Specifically, for each received message, if the message is a failure message indicating that the local transaction processing has failed, the transaction compensation rule is configured; if the message is a success message indicating that the local transaction processing has succeeded, the message confirmation rule is configured.
[0068] The second step is to instantiate the rule chain and run the component script to confirm the message or perform compensation processing on the local transaction corresponding to the message.
[0069] Specifically, if the target processing rule is the transaction compensation rule, the rule chain in the transaction compensation rule is instantiated, and the component script in the transaction compensation rule is run to re-execute the local transaction corresponding to the message; if the target processing rule is the message confirmation rule, the rule chain in the message confirmation rule is instantiated, and the component script in the message confirmation rule is run to confirm the message.
[0070] As an example, see Figure 3 , which is a schematic diagram of the transaction compensation processing process and message confirmation process of the present application. After receiving the message forwarded by the message middleware, the target component (for example, the message consumer program) can dynamically load the target processing rule (transaction compensation rule or message confirmation rule) and instantiate it according to the content type indicated by the message, so as to perform transaction compensation processing or message confirmation processing.
[0071] By configuring the target processing rules based on the message type, it is possible to flexibly configure matching processing rules according to the content type indicated by the message, thereby improving the overall efficiency of data processing.
[0072] Further references Figure 4 As an implementation of the methods shown in the above figures, the present application provides an embodiment of a transaction processing device, which is similar to Figure 1 The method embodiments shown correspond.
[0073] like Figure 4 As shown, the transaction processing device 400 of this embodiment includes: a conversion unit 401, which is used to split the business data involved in the data warehousing transaction into multiple business sub-data, and convert the data warehousing transaction into a distributed transaction, wherein the distributed transaction includes multiple local transactions, and each local transaction is used to store one business sub-data of the multiple business sub-data; a warehousing unit 402, which is used to start each local transaction to store the business sub-data corresponding to each local transaction, and obtain the warehousing result of each business sub-data; a forwarding unit 403, which is used to generate a message indicating whether each local transaction is successfully executed based on the warehousing result of each business sub-data, and forward the message to the target component via the message middleware; a processing unit 404, which is used to confirm the message indicating the successful execution of the local transaction through the target component, and perform compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
[0074] Optionally, the warehousing unit 402 is also used to obtain local message data corresponding to each local transaction, the local message data including a main message identifier, a local message identifier and parameter information, the main message identifier is used to indicate the data warehousing transaction, and the local message identifier is used to indicate the local transaction; the business sub-data corresponding to each local transaction and the local message data are stored in the warehouse; the device also includes a deletion unit, which is used to delete the local message data that has been stored after the target component confirms the message indicating that the local transaction is successfully executed.
[0075] Optionally, the local transaction is also used to store local message data; the storage unit 402 is also used to call the data storage interface corresponding to each local transaction, and the data storage interface is added with a target annotation, and the target annotation is used to indicate that a pre-operation is performed before the business sub-data is stored, and the pre-operation includes starting the local transaction; the pre-operation indicated by the target annotation is executed to start each local transaction.
[0076] Optionally, the target annotation is also used to perform post-operations after the business sub-data is successfully stored in the database, and the post-operations include: committing the local transaction, generating a success message indicating that the local transaction is successfully executed when the local transaction is successfully committed, and sending the success message to the message middleware; the forwarding unit 403 is also used for, for each local transaction, if the business sub-data involved in the local transaction is successfully stored in the database, executing the post-operation indicated by the target annotation to commit the local transaction, generating the success message when the local transaction is successfully committed, and sending the success message to the message middleware; for each local transaction, if the business sub-data involved in the local transaction fails to be stored in the database, generating a failure message indicating that the local transaction failed to be executed, and sending the failure message to the message middleware.
[0077] Optionally, the processing unit 404 is also used to perform the following steps through the target component: for each message received, based on the type of the message, configure a target processing rule, the target processing rule being a transaction compensation rule or a message confirmation rule, the target processing rule including a rule chain and a component script, the rule chain being used to describe the business execution process, and the component script being used to load the component associated with the rule chain; instantiating the rule chain and running the component script to confirm the message, or to perform compensation processing on the local transaction corresponding to the message.
[0078] Optionally, the processing unit 404 is further used to configure a transaction compensation rule for each received message if the message is a failure message indicating that local transaction processing has failed; and configure the message confirmation rule if the message is a success message indicating that local transaction processing has succeeded.
[0079] Optionally, the processing unit 404 is also used to instantiate the rule chain in the transaction compensation rule and run the component script in the transaction compensation rule to re-execute the local transaction corresponding to the message if the target processing rule is the transaction compensation rule; if the target processing rule is the message confirmation rule, instantiate the rule chain in the message confirmation rule and run the component script in the message confirmation rule to confirm the message.
[0080] The device provided by the above embodiment of the present application converts the data entry transaction into a distributed transaction by splitting the business data involved in the data entry transaction into multiple business sub-data, so that each local transaction in the distributed transaction is responsible for entering one business sub-data in the multiple business sub-data into the warehouse; then each local transaction is started to enter the business sub-data corresponding to each local transaction into the warehouse, and the entry result of each business sub-data is obtained; then based on the entry result of each business sub-data, a message indicating whether each local transaction is successfully executed is generated, and each message is forwarded to the target component via the message middleware; finally, the message indicating the successful execution of the local transaction is confirmed by the target component, and the local transaction corresponding to the message indicating the failure of the local transaction execution is compensated. In this scheme, on the one hand, since the business data is split into multiple business sub-data and the data entry transaction is converted into a distributed transaction, the data entry efficiency can be improved. On the other hand, since the message middleware is introduced, the local transaction processing result can be confirmed twice when the local transaction is successfully executed, and the local transaction can be asynchronously processed when the local transaction fails to execute, thereby ensuring the success of each local transaction processing and ensuring the consistency of the data. In this way, data consistency can be ensured while improving data processing efficiency.
[0081] Reference below Figure 5 , which shows a schematic structural diagram of an electronic device for implementing some embodiments of the present application. Figure 5 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0082] like Figure 5 As shown, the electronic device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the electronic device 500 are also stored. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0083] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a disk, a hard disk, etc.; and a communication device 509. The communication device 509 may allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 The electronic device 500 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead. Figure 5 Each block shown in the figure may represent one device, or may represent multiple devices as required.
[0084] In particular, according to some embodiments of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, some embodiments of the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In some such embodiments, the computer program can be downloaded and installed from the network through the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of some embodiments of the present application are executed.
[0085] It should be noted that the computer-readable medium described in some embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In some embodiments of the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In some embodiments of the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.
[0086] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.
[0087] The computer-readable medium may be included in the electronic device; or it may exist independently without being installed in the electronic device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: splits the business data involved in the data warehousing transaction into multiple business sub-data, converts the data warehousing transaction into a distributed transaction, and the distributed transaction includes multiple local transactions, each local transaction is used to store one of the multiple business sub-data; starts each local transaction to store the business sub-data corresponding to each local transaction, and obtains the warehousing result of each business sub-data; based on the warehousing result of each business sub-data, generates a message indicating whether each local transaction is successfully executed, and forwards the message to the target component via the message middleware; confirms the message indicating the successful execution of the local transaction through the target component, and performs compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction.
[0088] Computer program code for performing the operations of some embodiments of the present application may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++; and also conventional procedural programming languages such as "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, or may be connected to an external computer (e.g., using an Internet service provider to connect through the Internet), including a local area network (LAN) or a wide area network (WAN).
[0089] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0090] The units described in some embodiments of the present application may be implemented by software or hardware. The units described may also be set in a processor, for example, it may be described as: a processor includes a first determination unit, a second determination unit, a selection unit, and a third determination unit. The names of these units do not, in some cases, constitute limitations on the units themselves.
[0091] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.
[0092] The above description is only some preferred embodiments of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present application is not limited to the technical solutions formed by the specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with (but not limited to) the technical features with similar functions disclosed in the embodiments of the present application to form a technical solution.< / t>
Claims
1. A transaction processing method, characterized in that: The method comprises: Splitting the business data involved in the data warehousing transaction into multiple business sub-data, converting the data warehousing transaction into a distributed transaction, wherein the distributed transaction includes multiple local transactions, each local transaction is used to store one business sub-data among the multiple business sub-data; Start each local transaction to store the business sub-data corresponding to each local transaction into the database, and obtain the storage result of each business sub-data; Based on the storage results of each business sub-data, a message is generated to indicate whether each local transaction is successfully executed, and the message is forwarded to the target component via the message middleware; The target component confirms the message indicating the successful execution of the local transaction, and performs compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
2. The method according to claim 1, characterized in that The storing of the business sub-data corresponding to each local transaction includes: Acquire local message data corresponding to each local transaction, the local message data including a main message identifier, a local message identifier and parameter information, the main message identifier is used to indicate the data storage transaction, and the local message identifier is used to indicate the local transaction; The business sub-data corresponding to each local transaction and the local message data are stored in the database; The method further comprises: After the target component confirms the message indicating that the local transaction is successfully executed, the local message data that has been stored is deleted.
3. The method according to claim 1, characterized in that The starting of each local transaction includes: Calling the data storage interface corresponding to each local transaction, wherein the data storage interface is added with a target annotation, wherein the target annotation is used to indicate that a pre-operation is performed before the business sub-data is stored in the database, and the pre-operation includes starting a local transaction; The preceding operations indicated by the target annotation are executed to start each local transaction.
4. The method according to claim 3, characterized in that The target annotation is also used to perform post-operation after the business sub-data is successfully stored in the database, and the post-operation includes: submitting the local transaction, generating a success message indicating the successful execution of the local transaction when the local transaction is successfully submitted, and sending the success message to the message middleware; The method of generating a message indicating whether each local transaction is successfully executed based on the storage result of each business sub-data, and forwarding the message to the target component via the message middleware includes: For each local transaction, if the business sub-data involved in the local transaction is successfully stored in the database, the post-operation indicated by the target annotation is executed to commit the local transaction, and the success message is generated when the local transaction is successfully committed, and the success message is sent to the message middleware; For each local transaction, if the business sub-data involved in the local transaction fails to be stored in the database, a failure message indicating the failure of the execution of the local transaction is generated, and the failure message is sent to the message middleware.
5. The method according to claim 1, characterized in that The confirming, by the target component, the message indicating the successful execution of the local transaction, and performing compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution, includes: The following steps are performed by the target component: For each received message, a target processing rule is configured based on the type of the message. The target processing rule is a transaction compensation rule or a message confirmation rule. The target processing rule includes a rule chain and a component script. The rule chain is used to describe the business execution process, and the component script is used to load the component associated with the rule chain. The rule chain is instantiated, and the component script is run to confirm the message, or to perform compensation processing on the local transaction corresponding to the message.
6. The method according to claim 5, characterized in that For each received message, based on the type of the message, a target processing rule is configured, including: For each received message, if the message is a failure message indicating that the local transaction processing has failed, a transaction compensation rule is configured; if the message is a success message indicating that the local transaction processing has succeeded, the message confirmation rule is configured.
7. The method according to claim 5, characterized in that The instantiation of the rule chain and running the component script to confirm the message or perform compensation processing on the local transaction corresponding to the message includes: If the target processing rule is the transaction compensation rule, instantiating the rule chain in the transaction compensation rule, and running the component script in the transaction compensation rule to re-execute the local transaction corresponding to the message; If the target processing rule is the message confirmation rule, the rule chain in the message confirmation rule is instantiated, and the component script in the message confirmation rule is run to confirm the message.
8. A transaction processing device, characterized in that: The device comprises: A conversion unit, used to split the business data involved in the data warehousing transaction into multiple business sub-data, and convert the data warehousing transaction into a distributed transaction, wherein the distributed transaction includes multiple local transactions, and each local transaction is used to store one business sub-data among the multiple business sub-data; The storage unit is used to start each local transaction to store the business sub-data corresponding to each local transaction into the storage, and obtain the storage result of each business sub-data; A forwarding unit, used to generate a message indicating whether each local transaction is successfully executed based on the storage result of each business sub-data, and forward the message to the target component via the message middleware; The processing unit is used to confirm the message indicating the successful execution of the local transaction through the target component, and perform compensation processing on the local transaction corresponding to the message indicating the failure of the local transaction execution.
9. An electronic device, characterized in that: include: one or more processors; a storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.
10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.