Micro-service transaction processing method and device, equipment and medium
By generating global transaction snapshots in a microservice architecture and processing data changes in parallel, the problems of excessively long resource locking time and high latency in microservice architecture are solved, the system throughput is improved and the transaction processing latency is reduced, and data consistency and atomicity are ensured.
Patent Information
- Application Number
- CN202511392465.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-26
- Publication Date
- 2026-02-10
AI Technical Summary
In microservice architectures, traditional distributed transaction protocols result in excessively long resource locking times, reduced system throughput, and high transaction processing latency, making it difficult to meet low-latency business requirements.
A global transaction snapshot is generated in the transaction coordination layer cache, including the data changes of distributed transaction requests. When each participating service responds with a ready signal, parallel persistence processing is triggered. By pre-generating snapshots to compress resource locking time and triggering persistence in parallel, transaction processing latency is reduced.
It improves system throughput, reduces transaction processing latency, ensures data consistency and atomicity, and solves the problems of excessively long resource locking time and high latency in traditional protocols.
Smart Images

Figure CN121501427A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of resource allocation, and in particular to a micro-service transaction processing method, device, equipment and medium. BACKGROUND
[0002] In the service-splitting micro-service architecture, the distributed transaction protocol currently adopted by cross-service transactions ensures data consistency by realizing Atomicity (A), Consistency (C), Isolation (I) and Durability (D), but on the one hand, the synchronous blocking mechanism of the traditional protocol will cause the resource locking time to be too long, directly causing the system throughput to decrease; on the other hand, due to the inherent characteristics of the protocol, the average delay of the transaction processing of the existing scheme is high, and it is difficult to meet the stringent requirements of the business on low delay. SUMMARY
[0003] The present application provides a micro-service transaction processing method, device, equipment and medium to solve the technical problems of throughput decrease and high delay in the micro-service transaction processing of the prior art.
[0004] The present application provides a micro-service transaction processing method, comprising the following steps: In response to a distributed transaction request, a global transaction snapshot is generated in a transaction coordination layer cache; the global transaction snapshot includes the data change content of the operation data required by the distributed transaction corresponding to the distributed transaction request; When receiving the ready-to-use signals fed back by each participating service in the distributed transaction, the data change content is triggered by each participating service in the distributed transaction based on the global transaction snapshot to perform persistent processing in parallel.
[0005] According to the micro-service transaction processing method provided by the present application, in response to a distributed transaction request, a global transaction snapshot is generated in a transaction coordination layer cache, comprising: In response to a distributed transaction request, the operation log generated by each participating service in the distributed transaction when performing local operation based on the operation data required by the distributed transaction is obtained; The operation log of each participating service in the distributed transaction is encapsulated into a snapshot unit in the transaction coordination layer cache, respectively, and each snapshot unit is assigned a version number; Based on the snapshot unit and the version number corresponding to each participating service in the distributed transaction, a global transaction snapshot is generated.
[0006] The microservice transaction processing method provided by the application comprises the following steps: In response to the distributed transaction request, the cache line corresponding to the operation data required by the distributed transaction is locked; After the cache line is successfully locked, the operation log generated by each participating service in the distributed transaction when performing local operation based on the operation data required by the distributed transaction is acquired.
[0007] The microservice transaction processing method provided by the application further comprises the following steps after generating the global transaction snapshot in the transaction coordination layer cache in response to the distributed transaction request: When it is detected that the participating service in the distributed transaction fails or performs abnormally, a data rollback operation is performed based on the global transaction snapshot.
[0008] The microservice transaction processing method provided by the application, wherein the data rollback operation based on the global transaction snapshot comprises the following steps: According to the global transaction snapshot, target difference data is determined; the target difference data comprises at least one of difference data before and after the failure of the distributed transaction and difference data before and after the abnormal execution; The data rollback operation is performed on the target difference data.
[0009] The microservice transaction processing method provided by the application further comprises the following steps before generating the global transaction snapshot in the transaction coordination layer cache: The history access queue of the distributed transaction corresponding to the distributed transaction request is acquired; Based on the history access queue, the operation data required by the distributed transaction corresponding to the distributed transaction request is determined by using the LRU-K algorithm; The operation data required by the distributed transaction corresponding to the distributed transaction request is loaded into the preprocessing layer cache, and a first version mark with a time stamp is generated for the operation data required by the distributed transaction corresponding to the distributed transaction request; The second version mark corresponding to the operation data required by the distributed transaction in the database log is compared with the first version mark in the preprocessing layer cache; When it is detected that the version deviation of the second version mark and the first version mark exceeds a threshold value, the data corresponding to the first version mark in the preprocessing layer cache is updated based on the second version mark.
[0010] According to the microservice transaction processing method provided by the application, the data change content is triggered to be persisted in parallel by each participating service in the distributed transaction based on the global transaction snapshot, and the method comprises the following steps: In the persistent layer cache, the change request corresponding to the data change content of the global transaction snapshot is merged into a batch I / O request by adopting a merge write strategy; The batch I / O request is written into the database to complete the persistent processing.
[0011] The application further provides a microservice transaction processing device, which comprises: A response module is configured to generate a global transaction snapshot in a transaction coordination layer cache in response to a distributed transaction request, wherein the global transaction snapshot comprises data change content of operation data required by a distributed transaction corresponding to the distributed transaction request; A processing module is configured to trigger each participating service in the distributed transaction to persist the data change content in parallel based on the global transaction snapshot when a ready signal fed back by each participating service in the distributed transaction is received.
[0012] The application further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the microservice transaction processing method of any of the above when executing the program.
[0013] The application further provides a non-transitory computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the microservice transaction processing method of any of the above.
[0014] The application further provides a computer program product comprising a computer program, wherein the computer program is executed by a processor to implement the microservice transaction processing method of any of the above.
[0015] The microservice transaction processing method, device, equipment and medium provided by the application generate a global transaction snapshot in a transaction coordination layer cache in response to a distributed transaction request, wherein the global transaction snapshot comprises data change content of operation data required by a distributed transaction corresponding to the distributed transaction request, and each participating service in the distributed transaction is triggered to persist the data change content in parallel based on the global transaction snapshot when a ready signal fed back by each participating service in the distributed transaction is received. Thus, the application can compress the pre-resource locking time on one hand and effectively improve the throughput, and can shorten the total time consumption of the commit phase on the other hand by triggering the persistence in parallel, thereby reducing the transaction processing delay. BRIEF DESCRIPTION OF DRAWINGS
[0016] In order to more clearly illustrate the technical solutions in the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.
[0017] Figure 1 is a flowchart of a microservice transaction processing method provided by an embodiment of the present application.
[0018] Figure 2 is a structural diagram of a microservice transaction processing device provided by an embodiment of the present application.
[0019] Figure 3 is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0020] In order to make the objects, technical solutions and advantages of the present application clearer, the following will combine the drawings in the present application to clearly and completely describe the technical solutions in the present application. Obviously, the described embodiments are some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort fall within the protection scope of the present application.
[0021] The microservice transaction processing method of the embodiment of the present application, as shown in Figure 1 , includes steps 110 and 120.
[0022] Step 110: In response to a distributed transaction request, a global transaction snapshot is generated in a transaction coordination layer cache; the global transaction snapshot includes data change content of operation data required by a distributed transaction corresponding to the distributed transaction request.
[0023] Here, the distributed transaction request refers to a transaction operation request that needs to be completed cooperatively across multiple independent services. The request can be initiated by a client application or triggered by a certain service in the system, and no limitation is made on this.
[0024] It should be understood that in a microservice architecture, a business process often needs to call multiple services (such as order service, inventory service, payment service), and these services usually have independent databases or storage resources. When the operations of these services need to meet the atomicity requirement of “all success or all failure”, a distributed transaction is formed.
[0025] In this embodiment, when the system receives a distributed transaction request, the request is first routed to the transaction coordination layer, which assigns a globally unique transaction ID to the request and identifies all participating services needed to complete the transaction. The transaction coordination layer distributes corresponding tasks to each participating service. Each participating service executes its business logic locally and calculates the changes to the data it is responsible for if the transaction is successful. Each participating service reports the calculated data changes to the transaction coordination layer. The transaction coordination layer collects all the data changes reported by the participating services and aggregates them to form a complete global transaction snapshot, which is then stored in the transaction coordination layer cache.
[0026] It should be noted that the transaction coordination layer refers to a logical layer or a physical layer independent of the participating services, and the transaction coordination layer has its own cache space, i.e., the transaction coordination layer cache, for storing intermediate state data during transaction processing.
[0027] The global transaction snapshot refers to a data collection generated in the transaction coordination layer cache for a certain distributed transaction. This data collection is the final state of all data involved in the transaction if it is to be successfully committed, i.e., the data change content. The data change content refers to the final state value of the target data after the successful execution of the distributed transaction. For example, if a transaction is to change the account balance of user A from 100 yuan to 80 yuan and the account balance of user B from 50 yuan to 70 yuan, the data change content includes "the account balance of user A is 80 yuan and the account balance of user B is 70 yuan". It can be the new value of a field in the database, a complete data row to be inserted, or an identifier of a data row to be deleted, etc., without limitation.
[0028] Step 120, upon receiving the readiness signals fed back by the participating services in the distributed transaction, triggering the participating services in the distributed transaction to perform the data change content in parallel based on the global transaction snapshot.
[0029] Here, the readiness signal refers to a confirmation signal fed back by each participating service to the transaction coordination layer in a distributed transaction. The readiness signal indicates that the participating service has completed all local calculations and resource preparations, and confirms that it has the conditions to perform data persistence (such as normal local database connection, sufficient disk space, etc.).
[0030] In this embodiment, the transaction coordination layer acts as a coordinator, responsible for listening and collecting the ready signals from all participating services. When the transaction coordination layer confirms that it has received the ready signals of all participating services involved in this distributed transaction, it considers that the entire transaction has reached a commitable state. At this time, the transaction coordination layer broadcasts an instruction to execute the commit to all participating services. After receiving the instruction, each participating service executes the write operation of the local database according to the data change content determined in advance, and completes the persistence processing in parallel.
[0031] It should be understood that parallel persistence of data change content refers to that after receiving the instruction to execute the commit from the transaction coordination layer, all participating services simultaneously and independently start writing the data change content belonging to each participating service in the global transaction snapshot into the persistent storage (such as a relational database, a NoSQL database, etc.) of the back end, without waiting for each other. In this way, the final commit time of the entire transaction depends only on the persistence time of the slowest participating service, rather than the sum of the persistence times of all participating services.
[0032] The microservice transaction processing method of the embodiment of the application, on the one hand, compresses the resource locking pre-time by pre-generating the global transaction snapshot, effectively improving the throughput, and on the other hand, shortens the total time consumption in the commit phase by triggering the persistence in parallel, thereby reducing the transaction processing delay.
[0033] It should be noted that each embodiment of the present application can be freely combined, the order can be changed or executed alone, and does not need to rely on or depend on a fixed execution order.
[0034] In some embodiments, before generating the global transaction snapshot in the transaction coordination layer cache, the method further comprises: obtaining a historical access queue of a distributed transaction corresponding to the distributed transaction request; determining operation data required by the distributed transaction corresponding to the distributed transaction request based on the historical access queue by using an LRU-K algorithm; loading the operation data required by the distributed transaction corresponding to the distributed transaction request to a preprocessing layer cache, and generating a first version mark with a timestamp for the operation data required by the distributed transaction corresponding to the distributed transaction request; comparing a second version mark corresponding to the operation data required by the distributed transaction in a database log with the first version mark in the preprocessing layer cache; when detecting that the version deviation between the second version mark and the first version mark exceeds a threshold, updating the data corresponding to the first version mark in the preprocessing layer cache based on the second version mark.
[0035] In this embodiment, after responding to the distributed transaction request and before generating the global transaction snapshot, a preprocessing read-write cache step is also included, which is executed in the preprocessing layer.
[0036] Here, the historical access queue refers to a list of records maintained by the system for related data. This list records the times when the data was accessed in the past period of time, either in chronological order or by access frequency; that is, the historical access timestamps.
[0037] In this embodiment, the LRU-K algorithm is used to dynamically preload hot transaction operations. Here, LRU-K refers to an improved algorithm compared to the traditional LRU (Least Recently Used) algorithm, and K refers to the K most recent accesses. Specifically, based on the K most recently accessed records, the data's "hotness" (such as the frequency and timeliness of access) is determined, and data with high "hotness" is retained while data with low "hotness" is discarded. This allows the data most likely to be processed by the distributed transaction to be preloaded in the preprocessing layer. In this embodiment, K can be a preset integer.
[0038] In one example, if there are fewer than K historical access timestamps in the historical access queue of data (e.g., it has only been accessed once), it is considered cold data and has a lower priority; if K historical access timestamps have been accumulated, the interval between the most recent access time and the current time (i.e., the duration of time that it has not been accessed) is calculated. The shorter the interval, the higher the data popularity.
[0039] Here, the preprocessing layer refers to the first-level cache layer located in the transaction coordinator, which is a cache area used for read / write optimization. In this embodiment, before generating a global transaction snapshot in the transaction coordinator layer cache, it is first checked whether the data determined based on the LRU-K algorithm is already in the preprocessing layer cache. If not, it will be preloaded from persistent storage such as the backend database.
[0040] When data is loaded or updated to the preprocessing layer cache, the system appends a first version tag to it, which reflects the current version of the data. Then, it compares the second version tag corresponding to the data to be operated on in this distributed transaction in the database log with the first version tag in the current preprocessing layer cache. Here, the second version tag refers to the version tag obtained from the database's transaction log, reflecting the latest state of the data in persistent storage.
[0041] In this embodiment, a threshold is pre-set to measure whether a partial refresh operation of the data in the preprocessing layer cache is triggered. Here, a partial refresh operation refers to the operation of reloading only the inconsistent data when it is detected that the data in the preprocessing layer cache may be inconsistent with the database (i.e., the data is outdated), without clearing the entire cached data in the preprocessing layer.
[0042] Specifically, when the version deviation between the second version tag and the first version tag exceeds a threshold (for example, the second version tag is V5, the first version tag is V2, and the threshold is 2), the data corresponding to the first version tag currently cached in the preprocessing layer is updated to the data corresponding to the second version tag in the database to ensure data consistency.
[0043] The microservice transaction processing method of this invention preloads relevant data into the cache using the LRU-K algorithm before the transaction officially begins execution, reducing the latency caused by accessing the database during transaction execution. Simultaneously, version tag comparison and partial refresh mechanisms ensure the accuracy of data operations.
[0044] In some embodiments, generating a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request includes: In response to a distributed transaction request, obtain the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction; Each operation log of the service participating in the distributed transaction is encapsulated into a snapshot unit in the transaction coordination layer cache, and a version number is assigned to each snapshot unit. A global transaction snapshot is generated based on the snapshot unit and version number corresponding to each participating service in the distributed transaction.
[0045] Here, the operation log refers to the detailed record of how the data changes when each participating service performs local operations based on the operation data required by the distributed transaction, including but not limited to: operation type (add, delete, modify), data identifier, structured data of the data before and after the data change.
[0046] In this embodiment, the transaction coordination layer structurally encapsulates the original operation logs received from each participating service, forming an independent, identifiable, and reusable snapshot unit. Furthermore, each snapshot unit is assigned an independent, unique version number within the current transaction. This version number can be used to track the order of operations within the transaction and provide a basis for any subsequent rollback operations.
[0047] Finally, the transaction coordination layer aggregates all snapshot units belonging to the same global transaction ID, forming a list or a tree structure, i.e., the global transaction snapshot. The global transaction snapshot completely records all data changes that need to be performed in this distributed transaction.
[0048] The microservice transaction processing method of this invention obtains the local operation logs of each participating service and encapsulates them into snapshot units with version numbers, and finally generates a global transaction snapshot, thereby realizing unified recording, version control and global traceability of distributed transaction operation data.
[0049] In some embodiments, the step of obtaining the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction in response to a distributed transaction request includes: In response to a distributed transaction request, the cache line corresponding to the data to be operated on by the distributed transaction is locked; After the cache line is successfully locked, the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction are obtained.
[0050] In this embodiment, when the transaction coordination layer processes distributed transactions, it first locates the specific physical storage unit (such as a storage block divided by data shards) corresponding to the data in the transaction coordination layer cache based on the unique identifier of the data to be operated on in this transaction and through preset mapping rules (such as hash calculation and index matching). The smallest unit that can be independently locked in this physical storage unit is defined as a cache line. Then, a locking operation is performed on the cache line.
[0051] Here, a distributed lock mechanism can be used for locking operations. Specifically, a unique lock identifier (such as cache line ID + transaction ID) is generated for each cache line located, and precise locking of the target cache line is achieved by preempting this lock identifier.
[0052] Based on this, this embodiment refines the table-level locks that rely on the database in traditional distributed transactions into cache row-level locks that are cached in the transaction coordination layer. It locks only the smallest data unit that the transaction actually needs to operate on, thereby avoiding lock occupation of irrelevant data and reducing unnecessary lock contention.
[0053] Once the cache line is successfully locked, local business calculations begin, and corresponding operation logs are generated. Furthermore, after execution, the lock can be held until the entire distributed transaction is committed or rolled back, thus ensuring data isolation throughout the entire process from preparation to commit.
[0054] The microservice transaction processing method of this invention effectively solves the conflict problem in high-concurrency scenarios by locking resources in a fine-grained manner early in the transaction preparation phase. It ensures that the data on which a global transaction snapshot depends is not interfered with or modified by other concurrent transactions during the generation of the snapshot, thereby guaranteeing the accuracy and consistency of the snapshot content.
[0055] In some embodiments, after generating a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request, the method further includes: When a failure or execution anomaly is detected in the service involved in the distributed transaction, a data rollback operation is performed based on the global transaction snapshot.
[0056] In this embodiment, the transaction coordination layer monitors the status of each participating service, and its detection mechanism includes, but is not limited to: Timeout detection: If no response is received from a participating service within a preset time (e.g., the timeout period for waiting for a ready signal), it is determined that a failure has occurred. Error feedback: When a participating service encounters an error while performing local operations (such as database connection failure, business rule verification failure, etc.), it proactively reports the execution exception to the transaction coordination layer. Heartbeat or health check: The transaction coordination layer uses a heartbeat mechanism with participating services to determine whether a failure or execution anomaly has occurred.
[0057] Once a failure or execution anomaly is detected in any participating service, the transaction coordination layer will suspend the entire distributed transaction commit process. Then, using a global transaction snapshot as the unified basis for rollback, it will restore the operation data of all participating services to the state before the transaction execution, ensuring the atomicity of the distributed transaction and avoiding data inconsistency.
[0058] The microservice transaction processing method of this invention guides rollback through a global transaction snapshot, ensuring that all participating services can uniformly and coordinately revoke the pre-operations that have been executed and restore the data to the state before the transaction started, thereby effectively preventing data inconsistency problems caused by the failure of some nodes.
[0059] In some embodiments, performing a data rollback operation based on the global transaction snapshot includes: Based on the global transaction snapshot, target difference data is determined; the target difference data includes at least one of the difference data before and after the failure in the distributed transaction and the difference data before and after the execution exception. Perform a data rollback operation on the target difference data.
[0060] Here, target difference data refers to the difference data before and after a failure, determined based on the data recorded in the global transaction snapshot during the execution of a distributed transaction, or the difference data before and after an execution anomaly.
[0061] For example, when a service experiences a failure (such as a system crash or network interruption), it may have partially executed local operations but not completed them, resulting in discrepancies where the data is in a partially modified state. Alternatively, when a service performs an operation, an anomaly (such as insufficient inventory or incorrect data format) may cause the operation to fail, but some data may have already been modified, resulting in discrepancies.
[0062] In this embodiment, after the target difference data is determined, the target difference data is restored to its initial state before the transaction execution based on the global transaction snapshot.
[0063] The microservice transaction processing method of this invention implements incremental rollback through global transaction snapshots, thereby improving the efficiency of data rollback.
[0064] In some embodiments, the step of triggering the concurrent persistence of the data changes by participating services in the distributed transaction based on the global transaction snapshot includes: In the persistent layer cache, a merge write strategy is adopted to merge the change requests corresponding to the data change content of the global transaction snapshot into batch I / O requests; The batch I / O requests are written to the database to complete the persistence process.
[0065] In this embodiment, a merge write strategy is adopted in the persistent layer cache to merge multiple data changes belonging to different distributed transactions in the global transaction snapshot into a batch I / O request.
[0066] Here, the persistent layer cache refers to the third-level cache in the transaction coordinator. It is a buffer between the transaction coordinator and the database, used to temporarily store data changes to be written to the database, thus avoiding frequent direct calls to the database interface by the transaction coordinator.
[0067] In this embodiment, when the transaction coordination layer triggers parallel persistence, it does not allow each participating service to write data directly to the database. Instead, it first aggregates the data changes of all services into the persistence layer cache, and then integrates them into batch I / O requests through a merge write strategy.
[0068] Specifically, the transaction coordination layer extracts all data changes involved in the service from the global transaction snapshot and writes these scattered data changes into the persistent layer cache.
[0069] The persistent cache uses merge rules based on both database type and operation type to consolidate scattered data change requests into batch I / O requests. These merge rules include, but are not limited to: Merging SQL statements of the same type: If multiple change requests are in the same table and have the same operation type, they will be merged into a single batch SQL (Structured Query Language) statement; Batch transaction commit: If a change request involves multiple tables or multiple operation types, these SQL statements are packaged into a single database batch transaction. All operations are completed in a single transaction commit, reducing the number of database transaction creations and commits.
[0070] Once the persistent cache generates a batch of I / O requests, it sends these requests to the database all at once, completing the final data persistence.
[0071] The microservice transaction processing method of this invention reduces disk access frequency by merging change requests corresponding to data changes in the global transaction snapshot into batch I / O requests through a merge write strategy.
[0072] The microservice transaction processing apparatus provided by the present invention is described below. The microservice transaction processing apparatus described below can be referred to in correspondence with the microservice transaction processing method described above.
[0073] The microservice transaction processing apparatus of this invention, as shown in the embodiments of the present invention. Figure 2 As shown, it includes the following modules: Response module 210 is used to generate a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request; the global transaction snapshot includes the data change content of the data to be operated on by the distributed transaction corresponding to the distributed transaction request; Processing module 220 is used to, upon receiving a ready signal from each participating service in the distributed transaction, trigger each participating service in the distributed transaction to perform parallel persistence processing of the data changes based on the global transaction snapshot.
[0074] The microservice transaction processing device in this embodiment generates a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request. The global transaction snapshot includes the data changes required for the distributed transaction operations corresponding to the distributed transaction request. Upon receiving the ready signals from each participating service in the distributed transaction, the device triggers each participating service in the distributed transaction to perform parallel persistence processing of the data changes based on the global transaction snapshot. Therefore, this invention, on the one hand, compresses the resource locking lead time by pre-generating a global transaction snapshot, effectively improving throughput; on the other hand, it shortens the total commit phase time by triggering persistence in parallel, reducing transaction processing latency.
[0075] Figure 3 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 3As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute a microservice transaction processing method, which includes: In response to a distributed transaction request, a global transaction snapshot is generated in the transaction coordination layer cache; the global transaction snapshot includes the data changes required for the distributed transaction operation corresponding to the distributed transaction request. Upon receiving the ready signal from each participating service in the distributed transaction, the participating services in the distributed transaction are triggered to perform parallel persistence processing of the data changes based on the global transaction snapshot.
[0076] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., each of which can store program code.
[0077] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program that can be stored on a non-transitory computer-readable storage medium, wherein when the computer program is executed by a processor, the computer is capable of executing the microservice transaction processing method provided by each of the above methods, the method comprising: In response to a distributed transaction request, a global transaction snapshot is generated in the transaction coordination layer cache; the global transaction snapshot includes the data changes required for the distributed transaction operation corresponding to the distributed transaction request. Upon receiving the ready signal from each participating service in the distributed transaction, the participating services in the distributed transaction are triggered to perform parallel persistence processing of the data changes based on the global transaction snapshot.
[0078] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the microservice transaction processing method provided by each of the above methods, the method comprising: In response to a distributed transaction request, a global transaction snapshot is generated in the transaction coordination layer cache; the global transaction snapshot includes the data changes required for the distributed transaction operation corresponding to the distributed transaction request. Upon receiving the ready signal from each participating service in the distributed transaction, the participating services in the distributed transaction are triggered to perform parallel persistence processing of the data changes based on the global transaction snapshot.
[0079] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0080] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.
[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in each of the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of each embodiment of the present invention.
Claims
1. A microservice transaction processing method, characterized in that, include: In response to a distributed transaction request, a global transaction snapshot is generated in the transaction coordination layer cache; The global transaction snapshot includes the data changes required for the operation data of the distributed transaction corresponding to the distributed transaction request. Upon receiving the ready signal from each participating service in the distributed transaction, the participating services in the distributed transaction are triggered to perform parallel persistence processing of the data changes based on the global transaction snapshot.
2. The microservice transaction processing method according to claim 1, characterized in that, The step of generating a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request includes: In response to a distributed transaction request, obtain the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction; Each operation log of the service participating in the distributed transaction is encapsulated into a snapshot unit in the transaction coordination layer cache, and a version number is assigned to each snapshot unit. A global transaction snapshot is generated based on the snapshot unit and version number corresponding to each participating service in the distributed transaction.
3. The microservice transaction processing method according to claim 2, characterized in that, The step of responding to a distributed transaction request by obtaining the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction includes: In response to a distributed transaction request, the cache line corresponding to the data to be operated on by the distributed transaction is locked; After the cache line is successfully locked, the operation logs generated by each participating service in the distributed transaction when performing local operations based on the operation data required by the distributed transaction are obtained.
4. The microservice transaction processing method according to claim 1 or 2, characterized in that, After generating a global transaction snapshot in the transaction coordination layer cache in response to a distributed transaction request, the process further includes: When a failure or execution anomaly is detected in the service involved in the distributed transaction, a data rollback operation is performed based on the global transaction snapshot.
5. The microservice transaction processing method according to claim 4, characterized in that, The data rollback operation based on the global transaction snapshot includes: Based on the global transaction snapshot, target difference data is determined; the target difference data includes at least one of the difference data before and after the failure in the distributed transaction and the difference data before and after the execution exception. Perform a data rollback operation on the target difference data.
6. The microservice transaction processing method according to claim 1, characterized in that, Before generating a global transaction snapshot in the transaction coordination layer cache, the process also includes: Obtain the historical access queue of the distributed transaction corresponding to the distributed transaction request. Based on the historical access queue, the LRU-K algorithm is used to determine the operation data required for the distributed transaction corresponding to the distributed transaction request. Load the operation data required for the distributed transaction corresponding to the distributed transaction request into the preprocessing layer cache, and generate a first version tag with a timestamp for the operation data required for the distributed transaction corresponding to the distributed transaction request. Compare the second version tag corresponding to the operation data required for the distributed transaction in the database log with the first version tag in the preprocessing layer cache; When the version deviation between the second version tag and the first version tag exceeds a threshold, the data corresponding to the first version tag in the preprocessing layer cache is updated based on the second version tag.
7. The microservice transaction processing method according to claim 1, characterized in that, The step of triggering the distributed transaction based on the global transaction snapshot to persist the data changes in parallel by each participating service, includes: In the persistent layer cache, a merge write strategy is adopted to merge the change requests corresponding to the data change content of the global transaction snapshot into batch I / O requests; The batch I / O requests are written to the database to complete the persistence process.
8. A microservice transaction processing device, characterized in that, include: The response module is used to generate a global transaction snapshot in the transaction coordination layer cache in response to distributed transaction requests; The global transaction snapshot includes the data changes required for the operation data of the distributed transaction corresponding to the distributed transaction request. The processing module is used to, upon receiving a ready signal from each participating service in the distributed transaction, trigger each participating service in the distributed transaction to perform parallel persistence processing of the data changes based on the global transaction snapshot.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the microservice transaction processing method as described in any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the microservice transaction processing method as described in any one of claims 1 to 7.
Citation Information
Cited By
Autonomous transaction implementation method and device based on postgresql database and medium
CN122387974A