A transaction control method and program product

Abstract

The present application proposes a transaction control method and program product, which establishes an update mechanism for the corresponding key of the core node based on each transaction request. It involves establishing an association between the transaction number representing the transaction request and the identification information representing the storage node and the transaction request. In addition, the corresponding key of each core node in the present application has a more detailed value division granularity, which may involve the modification value generated in the transaction process, the value of the transaction number, the identification information, and the value of the historical version number. Combining the association design of the transaction request with the granularity design of the corresponding key, when there is a need for transaction recovery, it is possible to effectively determine the appropriate target value of the corresponding key of the core node to perform the corresponding recovery process, thereby realizing rollback or recovery for each transaction request.

Description

Technical Field

[0001] The present application relates to distributed system technology, and in particular, to a transaction control method and program product. Background Art

[0002] Distributed key-value storage system is a data storage system that disperses data and stores it in the form of key-value pairs. It is widely used because of its advantages such as simplicity, security, speed and reliability.

[0003] As a common distributed key-value storage system, the ETCD storage system is often used for shared configuration and service discovery. Taking the ETCD storage system as an example, when implementing common transaction functions, it usually uses the "TXN (Transaction) method". Its basic syntax is the "if-then-else" structure, that is, the conditional expression for comparison is defined in the If statement. If all the conditions are true, the operation in the Then statement is executed, otherwise the operation in the Else statement is executed.

[0004] Based on the grammatical structure of the "TXN (Transaction) method", the implementation scheme of the existing technology has the following technical features: 1) Atomicity, that is, all comparisons and operations are either all successful or all failed; 2) Consistency, it must be ensured that the database is transferred from one consistent state to another. Therefore, each modification to the storage will increase the revision of the key-value storage and generate the same revision for each completed request.

[0005] However, when there are multiple copies in the application scenario and the arbitration mechanism of the etcd storage system needs to be used, the above characteristics of the current "TXN (Transaction) method" result in a coarse control granularity for transactions and cannot adapt to complex control logic. Summary of the invention

[0006] The purpose of the present application is to provide a transaction control method and a program product, which are used to provide a transaction control mechanism based on transaction requests to improve control accuracy and improve transaction processing efficiency.

[0007] In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0008] In a first aspect, an embodiment of the present application provides a transaction control method, including:

[0009] The transaction manager writes a transaction number and identification information for a transaction request; the transaction request is sent by a core node; the transaction request includes a business type; the transaction number is used to uniquely identify the transaction request; the identification information is used to identify the storage node to which the transaction manager belongs;

[0010] The business execution module obtains a distributed lock according to the business type, and the distributed lock indicates that only one transaction processing flow is allowed for the same business type;

[0011] The service execution module executes the transaction processing flow according to the transaction request, the transaction number and the identification information;

[0012] When the transaction processing flow generates a modification of the corresponding key of the core node, the transaction manager writes the value to be updated into the target value of the corresponding key of the core node; the value to be updated includes: the value of the transaction number, the identification information and the value of the historical version number; the historical version number represents the version information of the last completed modification of the corresponding key of the core node.

[0013] Optionally, after the step of the transaction manager writing the transaction number and identification information for the transaction request, the step further includes:

[0014] The transaction manager stores the transaction request in a corresponding transaction log.

[0015] Optionally, after the step of the transaction manager writing the value to be updated into the target value of the key corresponding to the core node when the transaction processing flow generates a modified value, the step further includes:

[0016] When the transaction processing flow is not completed, the target value of the corresponding key of the core node is marked as an intermediate state.

[0017] Optionally, after the step of the transaction manager writing the value to be updated into the target value of the corresponding key of the core node when the transaction processing flow generates a modified value, the step further includes:

[0018] When the transaction processing flow is completed, the business execution module releases the distributed lock; and the target value of the corresponding key of the core node is marked as completed;

[0019] The transaction manager deletes the transaction log corresponding to the transaction request.

[0020] Optionally, the storage node to which the transaction manager belongs is a backup node; and the method further includes:

[0021] If the master-slave switching condition is triggered, the transaction manager traverses the transaction log to determine the key set of the corresponding key of the core node that has changed;

[0022] The transaction manager reads the current transaction number and current identification information of each corresponding key in the key set one by one;

[0023] Determine whether there is a transaction number identical to the current transaction number in the transaction log, and whether there is identification information identical to the current identification information;

[0024] If both exist, the target value of the corresponding key is restored according to the version information of the last modification included in the target value of the corresponding key.

[0025] Optionally, if at least one does not exist, determining whether the transaction number and identification information contained in the transaction log have completed traversal;

[0026] If the traversal is completed, the transaction is restored according to the target value of the corresponding key after recovery;

[0027] If the traversal is not completed, the process returns to the step of executing the transaction manager to read the current transaction number and the current identification information of each corresponding key in the key set one by one.

[0028] In a second aspect, an embodiment of the present application provides a transaction control device, including: a transaction manager and a service execution module;

[0029] The transaction manager is used to write a transaction number and identification information for a transaction request; the transaction request is sent by a core node; the transaction request includes a business type; the transaction number is used to uniquely identify the transaction request; the identification information is used to identify the storage node to which the transaction manager belongs;

[0030] The business execution module is used to obtain a distributed lock according to the business type, wherein the distributed lock indicates that only one transaction processing flow is allowed for the same business type; and execute the transaction processing flow according to the transaction request, the transaction number and the identification information;

[0031] When the transaction processing flow generates a modification of the corresponding key of the core node, the transaction manager is also used to write the value to be updated into the target value of the corresponding key of the core node; the value to be updated includes: the value of the transaction number, the identification information and the value of the historical version number; the historical version number represents the version information of the last completed modification of the corresponding key of the core node.

[0032] Optionally, the transaction manager is further used to store the transaction request in a corresponding transaction log.

[0033] Optionally, the transaction manager is further used to mark the target value of the key corresponding to the core node as an intermediate state when the transaction processing flow is not completed.

[0034] Optionally, the business execution module is further configured to release the distributed lock after the transaction processing flow is completed;

[0035] The transaction manager is further used to mark the target value of the key corresponding to the core node as a completed state; and delete the transaction log corresponding to the transaction request.

[0036] Optionally, the storage node to which the transaction manager belongs is a backup node; the transaction manager is also used to, if the master-slave switching condition is triggered, traverse the transaction log to determine the key set of corresponding keys of the core nodes that have changed; read the current transaction number and current identification information of each corresponding key in the key set one by one; determine whether there is a transaction number identical to the current transaction number, and whether there is identification information identical to the current identification information in the transaction log; if both exist, restore the target value of the corresponding key according to the version information of the last completed modification contained in the target value of the corresponding key.

[0037] Optionally, the transaction manager is further used to determine whether the transaction number and identification information contained in the transaction log have been traversed if at least one does not exist; if the traversal is completed, the transaction is recovered according to the target value of the corresponding key after recovery; if the traversal is not completed, it returns to execute the step of reading the current transaction number and current identification information of each corresponding key in the key set one by one.

[0038] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0039] A memory for storing one or more programs;

[0040] processor;

[0041] When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.

[0042] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, a method as described in any one of the above-mentioned first aspects is implemented.

[0043] In a fifth aspect, an embodiment of the present application provides a program product, which, when executed by a processor, implements a method as described in any one of the above-mentioned first aspects.

[0044] Compared with the prior art, a transaction control method and program product provided in an embodiment of the present application establish an update mechanism for the corresponding key of the core node based on each transaction request. It involves establishing an association between the transaction number representing the transaction request and the identification information representing the storage node and the transaction request. In addition, the corresponding key of each core node in the present application has a more detailed value division granularity, which may involve the modification value generated in the transaction process, the value of the transaction number, the identification information, and the value of the historical version number. Combining the association design of the transaction request with the granularity design of the corresponding key, when there is a need for transaction recovery, it is possible to effectively determine the appropriate target value of the corresponding key of the core node to perform the corresponding recovery process, thereby realizing rollback or recovery for each transaction request.

[0045] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0047] Figure 1 This is a schematic diagram of an arbitration mechanism based on ETCD;

[0048] Figure 2 A schematic diagram of an architecture based on a distributed key-value storage system provided by an embodiment of the present invention;

[0049] Figure 3 A flowchart of a transaction control method provided by an embodiment of the present invention;

[0050] Figure 4 A flowchart of a transaction control method provided by an embodiment of the present invention;

[0051] Figure 5 A schematic diagram of an arbitration mechanism based on ETCD provided in an embodiment of the present invention;

[0052] Figure 6 A signaling interaction diagram of a transaction control method provided by an embodiment of the present invention;

[0053] Figure 7 A signaling interaction diagram of another transaction control method provided by an embodiment of the present invention;

[0054] Figure 8 A flowchart of another transaction control method provided by an embodiment of the present invention;

[0055] Fig. 9 A signaling interaction diagram of another transaction control method provided by an embodiment of the present invention;

[0056] Fig.10 A schematic diagram of the structure of a transaction control device provided by an embodiment of the present invention;

[0057] Fig.11 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0059] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0060] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0061] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0062] The distributed key-value storage system of the prior art uses the syntax structure of the "TXN method" to build transaction functions, resulting in limited transaction processing capabilities. Especially for situations where there are multiple copies, such as memory trading systems in the financial field, it is often necessary to implement centralized arbitration based on the arbitration mechanism of the ETCD node, and then select the master and backup nodes among the core nodes.

[0063] In this scenario, when the main arbitration node is processing arbitration-related transactions, if the main arbitration node crashes, the arbitration transaction may be in an "intermediate state" where the arbitration result has not been notified or feedback from the core node has not been received. Since the "TXN method" does not support the rollback or recovery of the version based on the transaction request made by the core node. Even if another arbitration node takes over the arbitration transaction. Since the relevant key value for the arbitration transaction is in an "intermediate state" at this time, the arbitration node that takes over the transaction cannot confirm the result of the arbitration transaction based on the current "TXN method", resulting in the inability to restore the relevant key value to the state before the execution of the arbitration transaction, and the transaction can no longer be executed.

[0064] Specifically, Figure 1 This is a schematic diagram of an arbitration mechanism based on ETCD, see Figure 1 , the architecture includes: ETCD node 1, ETCD node 2, core node [master], core node [backup]. Among them, ETCD node 1 is the master arbitration node, and ETCD node 2 is the backup arbitration node.

[0065] If the core node [master] sends a transaction request for an alarm event to ETCD node 1, ETCD node 1 executes the arbitration-related transaction process. At this time, if ETCD node 1 crashes. Based on the master-slave mechanism of arbitration transactions, ETCD node 2 is required to take over the arbitration-related transactions. However, if ETCD node 1 does not inform the core node [master] of the arbitration result at this time, or ETCD node 1 has not received feedback from the core node [master]. Then in this "intermediate state", it is possible to cause differences in key-value related versions between replicas. Furthermore, because the "TXN method" does not support version rollback or recovery based on transaction requests, it is impossible to use the rollback mechanism to restore the versions between replicas to a consistent state, resulting in the inability to execute subsequent functions normally.

[0066] In addition, the "TXN method" has a limited number of comparison types that the If statement expression can support. For example, it only supports key / value / version / lease number comparisons, and does not support complex value comparisons. Figure 1 For example, if you want to use the "TXN method" to implement rollback, you must compare the key values. Figure 1In the scenario shown, the key value is stored in JSON format on a specific core node. If ETCD node 1 crashes at this time and ETCD node 2 needs to roll back the version, ETCD node 2 needs to obtain the keys of the core node [primary] and the core node [standby] respectively to obtain the corresponding values, and then identify the version difference by comparing the values ​​corresponding to the keys, and then complete the rollback or recovery of the key value. Obviously, its interaction method is inefficient.

[0067] For another example, during the execution of an arbitration transaction, multiple interactions are required between core node 1 and ETCD node 1 to complete the arbitration. The feature of this function is that the transaction needs to be suspended during this period and wait for feedback from other application nodes. The "TXN method" cannot be implemented either.

[0068] Obviously, based on the above discussion, if the distributed key-value storage system in the prior art uses the "TXN method", its transaction function cannot provide a rollback or recovery mechanism based on transaction requests in application scenarios with multiple copies. In addition, since the "TXN method" mechanism is relatively simple, it cannot provide a customized value comparison mechanism to support the needs of complex logic in business scenarios.

[0069] Therefore, in order to solve the above problems, this solution provides a new transaction control mechanism based on a distributed key-value storage system. Specifically, Figure 2 A schematic diagram of the architecture of a distributed key-value storage system provided by an embodiment of the present invention, see Figure 2 , the architecture includes: ETCD node and core node 1. The ETCD node includes a business execution module, a transaction manager and storage.

[0070] The core logic of this architecture is to add a transaction manager. Every time a single transaction modifies a key value, it records the transaction number + the identification information of the storage node (such as the ETCD node mentioned above) + the historical version number to the target value of the key corresponding to the transaction request. At the same time, it maintains the transaction log corresponding to the target value in the [intermediate state].

[0071] Furthermore, when the current storage node crashes, if a transaction happens to be executed, the storage node that takes over can determine the key range that may have been modified based on the transaction log, and thereby determine whether the transaction number + identification information of these keys is consistent with the transaction log, and then restore the target value of the key based on the last version number of the key, thereby restoring to the state before the transaction is executed. This implements a target value based on the transaction request, and a transaction rollback or recovery mechanism.

[0072] The following is combined with the above Figure 2 The present application also provides a possible implementation of a transaction control method, specifically, Figure 3A flow chart of a transaction control method provided by an embodiment of the present invention is shown in FIG. Figure 3 , the method comprising:

[0073] Step 100: The transaction manager writes the transaction number and identification information for the transaction request.

[0074] The transaction request is sent by the core node; the transaction request includes the business type; the transaction number is used to uniquely identify the transaction request; and the identification information is used to mark the storage node (for example, ETCD node) to which the transaction manager belongs.

[0075] Step 102: The business execution module obtains a distributed lock according to the business type.

[0076] The distributed lock indicates that only one transaction process is allowed for the same business type. The distributed lock is used to ensure isolation requirements.

[0077] Step 104: The business execution module executes the transaction processing flow according to the transaction request, transaction number and identification information.

[0078] The identification information is used to identify the storage node to which the transaction manager belongs.

[0079] Step 105: When the transaction processing flow generates a modification of the key corresponding to the core node, the transaction manager writes the value to be updated into the target value of the key corresponding to the core node.

[0080] Optionally, the transaction processing flow here can be customized and extended, such as parsing the target value of the corresponding key of the core node, and then performing some logical processing, multiple service calls, etc.

[0081] Optionally, for the corresponding key of each core node, in this application, the target value of the corresponding key can be further subdivided, that is, the target value can include but is not limited to: the modification value (value1) generated in the transaction processing flow, the value of the transaction number (value2), the identification information and the value of the corresponding historical version number (value3). Therefore, correspondingly for step 105, the value to be updated includes: the value of the transaction number, the identification information and the value of the historical version number; the historical version number represents the version information of the last modification completed for the corresponding key of the corresponding core node.

[0082] The transaction control method provided by the embodiment of the present invention establishes an update mechanism for the corresponding key of the core node based on each transaction request. It involves establishing an association between the transaction number representing the transaction request and the identification information representing the storage node and the transaction request. In addition, the corresponding key of each core node in the present application has a more detailed value division granularity, which may involve the modification value generated in the transaction process, the value of the transaction number, the identification information, and the value of the historical version number. Combining the association design of the transaction request with the granularity design of the corresponding key, when there is a need for transaction recovery, it is possible to effectively determine the appropriate target value of the corresponding key of the core node to perform the corresponding recovery process, thereby realizing rollback or recovery for each transaction request.

[0083] Furthermore, since the embodiment of the present application provides that the values ​​of corresponding keys can be further divided and designed, values ​​related to extended transactions can be added. Therefore, when the transaction manager takes over the entire transaction life cycle, various limitations of the "TXN method" are broken to implement custom extended transaction functions.

[0084] Optional, in Figure 3 On the basis of Figure 4 A flow chart of a transaction control method provided by an embodiment of the present invention is shown in FIG. Figure 4 , after step 100, further comprising:

[0085] Step 101: The transaction manager stores the transaction request, transaction number and identification information in the transaction log.

[0086] Continue to see Figure 4 , after step 104, further comprising:

[0087] Step 106: When the transaction processing flow is not completed, the target value of the corresponding key of the core node is marked as an intermediate state.

[0088] Step 107: When the transaction processing flow is completed, the business execution module releases the distributed lock, and the target value of the corresponding key of the core node is marked as completed.

[0089] Step 108: The transaction manager deletes the transaction log corresponding to the transaction request.

[0090] Optionally, based on the introduction of the "transaction manager", this application also provides a possible implementation method for transaction recovery. Specifically, Figure 1 On the basis of Figure 5 A schematic diagram of an arbitration mechanism based on ETCD provided in an embodiment of the present invention, see Figure 5 , where each ETCD node includes: a business execution module, a transaction manager, and storage. At this time, if core node 1 initiates a transaction request, such as an arbitration-related transaction request. Figure 3 and Figure 4 In each step shown, the transaction manager of ETCD-1 completes the triggering of the business execution module and the update of the transaction log in the storage. At the same time, the transaction manager of ETCD-1 will synchronize the transaction manager of ETCD node 1 to the transaction manager of ETCD-2 so that it can synchronize the transaction log.

[0091] Furthermore, see above Figure 1 From the description, we can see that in a specific scenario, when ETCD-1 crashes while executing a transaction, when ETCD-2 takes over, for the "intermediate state", the existing transaction mechanism, namely the "TXN method", cannot implement a rollback mechanism based on transaction requests.

[0092] The following is an optional ETCD architecture diagram to illustrate the above Figure 4 and Figure 5 Specifically, Figure 6 A signaling interaction diagram of a transaction control method provided by an embodiment of the present invention, see Figure 6 In this example, core node 1 [master], core node 2 [standby], ETCD-1 [master], and ETCD-2 [standby] are involved; both ETCDs run their own transaction managers.

[0093] The following uses the arbitration transaction of core node 1 [Master] applying for master-slave node switching as an example to explain:

[0094] Step 1: Core node 1 [master] sends a transaction request to ETCD-1 [master]. The purpose of this transaction request is to arbitrate the master-slave switching of the core node.

[0095] Step 2: The transaction manager of ETCD-1 [Master] generates a transaction number corresponding to the transaction request.

[0096] Step 3: The transaction manager writes the transaction number and identification information for the transaction request.

[0097] Step 4: The business execution module of ETCD-1 [main] (not shown in the figure) obtains the distributed lock according to the business type.

[0098] Step 5: The business execution module executes the transaction processing flow according to the transaction request, transaction number and identification information.

[0099] Step 6: When the transaction processing flow generates a modification of the key corresponding to the core node, the transaction manager writes the value to be updated into the target value of the key corresponding to the core node.

[0100] Optionally, at this time, the modified value (value1), transaction number value (value2), identification information, and corresponding historical version number value (value3) generated in the transaction processing flow are written into the target value of the corresponding key of the core node to form a new target value, and marked with [intermediate state].

[0101] Among them, the "modification value generated in the transaction processing flow" may include relevant modifications to the corresponding application of the core node, such as the status of the application, the business sequence number, etc.

[0102] It should be noted that ETCD-1 [Master] will update the target value and transaction log to ETCD-2 [Standby] based on the synchronization mechanism with ETCD-2 [Standby], such as the Raft consensus algorithm. Correspondingly, ETCD-2 [Standby] maintains the target value [intermediate state] and transaction log.

[0103] Step 7, ETCD-1 [Master] sends the transaction processing results and arbitration results to core node 1 [Master].

[0104] Step 8. ETCD-1 [Master] sends the transaction processing result to core node 2 [Standby].

[0105] Furthermore, based on step 7 and step 8, core node 1 [master] and core node 2 [standby] perform a master-standby switching process.

[0106] If the switch is successful, in step 9-1, core node 2 is switched to be the master.

[0107] Step 10-1, core node 2 informs etcd-1 [master] of the switching result, that is, the switching is successful.

[0108] Optionally, at this time, the modified value (value1) generated in the transaction processing flow and the value of the corresponding historical version number (value3) are written into the target value of the corresponding key of the core node to form a new target value, and marked with [Completion Status]. It should be noted that the value of the historical version number is the value of the new version number corresponding to [Completion Status]. In addition, the value of the transaction number (value2) in step 6 remains unchanged.

[0109] Step 11-1: The business execution module releases the distributed lock.

[0110] Step 12-1: The transaction manager marks the target value as completed and deletes the transaction log corresponding to the transaction request.

[0111] In addition, the transaction manager of the ETCD-1 [primary] synchronizes the target value of the [completion status] to the transaction manager of the ETCD-2 [standby], maintains the target value [completion status], and deletes the corresponding transaction log.

[0112] Optionally, in another possible situation, the master-slave switching after the above arbitration may not be successful, and a possible implementation method is provided below to illustrate the signaling interaction involved.

[0113] Step 9-2: Switching of core node 2 fails.

[0114] Step 10-2, the transaction manager of ETCD-1 [Master] marks the target value as [Exit Status].

[0115] Optionally, for the transaction log corresponding to the transaction request, there are two possible operations: Operation 1: if arbitration is not to be performed again in the future, the transaction log is deleted; Operation 2: if arbitration is to be performed again in the future, the transaction log is not deleted.

[0116] Step 10-3: If arbitration is performed again, the signaling interaction processes from step 7 to step 11-2 are executed.

[0117] It should be noted that if the re-arbitration of step 10-3 does not clarify the result, then the [exit state] can be understood as an [intermediate state], and its maintenance mechanism for the transaction log and the target value is similar to that of the [intermediate state] in the above example. If the re-arbitration of step 10-3 clarifies the result, such as arbitration success or failure, then the [exit state] can be understood as a [completion state], and its maintenance mechanism for the transaction log and the target value is similar to that of the [completion state] in the above example.

[0118] In another possible implementation, continuing with the above arbitration transaction as an example, if there are multiple backup nodes in the core node, after triggering the arbitration-related signaling interaction, an election is also required to be conducted among the multiple backup nodes based on the election mechanism to determine the master node. Figure 6 On the basis of Figure 7 For another signaling interaction diagram of a transaction control method provided by an embodiment of the present invention, see Figure 7 In this architecture, core node 1 is the master node, and core node 2 and core node 3 are both standby nodes.

[0119] When core node 1 triggers the arbitration process, its signaling interaction process can be referred to Figure 6 Follow steps 1 to 8 in .

[0120] After ETCD-1 completes the arbitration, the arbitration result is synchronized to core nodes 2 and 3. At this time, the master node is selected through the election mechanism.

[0121] Based on the result of the election mechanism, the success or failure of the active / standby switch is confirmed. Figure 6 Step 9-1 to step 10-3.

[0122] exist Figure 7 The signaling interaction process shown still involves the modification of the target value, and its status can be marked from [intermediate status] to [complete status] or [exit status]. In order to maintain data consistency, the transaction log corresponding to the target value and the transaction request will be synchronized between ETCD-1 and ETCD-2.

[0123] In addition, it should be noted that for the [intermediate state], [complete state] and [exit state] described in the examples of this application. A possible implementation method is: to reflect it using the modification value (value1) generated in the above transaction processing flow. For example, the modification value can represent the application state. If the application state is "to host" or "to standby", it represents the [intermediate state]; if the application state is "host" or "standby", it represents the [complete state]. For the [exit state], if the application state is "to exit", the [exit state] represents a special [intermediate state], and if the application state is "exit", the [exit state] represents a special [complete state].

[0124] Combine the following Figure 5 , an exemplary description is given of how the present application implements a rollback mechanism based on transaction requests based on a "transaction manager", specifically, Figure 8 A flow chart of another transaction control method provided by an embodiment of the present invention is shown in FIG. Figure 8 , the execution subject may be, when the ETCD node 1 as the main storage node crashes, the ETCD node 2 that takes over the transaction. The method includes:

[0125] Step 108: If the active / standby switching condition is triggered, the transaction manager traverses the transaction log to determine the key set of the key corresponding to the core node that has changed.

[0126] in, Figure 8 The transaction manager described is a transaction manager deployed on ETCD node 2. Optionally, the key set of the key corresponding to the changed core node is determined through the business logic corresponding to the transaction log.

[0127] Specifically, for clusters, the cluster name can be used as part of the key value to distinguish the core nodes of different clusters. The application name or product name is used to identify a specific application or product, which can be used as a prefix or part of the key value to distinguish the core nodes of different applications or products. Therefore, the key value can adopt a hierarchical structure: cluster name / application name / core node corresponding key (node ​​ID). Therefore, for business logic, it can include the above cluster name / application name to determine a specific core node. Then, based on the core node corresponding key, the above key set is determined.

[0128] Step 109: The transaction manager reads the current transaction number and current identification information of each corresponding key in the key set one by one.

[0129] Step 110: Determine whether there is a transaction number identical to the current transaction number in the transaction log, and whether there is identification information identical to the current identification information.

[0130] If both exist, then execute step 111 ; if at least one does not exist, then execute step 112 .

[0131] Step 111: Restore the target value of the corresponding key according to the version information of the last modification.

[0132] The version information of the last completed modification is stored in the target value of the corresponding key. Moreover, the “last completed modification” refers to the target value marked as [Completed Status] at the time of the last modification.

[0133] Step 112: Determine whether the transaction number and identification information contained in the transaction log have been traversed.

[0134] If the traversal is completed, step 113 is executed; if the traversal is not completed, the process returns to step 109 for execution.

[0135] Step 113: Re-execute the transaction according to the restored target value of the corresponding key.

[0136] For example, the arbitration request was originally executed by ETCD-1. At this time, based on the target value of the historical version number before ETCD-1 modified the relevant target value, ETCD-2 re-executes the arbitration transaction. Figure 8 The implementation method for recovering the target value and transaction shown in FIG. 1 illustrates the signaling interaction involved. Specifically, in Figure 6 On the basis of Fig. 9 For another signaling interaction diagram of a transaction control method provided by an embodiment of the present invention, see Fig. 9 , whose architecture includes core node 1, core node 2, ETCD-1, ETCD-2 and ETCD-3.

[0137] Among them, core node 1 is the master node, core node 2 is the standby node, ETCD-1 is the master node, and ETCD-2 and ETCD-3 are standby nodes.

[0138] See previous article Figure 6 In the example shown, if core node 1 initiates a transaction request, such as an arbitration request, the architecture is based on Figure 6 The signaling interaction method shown performs steps 1 to 8 in the transaction execution process.

[0139] Furthermore, in one case, the target value associated with the transaction request is in an intermediate state, and Fig. 9 The ETCD-2 described in the maintains the target value of the intermediate state and the transaction log corresponding to the transaction request.

[0140] At this time, if the ETCD node switches between the master and the standby nodes, for example, ETCD-2 becomes the new master node, then step 13 is executed, and ETCD-1 and ETCD-2 perform master-standby switching synchronization.

[0141] However, since the transaction results of steps 1 to 8 are not clear, for example Figure 6 , Figure 7 The arbitration transaction involved in the transaction request has not obtained a result. At this time, the target value related to the transaction request is in an intermediate state. At this time, in order to ensure data consistency, it is necessary to roll back the target value of the transaction request. However, the "TXN method" in the prior art does not provide a mechanism for establishing a corresponding transaction log for a "transaction request", and thus cannot achieve rollback or recovery of the target value at the granularity of a "transaction request".

[0142] Therefore, in this application, since the transaction log can predict in advance whether the target value of a transaction request is in an intermediate state, when the target value needs to be restored, for example Fig. 9 As shown in the figure, when ETCD-1 and ETCD-2 perform active-standby switching, the target values ​​that need to be restored can be determined by traversing the transaction log.

[0143] Specifically, as in step 14, the transaction manager of etcd-2 determines whether a transaction log exists.

[0144] Step 15: If a transaction log exists, the transaction manager further traverses the transaction log to determine the key set corresponding to the key of the core node that has changed.

[0145] Specifically, the transaction manager further traverses the transaction log, and determines the key set of the key corresponding to the changed core node through the business logic corresponding to the transaction log.

[0146] Step 16: After the transaction log traversal is completed, the transaction recovery is performed according to the target value of the corresponding key after recovery, and the current transaction number and current identification information of each corresponding key in the key set are read one by one.

[0147] Specifically, for each corresponding key, since its corresponding target value includes the value of the transaction number and identification information, it is determined whether the current transaction number and identification information are consistent with the transaction number and identification information in the transaction log. If they are consistent, it means that the target value maintained in the transaction log is the same as the target value of the corresponding key, that is, the target value is in an intermediate state.

[0148] For example, if the target value of the key corresponding to core node 1 is modified during the arbitration transaction in steps 1 to 8, then the key corresponding to the core node has changed, that is, the target value of the key corresponding to core node 1 may need to be restored.

[0149] Step 17: If the transaction number and identification information are consistent, the version information that was modified last time is restored to the target value of the corresponding key.

[0150] Specifically, when the transaction number and identification information are consistent, the target value is the [intermediate state]. Therefore, it is necessary to determine the target value that was in the [completed state] last time based on the version information, and restore the target value in the [intermediate state] to the target value that was in the [completed state] last time to complete the recovery of the target value, thereby ensuring the consistency of the target values ​​on different ETCD nodes.

[0151] After completing the recovery of each target value, the transaction is recovered based on the target value of each [Completion Status].

[0152] That is, in step 18, after the transaction log traversal is completed, the transaction is recovered according to the target value of the corresponding key after recovery.

[0153] Optionally, step 18 may be performed by the service execution module of ETCD-2.

[0154] It should be noted that for scenarios involving multiple ETCD nodes, such as Fig. 9 As shown in ETCD-1, ETCD-2 and ETCD-3, when the target value and transaction log of any ETCD node change, the ETCD node synchronization mechanism can be used to synchronize information on other ETCD nodes to maintain data consistency.

[0155] Optionally, the present application also provides a transaction control device, which has executed each step of the above example to achieve the corresponding technical effect. Specifically, Fig.10 A schematic diagram of a transaction control device provided by an embodiment of the present invention is shown in FIG. Fig.10 The device 20 includes: a transaction manager 200 and a service execution module 201.

[0156] The transaction manager 200 is used to write the transaction number and identification information for the transaction request; the transaction request is sent by the core node.

[0157] The business execution module 201 is used to obtain a distributed lock according to the business type, where the distributed lock indicates that only one transaction processing flow is allowed for the same business type; and execute the transaction processing flow according to the transaction request, transaction number and identification information.

[0158] When the transaction processing flow generates a modification of the key corresponding to the core node, the transaction manager 200 is also used to write the value to be updated into the target value of the key corresponding to the core node.

[0159] Optionally, the transaction manager 200 is further configured to store the transaction request in a corresponding transaction log.

[0160] Optionally, the transaction manager 200 is further used to mark the target value of the corresponding key of the core node as an intermediate state when the transaction processing flow is not completed.

[0161] Optionally, the business execution module is also used to release the distributed lock after the transaction processing process is completed;

[0162] The transaction manager 200 is further used to mark the target value of the key corresponding to the core node as a completed state; and delete the transaction log corresponding to the transaction request.

[0163] Optionally, the storage node to which the transaction manager 200 belongs is a backup node; the transaction manager 200 is also used to traverse the transaction log if the master-slave switching condition is triggered, determine the key set of the corresponding keys of the core node that has changed; read the current transaction number and current identification information of each corresponding key in the key set one by one; determine whether there is a transaction number identical to the current transaction number, and whether there is identification information identical to the current identification information in the transaction log; if both exist, restore the target value of the corresponding key according to the version information of the last completed modification contained in the target value of the corresponding key.

[0164] Optionally, the transaction manager 200 is also used to determine whether the transaction number and identification information contained in the transaction log have been traversed if at least one does not exist; if the traversal is completed, the transaction is recovered according to the target value of the corresponding key after recovery; if the traversal is not completed, it returns to execute the step of reading the current transaction number and current identification information of each corresponding key in the key set one by one.

[0165] The embodiment of the invention further provides an electronic device, which can execute all the steps of the above examples of the embodiment of the invention to achieve the corresponding technical effects. Specifically, Fig.11 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, see Fig.11 , the electronic device 50, comprises: a memory 501, a processor 500;

[0166] Memory 501, used to store one or more programs;

[0167] Processor 500;

[0168] When one or more programs are executed by the processor, when the electronic device 50 is used to execute the steps shown in the above-mentioned method examples, it can achieve each step and the corresponding technical effects.

[0169] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and a part of the module, program segment or code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes 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 box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0170] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0171] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a program product, which is stored in a computer-readable storage medium and includes a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program codes.

[0172] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

[0173] It will be apparent to those skilled in the art that the present application is not limited to the details of the exemplary embodiments described above, and that the present application can be implemented in other specific forms without departing from the spirit or essential features of the present application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims be included in the present application. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

Claims

1. A transaction control method, characterized in that: The transaction control method is executed by a storage node, and the storage node includes: a transaction manager and a service execution module; the method includes: The transaction manager writes a transaction number and identification information for a transaction request; the transaction request is sent by a core node; the transaction request includes a business type; the transaction number is used to uniquely identify the transaction request; the identification information is used to identify the storage node to which the transaction manager belongs; The business execution module acquires a distributed lock according to the business type, and the distributed lock indicates that only one transaction processing flow is allowed for the same business type; The service execution module executes the transaction processing flow according to the transaction request, the transaction number and the identification information; When the transaction processing flow generates a modification of the corresponding key of the core node, the transaction manager writes the value to be updated into the target value of the corresponding key of the core node; the value to be updated includes: the value of the transaction number, the identification information and the value of the historical version number; the historical version number represents the version information of the last modification completed for the corresponding key of the core node; the target value is synchronized through the transaction managers of different storage nodes.

2. The method according to claim 1, characterized in that After the transaction manager writes the transaction number and identification information for the transaction request, the method further includes: The transaction manager stores the transaction request in a corresponding transaction log.

3. The method according to claim 2, characterized in that After the step of the transaction manager writing the value to be updated into the target value of the corresponding key of the core node when the transaction processing flow generates a modified value, the step further includes: When the transaction processing flow is not completed, the target value of the corresponding key of the core node is marked as an intermediate state.

4. The method according to claim 2, characterized in that: After the step of the transaction manager writing the value to be updated into the target value of the corresponding key of the core node when the transaction processing flow generates a modified value, the step further includes: When the transaction processing flow is completed, the business execution module releases the distributed lock; and the target value of the corresponding key of the core node is marked as completed; The transaction manager deletes the transaction log corresponding to the transaction request.

5. The method according to claim 3, characterized in that: The storage node to which the transaction manager belongs is a backup node; the method further comprises: If the master-slave switching condition is triggered, the transaction manager traverses the transaction log to determine the key set of the corresponding key of the core node that has changed; The transaction manager reads the current transaction number and current identification information of each corresponding key in the key set one by one; Determine whether there is a transaction number identical to the current transaction number in the transaction log, and whether there is identification information identical to the current identification information; If both exist, the target value of the corresponding key is restored according to the version information of the last modification included in the target value of the corresponding key.

6. The method according to claim 5, characterized in that If at least one does not exist, determining whether the transaction number and identification information contained in the transaction log have been traversed; If the traversal is completed, the transaction is restored according to the target value of the corresponding key after recovery; If the traversal is not completed, the process returns to the step of executing the transaction manager to read the current transaction number and the current identification information of each corresponding key in the key set one by one.

7. A transaction control device, characterized in that: The transaction control device is deployed on a storage node, and includes: a transaction manager and a service execution module; The transaction manager is used to write a transaction number and identification information for a transaction request; the transaction request is sent by a core node; the transaction request includes a business type; the transaction number is used to uniquely identify the transaction request; the identification information is used to identify the storage node to which the transaction manager belongs; The business execution module is used to obtain a distributed lock according to the business type, wherein the distributed lock indicates that only one transaction processing flow is allowed for the same business type; and execute the transaction processing flow according to the transaction request, the transaction number and the identification information; When the transaction processing flow generates a modification of the corresponding key of the core node, the transaction manager is also used to write the value to be updated into the target value of the corresponding key of the core node; the value to be updated includes: the value of the transaction number, the identification information and the value of the historical version number; the historical version number represents the version information of the last modification completed for the corresponding key of the core node; the target value is synchronized through the transaction managers of different storage nodes.

8. An electronic device, characterized in that: include: A memory for storing one or more programs; processor; When the one or more programs are executed by the processor, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A program product, characterized in that When the program product is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images