CN115495205B - Method and device for realizing data consistency based on distributed transaction lock - Google Patents
Method and device for realizing data consistency based on distributed transaction lock Download PDFInfo
- Publication number
- CN115495205B CN115495205B CN202211353874.6A CN202211353874A CN115495205B CN 115495205 B CN115495205 B CN 115495205B CN 202211353874 A CN202211353874 A CN 202211353874A CN 115495205 B CN115495205 B CN 115495205B
- Authority
- CN
- China
- Prior art keywords
- transaction
- state
- execution
- sub
- lock
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
Abstract
The invention discloses a method and a device for realizing data consistency based on a distributed transaction lock, wherein the method comprises the following steps: initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction; determining a distributed transaction execution scheme according to the transaction execution queue, updating the transaction state of the transaction global state lock of the target transaction in real time while executing the distributed transaction execution scheme, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not; if yes, executing the submission operation of the target transaction; and if not, executing the rollback operation of the target transaction. The distributed system ensures data consistency, realizes low resource deployment, reduces memory loss, realizes the ACID principle of transactions by monitoring the transaction lock in the global state in real time, and ensures that the system has higher fault-tolerant capability.
Description
Technical Field
The invention relates to the technical field of distributed transaction lock management, in particular to a method and a device for realizing data consistency based on a distributed transaction lock.
Background
Micro-service architecture has become the mainstream technology of large-scale distributed architecture, and is a new technology for deploying applications and services in the cloud. Microservices can run in 'own programs' and communicate with an HTTP type API through 'lightweight equipment'; in the microservice architecture, only the required functions need to be added in a specific certain service, and the architecture of the whole process is not influenced. The large data system based on the micro-service architecture mostly adopts a distributed architecture, i.e. different service logic modules are split into different server clusters in a decoupling mode, so that the distributed architecture is realized, and the resource expansion and maintenance are facilitated.
Since the distributed architecture based on microservices needs to span multiple services, the traditional transaction execution cannot guarantee data consistency, and the problem of transaction data consistency is generated. At present, commonly used distributed transaction consistency solutions include a 2PC (two-phase commit) scheme and a 3PC (three-phase commit) scheme, however, the two schemes are suitable for traditional monolithic applications, and in a micro-service distributed architecture, data consistency is difficult to guarantee due to the fact that data is in a strong consistency relationship, so that the two schemes are not suitable for the micro-service architecture. On the other hand, in the method adopting the Spring Cloud Aliba distributed architecture, because the sea transaction management component is too large and needs to depend on a plurality of packets, although the write isolation and the read isolation are realized based on the global lock, other problems are brought, for example, the original project only needs a small part of functions and needs to use the distributed transaction, but because a certain table introduces the sea control transaction, all the related programs need to add the sea transaction. There is some performance loss in sea itself, which will significantly compromise the performance of the whole program.
Therefore, a new method applied to the micro-service distributed architecture is needed to solve the above problems.
Disclosure of Invention
In view of this, it is necessary to provide a method, an apparatus, an electronic device, and a storage medium for implementing data consistency based on a distributed transaction lock, so that resource deployment can be reduced on the premise of ensuring data consistency in a micro-service distributed architecture.
In order to solve the technical problems, the invention adopts the following technical scheme:
in a first aspect, the present invention provides a method for implementing data consistency based on a distributed transaction lock, including:
initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction;
determining a distributed transaction execution scheme according to the transaction execution queue, updating the transaction state of the transaction global state lock of the target transaction in real time while executing the distributed transaction execution scheme, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not;
if yes, executing the submission operation of the target transaction;
if not, executing the rollback operation of the target transaction.
In some embodiments, initializing a transaction global state lock includes:
and creating a transaction global state lock, and initializing the transaction state of the transaction global state lock corresponding to the target transaction to be a starting state.
In some embodiments, the distributed transactional execution scheme includes a plurality of sub-schemes; the method for updating the transaction state of the transaction global state lock of the target transaction in real time while executing the distributed transaction execution scheme and judging whether the updated transaction state of the transaction global state lock is a normal execution state comprises the following steps:
respectively starting the execution processes of the plurality of sub-schemes according to the queue sequence of the transaction execution queue;
judging the transaction state of the transaction global state lock of any one sub-scheme before the transaction is executed, wherein the global transaction state comprises a normal execution state, an error state and a starting state;
if the transaction state of the transaction global state lock is a normal execution state and the execution process is not overtime, executing any one of the sub-schemes;
and if the transaction state of the transaction global state lock is an error state, terminating the execution of any one of the sub-schemes and performing rollback operation on the sub-scheme.
In some embodiments, the executing process of the distributed transaction executing scheme includes a pre-executing process, a waiting process, and a committing process, and if the transaction state of the transaction global state lock is a normal executing state and the executing process is not timed out, the executing any one of the sub-schemes includes:
judging whether the pre-execution process of any one of the sub-schemes is correct or not;
if the transaction state is wrong, resetting the transaction state to be a wrong state;
if the sub-scheme is correct, judging whether the any sub-scheme is the last sub-scheme in the queue sequence of the transaction execution queue;
if not, switching the pre-execution process of any one of the sub-schemes into a waiting process;
if yes, switching the pre-execution process of any one of the sub-schemes to a submission process, and resetting the transaction state of the global transaction state lock to a normal execution state.
In some embodiments, while the execution processes of the plurality of sub-schemes are respectively started according to the queue order of the transaction execution queue, a startup daemon monitors the execution processes of the plurality of sub-schemes so as to obtain the transaction state of the transaction global lock and the commit and rollback operations of the single-node transaction executing the transaction process in real time.
In some embodiments, the monitoring of the execution of the plurality of sub-solutions by the start daemon comprises:
judging whether any one of the sub-schemes is overtime in the transaction execution process;
if yes, destroying the daemon program and performing rollback operation on any sub scheme;
if not, judging the transaction state corresponding to the transaction global state lock;
if the transaction state is an error state, destroying the daemon program and performing rollback operation on any one of the sub-schemes;
if the transaction state is a normal execution state, judging whether the execution process of any one of the sub-schemes is consistent with the submission sequence of the submission queue;
if the sub-schemes are consistent, performing submission operation on the sub-schemes according to the submission queue;
if not, pausing the daemon within a set time, and restarting the daemon after the set time is reached until the execution process of the current sub-scheme is consistent with the submission queue.
In some embodiments, when the execution of the predetermined distributed transaction execution scheme is completed, the transaction global state lock is ended.
In a second aspect, the present invention further provides an apparatus for implementing data consistency based on a distributed transaction lock, including:
the initialization module is used for initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction;
the transaction execution module is used for executing a preset distributed transaction execution scheme, updating the transaction state of the transaction global state lock of the target transaction in real time, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not;
the transaction submitting module is used for executing the submitting operation of the target transaction when the transaction state of the transaction global state lock is a normal execution state;
and the rollback module is used for executing the rollback operation of the target transaction according to the condition that the transaction state of the transaction global state lock is not a normal execution state.
In a third aspect, the present invention further provides an electronic device, including: a processor and a memory;
the memory has stored thereon a computer readable program executable by the processor;
the processor, when executing the computer readable program, implements the steps in the method for implementing data consistency based on distributed transactional locks as described above.
In a fourth aspect, the present invention also provides a computer readable storage medium storing one or more programs, which are executable by one or more processors to implement the steps in the method for implementing data consistency based on distributed transactional locks as described above.
Compared with the prior art, the method, the device, the electronic equipment and the storage medium for realizing data consistency based on the distributed transaction lock provided by the invention have the advantages that by carrying out initialization operation on a target transaction, an execution queue, a commit queue and a transaction global state lock are determined, a distributed transaction execution scheme is determined according to the transaction execution queue, the transaction state of the transaction global state lock of the target transaction is updated in real time while the distributed transaction execution scheme is executed, whether the updated transaction state of the transaction global state lock is a normal execution state or not is judged, when the transaction state of the transaction global state lock is the normal execution state, the commit operation of the target transaction is executed, and when the transaction state of the transaction global state lock is not the normal execution state, the rollback operation of the target transaction is executed; the invention carries out global monitoring on the execution process of the transaction by setting the transaction global state lock, updates the state of the transaction in real time so as to realize rollback or commit operation of the transaction, ensures data consistency, simultaneously realizes low resource deployment, reduces memory loss, simultaneously realizes the ACID principle of the transaction by monitoring the global state transaction lock in real time, and ensures that the system has higher fault-tolerant capability.
Drawings
FIG. 1 is a flow diagram of one embodiment of a method for achieving data consistency based on distributed transactional locks;
FIG. 2 is a flowchart of an embodiment of step S102 in the method for implementing data consistency based on distributed transaction locks according to the present invention;
FIG. 3 is a flowchart of an embodiment of step S203 in the method for implementing data consistency based on distributed transaction locks according to the present invention;
FIG. 4 is a diagram illustrating an embodiment of a daemon process in the method for implementing data consistency based on a distributed transaction lock according to the present invention;
FIG. 5 is a diagram illustrating an embodiment of an apparatus for implementing data consistency based on a distributed transaction lock according to the present invention;
fig. 6 is a schematic operating environment diagram of an embodiment of an electronic device provided in the present invention.
Detailed Description
The accompanying drawings, which are incorporated in and constitute a part of this application, illustrate preferred embodiments of the invention and together with the description, serve to explain the principles of the invention and not to limit the scope of the invention.
In the description of the present invention, the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the feature. Further, "plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Reference throughout this specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present invention. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the described embodiments can be combined with other embodiments.
First, the terms related to the present invention will be explained:
micro-service: a variation of software development technology, service Oriented Architecture (SOA) architectural style, calls for partitioning a single application into a set of small services that are coordinated and interworked to provide ultimate value to the user. Each service runs in its own independent process, and the services communicate with each other by adopting a lightweight communication mechanism (usually, HTTP-based RESTful API). Each service is built around a specific business and can be deployed independently to a production environment, a production-like environment, and the like. In addition, a unified and centralized service management mechanism should be avoided as much as possible, and for a specific service, a proper language and a proper tool should be selected to construct the service according to the context;
distributed transaction lock: the distributed transaction means that a participant of the transaction, a server supporting the transaction, a resource server and a transaction manager are respectively positioned on different nodes of different distributed systems.
ACID: the method refers to four characteristics that a database management system (DBMS) must have in order to ensure that a transaction (transaction) is correct and reliable in the process of writing or updating data: atomicity (or indivisible), consistency (consistency), isolation (or independence), persistence (persistence).
In a distributed transaction, if data in multiple machines deployed in a distributed manner is desired to be consistent, then it is guaranteed that data writes at all nodes are either all performed or none performed. However, one machine cannot know the execution result of the local transaction in the other machine when executing the local transaction, and the node does not know whether the transaction should be committed (Commit) or rolled back (Rollback) at all. In order to ensure data consistency of distributed transaction execution, at present, for 2PC and 3PC schemes in a data consistency solution, under some extreme conditions, a problem of data inconsistency still occurs, that is, after a commit command is sent by a coordinating node, when the coordinating node and a data node fail and recover simultaneously, it is assumed that 10 data nodes are involved in transactions in total, one of the data nodes does not execute a local transaction commit operation when being down, and the other 9 data nodes execute the local transaction commit operation, and after the coordinating node and the data node recover, the coordinating node does not know whether each data node executes the commit operation or not, and needs to roll back to cancel the transaction, so as to send a roll back command to each data node.
In order to solve the technical problem of data inconsistency caused by fault recovery of a coordination node and a data node, the embodiment of the application provides a method, a device, an electronic device and a storage medium for realizing data consistency based on a distributed transaction lock on the basis of not changing an original architecture, and based on transaction management under a micro service architecture scene, maintenance and update of a transaction state and maintenance of a transaction execution queue are realized mainly through a memory database (Redis). When the execution process of the transaction starts, a transaction execution queue and a transaction state are generated according to a calling sequence, timeout time is obtained, and initialization execution parameters are put into a memory database (Redis) to realize transaction initialization. And in the transaction execution stage, the corresponding methods are executed according to the execution sequence, so that the method is pre-submitted, and after the execution is finished, the daemon process submits the methods or rolls back the transactions, so that the data consistency is realized. Referring to fig. 1, fig. 1 is a flowchart of an embodiment of a method for implementing data consistency based on a distributed transaction lock according to the present invention, which specifically includes:
s101, initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction;
s102, determining a distributed transaction execution scheme according to the transaction execution queue, executing the distributed transaction execution scheme, updating the transaction state of a transaction global state lock of the target transaction in real time, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not;
s103, if yes, executing the submitting operation of the target transaction;
and S104, if not, executing the rollback operation of the target transaction.
The method, the device, the electronic device and the storage medium for realizing data consistency based on the distributed transaction lock, provided by the embodiment of the invention, are used for determining an execution queue, a commit queue and a transaction global state lock by performing initialization operation on a target transaction, updating the transaction state of the transaction global state lock of the target transaction in real time while executing a preset distributed transaction execution scheme, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not, when the transaction state of the transaction global state lock is the normal execution state, executing the commit operation of the target transaction, and when the transaction state of the transaction global state lock is not the normal execution state, executing the rollback operation of the target transaction; the invention carries out global monitoring on the execution process of the transaction by setting the transaction global state lock, updates the state of the transaction in real time so as to realize rollback or commit operation of the transaction, ensures the data consistency, simultaneously realizes low resource deployment, reduces the memory loss, simultaneously realizes the ACID principle of the transaction by monitoring the global state transaction lock in real time, and ensures that the system has higher fault-tolerant capability.
It should be noted that the transaction execution queue is an order arrangement condition of the transaction execution, and the transaction commit queue is a commit arrangement condition after the transaction execution is completed.
In some embodiments, initializing a transaction global state lock includes:
and creating a transaction global state lock, and initializing the transaction state of the transaction global state lock corresponding to the target transaction to be a starting state.
In this embodiment, the transaction state of the transaction global state lock is initialized, the transaction state of the transaction global state lock is updated in real time according to the transaction execution process, and whether the execution process is normal is determined according to the transaction state, so that the submission or rollback of the transaction is determined according to the real-time transaction state.
In some embodiments, referring to FIG. 2, the distributed transactional execution scheme includes a plurality of sub-schemes; the executing the distributed transaction executing scheme and simultaneously updating the transaction state of the transaction global state lock of the target transaction in real time, and judging whether the updated transaction state of the transaction global state lock is a normal executing state or not, including:
s201, respectively starting the execution processes of the plurality of sub-schemes according to the queue sequence of the transaction execution queue;
s202, judging the transaction state of the transaction global state lock of any one sub-scheme before the transaction is executed, wherein the global transaction state comprises a normal execution state, an error state and a starting state;
s203, if the transaction state of the transaction global state lock is a normal execution state and the execution process is not overtime, executing any one of the sub-schemes;
s204, if the transaction state of the transaction global state lock is an error state, terminating the execution of any one of the sub-schemes, and performing rollback operation on the sub-scheme.
In this embodiment, a target transaction is initialized, after determining a commit queue, an execution queue, and a global state transaction lock, an execution scheme may be started, and sub-schemes in the scheme may be started to be executed according to the transaction queue, and when execution starts, whether an execution process can continue is determined by performing double monitoring on a timeout time and the global state transaction lock, if a starting state corresponding to any executed sub-method does not appear timeout, any sub-method is executed, and a subsequent execution process is monitored by continuously monitoring the global transaction state, and if an error state appears or the timeout time appears timeout, data is quickly rolled back.
It should be noted that, in order to prevent uncertainty of the call time caused by various uncertainty factors, a timeout time is set to implement a quick failure, release resources, implement a quick response of an erroneous call, rollback data, and improve a system response speed.
In some embodiments, referring to fig. 3, the executing process of the distributed transaction executing scheme includes a pre-executing process, a waiting process, and a committing process, and if the transaction state of the transaction global state lock is a normal executing state and the executing process is not timed out, the executing any one of the sub-schemes includes:
s301, judging whether the pre-execution process of any one sub-scheme is correct or not;
s302, if the transaction state is wrong, resetting the transaction state to be a wrong state;
s303, if the sub-scheme is correct, judging whether the any sub-scheme is the last sub-scheme in the queue sequence of the transaction execution queue;
s304, if not, switching the pre-execution process of any one of the sub-schemes to a waiting process;
s305, if yes, switching the pre-execution process of any one of the sub-schemes to a submission process, and resetting the transaction state of the global transaction state lock to a normal execution state.
In this embodiment, after one node completes execution and commits in the execution process of a transaction, if data of a subsequent node is wrong, the whole transaction needs to be rolled back, but the committed result of the previous node cannot be reversed, which may cause inconsistency of the data; therefore, in order to ensure that when an error occurs in a certain node of the transaction, the transaction can still roll back as a whole, the transaction execution process is set as a pre-execution process, a waiting process and a submission process, wherein the pre-execution process is a step required to be performed before submission in the transaction execution process, when the waiting process is that the current node completes the pre-execution process and is not the last node of the execution queue, the waiting process is entered into the waiting process, the follow-up node completes the pre-execution process and is not in error, then the process is switched to the submission process according to the submission queue, and the submission process is that the transaction is submitted according to the submission queue.
In some embodiments, while the execution processes of the plurality of sub-schemes are respectively started according to the queue order of the transaction execution queue, a startup daemon monitors the execution processes of the plurality of sub-schemes so as to obtain the transaction state of the transaction global lock and the commit and rollback operations of the single-node transaction executing the transaction process in real time.
In the embodiment, the method transaction is monitored in real time through a daemon process, and the submission or rollback of the transaction is guided; each service method daemon realizes the monitoring and management of the method affairs through an injection mode (annotating or binding affairs on slices).
In some embodiments, referring to fig. 4, the monitoring of the execution of the plurality of sub-solutions by the start daemon includes:
s401, judging whether any one of the sub-schemes is overtime in the transaction execution process;
s402, if the sub-scheme is overtime, destroying the daemon and performing rollback operation on the sub-scheme;
s403, if the time is not overtime, the transaction state of the transaction global state lock is judged;
s404, if the transaction state is an error state, destroying the daemon program and performing rollback operation on the sub-scheme;
s405, if the transaction state is a normal execution state, judging whether the execution process of the sub-scheme is consistent with the submission sequence of the transaction submission queue;
s406, if the sub-schemes are consistent, performing a commit operation on the sub-schemes according to the transaction commit queue;
s407, if the sub-schemes are not consistent, pausing the daemon within a set time, and restarting the daemon after the set time is reached until the execution process of the sub-schemes is consistent with the submission queue.
In this embodiment, in step S401, judging whether any of the sub-schemes is overtime in the transaction execution process, specifically, setting a total execution duration for the transaction execution process, and if the total execution duration is exceeded, performing a rollback operation on the transaction.
In some embodiments, the transaction global state lock is ended when all of the distributed transactions have completed execution.
In this embodiment, after the execution of the preset distributed transaction execution scheme is completed, the transaction global state lock is ended, that is, the transaction state lock has completed its protection work on the transaction process.
Based on the method for implementing data consistency based on the distributed transaction lock, an embodiment of the present invention further provides a device 500 for implementing data consistency based on the distributed transaction lock, please refer to fig. 5, where the device 500 for implementing data consistency based on the distributed transaction lock includes an initialization module 510, a transaction execution module 520, a monitoring module 530, a transaction commit module 540, and a rollback module 550;
an initialization module 510, configured to initialize a transaction execution queue, a transaction commit queue, and a transaction global state lock of a target transaction;
the transaction execution module 520 is configured to execute a preset distributed transaction execution scheme, update the transaction state of the transaction global state lock of the target transaction in real time, and determine whether the updated transaction state of the transaction global state lock is a normal execution state;
a transaction commit module 530, configured to execute a commit operation of the target transaction when the transaction state of the transaction global state lock is a normal execution state;
and a rollback module 540, configured to execute a rollback operation of the target transaction according to that the transaction state of the transaction global state lock is not a normal execution state.
In this embodiment, an execution queue, a commit queue, and a transaction global state lock are determined by performing an initialization operation on a target transaction, and are configured to execute a preset distributed transaction execution scheme, update a transaction state of the transaction global state lock of the target transaction in real time, and determine whether the updated transaction state of the transaction global state lock is a normal execution state, execute a commit operation of the target transaction when the transaction state of the transaction global state lock is the normal execution state, and execute a rollback operation of the target transaction when the transaction state of the transaction global state lock is not the normal execution state; the invention carries out global monitoring on the execution process of the transaction by setting the transaction global state lock, updates the state of the transaction in real time so as to realize rollback or commit operation of the transaction, ensures the data consistency, simultaneously realizes low resource deployment, reduces the memory loss, simultaneously realizes the ACID principle of the transaction by monitoring the global state transaction lock in real time, and ensures that the system has higher fault-tolerant capability.
As shown in fig. 6, based on the method for implementing data consistency based on the distributed transaction lock, the present invention also provides an electronic device, which may be a mobile terminal, a desktop computer, a notebook computer, a palmtop computer, a server, or other computing devices. The electronic device includes a processor 610, a memory 620, and a display 630. Fig. 6 shows only some of the components of the electronic device, but it is to be understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead.
The storage 620 may in some embodiments be an internal storage unit of the electronic device, such as a hard disk or a memory of the electronic device. The memory 620 may also be an external storage device of the electronic device in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), etc. provided on the electronic device. Further, the memory 620 may also include both internal storage units of the electronic device and external storage devices. The memory 620 is used for storing application software installed in the electronic device and various data, such as program codes for installing the electronic device. The memory 620 may also be used to temporarily store data that has been output or is to be output. In an embodiment, the memory 620 stores a program 640 for implementing data consistency based on a distributed transaction lock, and the program 640 for implementing data consistency based on a distributed transaction lock can be executed by the processor 610, so as to implement the method for implementing data consistency based on a distributed transaction lock according to the embodiments of the present application.
The display 630 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch panel, or the like in some embodiments. The display 630 is used for displaying information of the device for realizing data consistency based on the distributed transaction lock and displaying a visualized user interface. The components 610-630 of the electronic device communicate with each other via a system bus.
Of course, it will be understood by those skilled in the art that all or part of the processes of the methods of the above embodiments may be implemented by a computer program instructing relevant hardware (such as a processor, a controller, etc.), and the program may be stored in a computer readable storage medium, and when executed, the program may include the processes of the above method embodiments. The storage medium may be a memory, a magnetic disk, an optical disk, etc.
The above-described embodiments of the present invention should not be construed as limiting the scope of the present invention. Any other corresponding changes and modifications made according to the technical idea of the present invention should be included in the protection scope of the claims of the present invention.
Claims (8)
1. A method for realizing data consistency based on distributed transaction lock is applied to the realization of interactive data consistency between a lightweight device and an HTTP type API under a micro-service architecture, and is characterized by comprising the following steps:
initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction;
determining a distributed transaction execution scheme according to the transaction execution queue, wherein the execution process of the distributed transaction execution scheme comprises a pre-execution process, a waiting process and a submission process;
updating the transaction state of the transaction global state lock of the target transaction in real time while executing the distributed transaction execution scheme, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not; the distributed transaction execution scheme comprises a plurality of sub-schemes, and the execution processes of the sub-schemes are respectively started according to the queue sequence of the transaction execution queue; judging the transaction state of the transaction global state lock of any one sub-scheme before the transaction is executed, wherein the transaction state comprises a normal execution state, an error state and a starting state; if the transaction state of the transaction global state lock is an error state, terminating the execution of any one of the sub-schemes and performing rollback operation on the sub-scheme; if the transaction state of the transaction global state lock is a normal execution state and the execution process is not overtime, executing any one of the sub-schemes;
judging whether the pre-execution process of any sub-scheme is correct or not; if the transaction state is wrong, resetting the transaction state to be a wrong state; if so, judging whether any one sub-scheme is the last sub-scheme in the queue sequence of the transaction execution queue; if not, switching the pre-execution process of any one of the sub-schemes into a waiting process; if yes, switching the pre-execution process of any one of the sub-schemes to a submission process, and resetting the transaction state of the transaction global state lock to a normal execution state.
2. The method of claim 1, wherein initializing a transaction global state lock comprises:
and creating a transaction global state lock, and initializing the transaction state of the transaction global state lock corresponding to the target transaction to be a starting state.
3. The method according to claim 2, wherein while the execution processes of the plurality of sub-schemes are respectively started according to the queue order of the transaction execution queue, a start daemon monitors the execution processes of the plurality of sub-schemes to obtain the transaction state of the transaction global state lock and commit and rollback operations of a single-node transaction executing the transaction process in real time.
4. The method of claim 3, wherein the initiating daemon monitors execution of the plurality of sub-schemes, and comprises:
judging whether any one of the sub-schemes is overtime in the transaction execution process;
if yes, destroying the daemon program and performing rollback operation on the sub-scheme;
if not, the transaction state of the transaction global state lock is judged;
if the transaction state is an error state, destroying the daemon program and performing rollback operation on the sub-scheme;
if the transaction state is a normal execution state, judging whether the execution process of the sub-scheme is consistent with the submission sequence of the transaction submission queue;
if the sub-schemes are consistent, performing a commit operation on the sub-schemes according to the transaction commit queue;
if not, pausing the daemon within a set time, and restarting the daemon after the set time is reached until the execution process of the sub-scheme is consistent with the transaction submission queue.
5. The method of claim 2, wherein the transaction global state lock is terminated when a predetermined distributed transaction execution scheme is completed.
6. An apparatus for implementing data consistency based on a distributed transaction lock, comprising:
the initialization module is used for initializing a transaction execution queue, a transaction submission queue and a transaction global state lock of a target transaction;
a transaction execution scheme determining module, configured to determine a distributed transaction execution scheme according to the transaction execution queue, where an execution process of the distributed transaction execution scheme includes a pre-execution process, a waiting process, and a commit process;
the transaction execution module is used for executing the distributed transaction execution scheme, updating the transaction state of the transaction global state lock of the target transaction in real time, and judging whether the updated transaction state of the transaction global state lock is a normal execution state or not; the distributed transaction execution scheme comprises a plurality of sub-schemes, and the execution processes of the sub-schemes are respectively started according to the queue sequence of the transaction execution queue; judging the transaction state of the transaction global state lock of any one sub-scheme before the transaction is executed, wherein the transaction state comprises a normal execution state, an error state and a starting state; if the transaction state of the transaction global state lock is an error state, terminating the execution of any one of the sub-schemes and performing rollback operation on the sub-scheme; if the transaction state of the transaction global state lock is a normal execution state and the execution process is not overtime, executing any one of the sub-schemes;
the transaction pre-execution module is used for judging whether the pre-execution process of any one of the sub-schemes is correct or not; if the transaction state is wrong, resetting the transaction state to be a wrong state; if so, judging whether any one sub-scheme is the last sub-scheme in the queue sequence of the transaction execution queue; if not, switching the pre-execution process of any one of the sub-schemes into a waiting process; if yes, switching the pre-execution process of any one of the sub-schemes to a submission process, and resetting the transaction state of the transaction global state lock to a normal execution state.
7. An electronic device, comprising: a processor and a memory;
the memory has stored thereon a computer readable program executable by the processor;
the processor, when executing the computer readable program, implements the steps in the method for implementing data consistency based on distributed transaction locks as claimed in any one of claims 1 to 5.
8. A computer readable storage medium, storing one or more programs, which are executable by one or more processors, for performing the steps of the method for achieving data consistency based on distributed transactional locks of any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353874.6A CN115495205B (en) | 2022-11-01 | 2022-11-01 | Method and device for realizing data consistency based on distributed transaction lock |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353874.6A CN115495205B (en) | 2022-11-01 | 2022-11-01 | Method and device for realizing data consistency based on distributed transaction lock |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115495205A CN115495205A (en) | 2022-12-20 |
| CN115495205B true CN115495205B (en) | 2023-03-14 |
Family
ID=85115262
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211353874.6A Active CN115495205B (en) | 2022-11-01 | 2022-11-01 | Method and device for realizing data consistency based on distributed transaction lock |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115495205B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104793988A (en) * | 2014-01-20 | 2015-07-22 | 阿里巴巴集团控股有限公司 | Cross-database distributed transaction implementation method and device |
| CN107977376A (en) * | 2016-10-24 | 2018-05-01 | 腾讯科技（深圳）有限公司 | Distributed data base system and transaction methods |
| CN112148436A (en) * | 2020-09-23 | 2020-12-29 | 厦门市易联众易惠科技有限公司 | Decentralized TCC (transmission control protocol) transaction management method, device, equipment and system |
| CN113051044A (en) * | 2021-04-20 | 2021-06-29 | 中国工商银行股份有限公司 | Distributed transaction processing method and device based on non-service architecture |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7890707B2 (en) * | 2007-06-27 | 2011-02-15 | Microsoft Corporation | Efficient retry for transactional memory |
-
2022
- 2022-11-01 CN CN202211353874.6A patent/CN115495205B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104793988A (en) * | 2014-01-20 | 2015-07-22 | 阿里巴巴集团控股有限公司 | Cross-database distributed transaction implementation method and device |
| CN107977376A (en) * | 2016-10-24 | 2018-05-01 | 腾讯科技（深圳）有限公司 | Distributed data base system and transaction methods |
| CN112148436A (en) * | 2020-09-23 | 2020-12-29 | 厦门市易联众易惠科技有限公司 | Decentralized TCC (transmission control protocol) transaction management method, device, equipment and system |
| CN113051044A (en) * | 2021-04-20 | 2021-06-29 | 中国工商银行股份有限公司 | Distributed transaction processing method and device based on non-service architecture |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115495205A (en) | 2022-12-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7178050B2 (en) | System for highly available transaction recovery for transaction processing systems | |
| CN110780890B (en) | System upgrading method, device, electronic equipment and medium | |
| US9495258B2 (en) | Dynamic generation of disaster recovery plan which react to changes to an underlying topology | |
| US8332443B2 (en) | Masterless distributed batch scheduling engine | |
| US7620842B2 (en) | Method for highly available transaction recovery for transaction processing systems | |
| CN108932338B (en) | Data updating method, device, equipment and medium | |
| US9396052B2 (en) | Periodic validation and health reports of disaster recovery plan | |
| US20090144720A1 (en) | Cluster software upgrades | |
| US20110154092A1 (en) | Multistage system recovery framework | |
| US20060259594A1 (en) | Progressive deployment and maintenance of applications on a set of peer nodes | |
| US8504873B1 (en) | Method and apparatus for providing in-memory checkpoint services within a distributed transaction | |
| JP6832291B2 (en) | Systems and methods for starting application servers in parallel | |
| CN110716793A (en) | Execution method, device, equipment and storage medium of distributed transaction | |
| CN111258957A (en) | Method, device, equipment and medium for updating directory of distributed file system | |
| Glider et al. | The software architecture of a san storage control system | |
| CN108108119B (en) | Configuration method and device for extensible storage cluster things | |
| CN115495205B (en) | Method and device for realizing data consistency based on distributed transaction lock | |
| US6256641B1 (en) | Client transparency system and method therefor | |
| CN106972963B (en) | Service module starting control method and starting control method after crash restart | |
| CN115934251A (en) | Method and system for realizing high availability of cloud native NFS | |
| US20190235962A1 (en) | Management of changed-block bitmaps | |
| US7296193B2 (en) | Technique for processing an error using write-to-operator-with-reply in a ported application | |
| CN112395102A (en) | Distributed database middleware solution method | |
| CN108847980A (en) | A kind of method and device of CTDB node failure virtual IP address migration | |
| JP7148570B2 (en) | System and method for parallel startup of application servers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |