Distributed transaction data consistency solution method and device, electronic equipment and medium
By remotely calling and storing data to a key-value database in a distributed transaction to determine data consistency, the high cost problem in existing technologies is solved, and a low-cost solution for distributed transaction data consistency is achieved.
Patent Information
- Application Number
- CN202610235588.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-27
- Publication Date
- 2026-06-05
AI Technical Summary
Existing distributed transactional data consistency solutions require the introduction of additional frameworks such as MySQL, Redis, and message queues (MQ) or Seata, resulting in excessively high development and learning costs.
By remotely calling the execution data of the database corresponding to different services to the corresponding previous database and storing it in the first key-value database, the consistency of the data in the first and second key-value databases is judged according to the distributed transaction order, ensuring that the transaction is successfully committed.
It eliminates the need for additional frameworks, reducing the development and learning costs of distributed transaction data consistency solutions and ensuring the success of distributed transactions and data consistency.
Smart Images
Figure CN122152440A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a distributed transaction data consistency solution, apparatus, electronic device, and storage medium. Background Technology
[0002] As databases face ever-increasing volumes of data, the drawbacks of traditional centralized databases are becoming increasingly apparent. Distributed databases, on the other hand, are gradually replacing traditional centralized databases due to their advantages in scalability, concurrency, reliability, and availability. Therefore, solutions for distributed transaction data consistency have become paramount. Current distributed transaction data consistency solutions, in addition to using commonly used database systems like MySQL and Redis, also require the introduction of message queue (MQ) or Seata (an open-source distributed transaction solution) frameworks for data compensation. These solutions primarily rely on determining the success of distributed transactions to synchronously commit them, requiring significant development costs and learning curves for developers, resulting in high costs for distributed transaction data consistency solutions. Summary of the Invention
[0003] The main objective of this application is to provide a solution, apparatus, electronic device, and storage medium for distributed transaction data consistency, aiming to solve the technical problem of high cost in distributed transaction data consistency solutions.
[0004] To achieve the above objectives, this application provides a distributed transaction data consistency solution, which includes:
[0005] The execution data of each database corresponding to different services is remotely called to the corresponding previous database, and the execution data is stored in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before transaction execution and data after transaction execution. When each execution data is successfully stored, a transaction is submitted through each database based on the corresponding execution data, and the corresponding transaction data is submitted to the second key-value database. Determine whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
[0006] Optionally, before the step of remotely calling the execution data of each database corresponding to different services to the corresponding previous database, the method further includes: A data request is sent to a first database, and the data request is processed by the service corresponding to the first database to generate first execution data; The corresponding transactions in the data request are executed sequentially by the services corresponding to each of the databases to generate the execution data corresponding to the data request.
[0007] Optionally, the step of storing each of the execution data in the first key-value database includes: The execution data corresponding to the next database received is stored in the first key-value database through each of the aforementioned databases; The step of storing the received execution data corresponding to the next database into the first key-value database through each of the databases further includes: storing the received second execution data and the corresponding first execution data into the first key-value database through the first database.
[0008] Optionally, the step of submitting a transaction based on the corresponding execution data through each of the databases and submitting the corresponding transaction data to the second key-value database when each of the execution data is successfully stored includes: The storage marker in the first key-value database is queried through each of the databases. If the storage marker is found, it is determined that each of the execution data is successfully stored. The storage marker is used to indicate that the first database has stored the corresponding first execution data in the first key-value database. The corresponding execution data is updated to the corresponding server logs through each of the databases to generate transaction data and complete the transaction commit. Each of the aforementioned databases submits the corresponding transaction data to the second key-value database.
[0009] Optionally, the step of determining whether the data in the first key-value database and the second key-value database are consistent includes: The execution data corresponding to the first key-value database and the second key-value database is checked by periodically querying the task. If the first key-value database contains execution data that does not exist in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent. If the execution data in the first key-value database also exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
[0010] Optionally, after the step of determining whether the data in the first key-value database and the second key-value database are consistent, the method further includes: If they match, the distributed transaction is deemed to have been successfully committed, and the data in the first key-value database and the second key-value database is cleared. If there is a discrepancy, the distributed transaction is determined to have failed to commit, and the transaction is committed based on the execution data in the first key-value database through the service corresponding to each of the databases. If the transaction commit fails within a preset time, the transaction is abandoned and the original data is restored by synchronizing the pre-execution data of the first key-value database to the first database.
[0011] Optionally, the step of submitting a transaction based on the execution data in the first key-value database through each of the databases includes: The transaction is committed by each of the databases according to the execution data corresponding to the first key-value database, and the generated transaction data is stored in the second key-value database. The execution step is then returned: determine whether the data in the first key-value database and the second key-value database are consistent. When the number of times the distributed transaction commit fails reaches a preset number, the data before the execution of the transaction committed by the first database in the first key-value database is synchronized to the first database, and a data request execution failure is returned.
[0012] This application also provides a distributed transaction data consistency resolution device, which is applied to a distributed transaction data consistency resolution device, and the distributed transaction data consistency resolution device includes: The data storage module is used to remotely call the execution data of each database corresponding to different services to the corresponding previous database, and store the execution data in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before execution and data after execution. The transaction commit module is used to commit transactions based on the corresponding execution data through each of the databases when each of the execution data is successfully stored, and to commit the corresponding transaction data to the second key-value database. The consistency judgment module determines whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
[0013] Optionally, the data module is further configured to: A data request is sent to a first database, and the data request is processed by the service corresponding to the first database to generate first execution data; The corresponding transactions in the data request are executed sequentially by the services corresponding to each of the databases to generate the execution data corresponding to the data request.
[0014] Optionally, the data storage module is further configured to: The execution data corresponding to the next database received is stored in the first key-value database through each of the aforementioned databases; The step of storing the received execution data corresponding to the next database into the first key-value database through each of the databases further includes: storing the received second execution data and the corresponding first execution data into the first key-value database through the first database.
[0015] Optionally, the transaction commit module is further configured to: The storage marker in the first key-value database is queried through each of the databases. If the storage marker is found, it is determined that each of the execution data is successfully stored. The storage marker is used to indicate that the first database has stored the corresponding first execution data in the first key-value database. The corresponding execution data is updated to the corresponding server logs through each of the databases to generate transaction data and complete the transaction commit. Each of the aforementioned databases submits the corresponding transaction data to the second key-value database.
[0016] Optionally, the consistency determination module is further configured to: The execution data corresponding to the first key-value database and the second key-value database is checked by periodically querying the task. If the first key-value database contains execution data that does not exist in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent. If the execution data in the first key-value database also exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
[0017] Optionally, the consistency determination module is further configured to: If they match, the distributed transaction is deemed to have been successfully committed, and the data in the first key-value database and the second key-value database is cleared. If there is a discrepancy, the distributed transaction is determined to have failed to commit, and the transaction is committed based on the execution data in the first key-value database through the service corresponding to each of the databases. If the transaction commit fails within a preset time, the transaction is abandoned and the original data is restored by synchronizing the pre-execution data of the first key-value database to the first database.
[0018] Optionally, the consistency determination module is further configured to: The transaction is committed by each of the databases according to the execution data corresponding to the first key-value database, and the generated transaction data is stored in the second key-value database. The execution step is then returned: determine whether the data in the first key-value database and the second key-value database are consistent. When the number of times the distributed transaction commit fails reaches a preset number, the data before the execution of the transaction committed by the first database in the first key-value database is synchronized to the first database, and a data request execution failure is returned.
[0019] This application also provides an electronic device, which is a physical device, comprising: a memory, a processor, and a program for the distributed transaction data consistency solution stored in the memory and executable on the processor. When the program for the distributed transaction data consistency solution is executed by the processor, it can implement the steps of the distributed transaction data consistency solution as described above.
[0020] This application also provides a computer-readable storage medium storing a program for implementing a distributed transaction data consistency solution, wherein when the program for implementing the distributed transaction data consistency solution is executed by a processor, it implements the steps of the distributed transaction data consistency solution as described above.
[0021] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the distributed transaction data consistency solution described above.
[0022] This application provides a solution, apparatus, electronic device, and storage medium for distributed transaction data consistency. First, execution data from each database corresponding to different services is remotely invoked to the corresponding preceding database, and the execution data is stored in a first key-value database. The databases are arranged according to the order of distributed transaction execution. The execution data includes data before and after transaction execution. When the execution data is successfully stored, each database commits a transaction based on the corresponding execution data and submits the corresponding transaction data to a second key-value database. Finally, it is determined whether the data in the first and second key-value databases are consistent. If they are consistent, the distributed transaction is successfully committed. This application's technical solution uses a method of storing data before and after execution and transaction data after successful transaction commit in the key-value databases, and then determining whether the data in the two key-value databases are consistent, to ensure successful distributed transaction commit and the consistency of distributed transaction data. It does not require introducing an additional framework to develop a distributed transaction data consistency solution system, overcoming the technical shortcomings of synchronously executing transaction commits by judging whether the distributed transaction execution is successful, which requires significant development costs and learning costs for developers, thus reducing the cost of the distributed transaction data consistency solution. Attached Figure Description
[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1 This is a flowchart illustrating the first embodiment of the distributed transaction data consistency solution of this application; Figure 2 This is a data flow structure diagram in the first embodiment of the distributed transaction data consistency solution of this application; Figure 3 This is a flowchart illustrating steps S31 to S35 in the first embodiment of the distributed transaction data consistency solution of this application. Figure 4 This is a schematic diagram of the structure of the distributed transaction data consistency resolution device of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the distributed transaction data consistency solution in the embodiments of this application.
[0026] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0027] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0028] Example 1 As databases face ever-increasing volumes of data, the drawbacks of traditional centralized databases are becoming increasingly apparent. Distributed databases, on the other hand, are gradually replacing traditional centralized databases due to their advantages in scalability, concurrency, reliability, and availability. Therefore, solutions for distributed transaction data consistency have become paramount. Existing distributed transaction solutions mainly include: 2PC (Two-Phase Commit Protocol), 3PC (Three-Phase Commit Protocol), TCC (Try, Confirm, Cancel), and eventual consistency based on reliable messages. Besides requiring commonly used database systems like MySQL and Redis, these solutions also need to incorporate message queues (MQ) or Seata (an open-source distributed transaction solution) frameworks for data compensation. These distributed transaction data consistency solutions primarily rely on determining the success of distributed transactions and synchronously committing transactions. This requires significant development costs and learning curves for developers. Therefore, there is an urgent need for a distributed transaction data consistency solution that is quick to develop and easy for developers to learn.
[0029] This application provides a solution for distributed transaction data consistency. In the first embodiment of this application's distributed transaction data consistency solution, refer to... Figure 1 The distributed transaction data consistency solution includes: Step S10: Remotely call the execution data of each database corresponding to different services to the corresponding previous database, and store each execution data in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before transaction execution and data after transaction execution. Step S20: When each of the execution data is successfully stored, a transaction is submitted through each of the databases based on the corresponding execution data, and the corresponding transaction data is submitted to the second key-value database. Step S30: Determine whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
[0030] In this embodiment, it should be noted that each database (MySQL) is applied in a corresponding server, and each server has a service, which is an application that performs the corresponding operation. This service is used to execute the data request submitted by the user and execute the distributed transactions of each part of the data request in sequence. When the service of the previous server starts or finishes execution, it can send an execution instruction to the next server. After receiving the execution instruction from the previous server, the next server can start executing the corresponding part of the transaction in the data request. The data before and after the transaction execution of each database is transmitted to the corresponding previous database through the corresponding service via remote procedure call (RPC). The previous database stores the data before and after the transaction execution of the next database into the first key-value database (Redis1). The first database, which is used to execute the first distributed transaction in the data request, stores the data before and after the transaction execution of the corresponding second database, as well as its own data before and after the transaction execution, into the first key-value database. The key-value database is designed in a cluster mode to ensure high availability.
[0031] As an example, steps S10 to S30 include: receiving a data request sent by a user through the first database in each of the databases, and executing the transaction corresponding to the first database in the data request through the service corresponding to the first database, generating corresponding post-execution data; when each database after the first database receives an instruction to start or finish execution from the previous database, it starts executing the transaction corresponding to the data request through the corresponding service, and generates corresponding post-execution data; when the last database in each of the databases finishes execution, the pre-execution data and post-execution data generated by the transaction are remotely called to the previous database through the service corresponding to the last database, and the pre-execution data and post-execution data of each database are remotely called to the previous database in turn from the last database to the first database, until the pre-execution data and post-execution data of the second database are remotely called to the first database; storing the received pre-execution data and post-execution data of the next database in the first key-value database through each of the databases, wherein the first database stores the second... The data before and after transaction execution, as well as the data before and after transaction execution of each database, are all stored in the first key-value database. When the data in the first database is successfully stored, each database updates its own data before and after execution to the corresponding server log to commit the transaction, generate corresponding transaction data, and submit the transaction data to the second key-value database. The data before and after transaction execution in the first database and the transaction data in the second database are checked to determine if there is any data before and after transaction execution in the first database that is not present in the second database. If not, it is determined that the data in the first key-value database and the second key-value database are consistent, and the distributed transaction has been successfully committed. If so, the execution steps are returned: when the data in each database is successfully stored, a transaction is committed based on the corresponding execution data, and the corresponding transaction data is submitted to the second key-value database, until the data in the first key-value database and the second key-value database are consistent or the transaction commit fails a preset number of times.
[0032] As an example, there are three databases used to perform distributed transactions: the first database, the second database, and the third database. (Refer to...) Figure 2MySQL1, MySQL2, and MySQL3 represent the first, second, and third databases, respectively; Redis1 and Redis2 represent the first and second key-value databases, respectively. 1 and 3 indicate that the preceding database is executing a distributed task or has completed a distributed task and is sending execution instructions to the following database. 2 and 4 indicate that the following database remotely calls the preceding database for pre-transaction and post-transaction data through the corresponding service. 5 indicates that the second database stores the pre-transaction and post-transaction data received from the third database into the first key-value database. 6 indicates that the first database stores the pre-transaction and post-transaction data received from the second database, as well as its own pre-transaction and post-transaction data, into the first key-value database. 7, 8, and 9 indicate that after each database completes its transaction commit, the corresponding transaction data is committed to the second key-value database. 10 indicates that the data in the first and second key-value databases is checked to determine if the data is consistent.
[0033] In addition, before the step of remotely calling the execution data of each database corresponding to different services to the corresponding previous database, the method further includes: Step A10: Send the data request to the first database, and process the data request through the service corresponding to the first database to generate the first execution data; Step A20: Execute the corresponding transactions in the data request sequentially through the services corresponding to each database to generate the execution data corresponding to the data request.
[0034] In this embodiment of the application, it should be noted that this embodiment provides a transaction execution method before the distributed data transaction is committed in each database. Each database executes each part of the transaction in the data request sequentially through its corresponding service. When the current database is executing the corresponding transaction or when the transaction is completed, it can send an execution instruction to the next database. When the next database receives the execution instruction, it starts to execute the corresponding transaction in the data request through its corresponding service. In this way, each part of the transaction in the data request is executed sequentially. The user can choose to send the execution instruction to the next database when the current database is executing the corresponding transaction or after the transaction is completed, as needed.
[0035] As an example, steps A10 to A20 include: receiving a data request sent by a user and sending the data request to a first database; processing the data request through the service corresponding to the first database to generate data after the execution of a first transaction; sending an execution instruction to a second database through the service corresponding to the first database, and when the second database receives the execution instruction, processing the transaction corresponding to the data request through the service corresponding to the second database to generate data after the execution of a second transaction; sending an execution instruction to a third database through the service corresponding to the second database, and when the third database receives the execution instruction, processing the transaction corresponding to the data request through the service corresponding to the third database to generate data after the execution of a third transaction; and so on, until the services corresponding to all databases have completed the execution of the transactions corresponding to the data requests.
[0036] The step of storing each of the execution data in the first key-value database includes: Step S11: The execution data corresponding to the received next database is stored in the first key-value database through each of the databases. Step S12, wherein the step of storing the received execution data corresponding to the next database into the first key-value database through each of the databases further includes: storing the received second execution data and the corresponding first execution data into the first key-value database through the first database.
[0037] In this application embodiment, it should be noted that this application embodiment provides an execution data storage method, wherein the order in which each database stores the execution data corresponding to the next database is from back to front, until the first database stores the received second execution data and the corresponding first execution data into the first key-value database.
[0038] As an example, there are three databases used to execute distributed transactions: a first database, a second database, and a third database. Steps S11 to S12 include: storing the third execution data received from the third database into the first key-value database through the second database; and storing the second execution data received from the second database and the corresponding first execution data into the first key-value database through the first database.
[0039] The step of submitting a transaction based on the corresponding execution data through each database and submitting the corresponding transaction data to the second key-value database when each of the execution data is successfully stored includes: Step S21: Query the storage marker in the first key-value database through each of the databases. If the storage marker is found, it is determined that each of the execution data is successfully stored. The storage marker is used to indicate that the first database has stored the corresponding first execution data in the first key-value database. Step S22: Update the corresponding execution data to the corresponding server log through each of the databases to generate transaction data and complete the transaction commit; Step S23: Submit the corresponding transaction data to the second key-value database through each of the databases.
[0040] In this embodiment of the application, it should be noted that this embodiment provides a transaction commit method, wherein the storage tag is used to indicate that the first database has stored the corresponding first execution data in the first key-value database, and the order in which each database stores the corresponding execution data in the first key-value database is from back to front. That is, when the first database has stored the corresponding first execution data in the first key-value database, the data storage steps of each database have been completed. The standard for the successful execution of submitting the corresponding transaction data to the second key-value database through each of the databases is based on whether the first key-value database and the second key-value database are consistent.
[0041] As an example, steps S21 to S23 include: setting up timed query tasks in each of the databases to query whether there exists a storage tag in the first key-value database that indicates that the first database has stored the corresponding first execution data in the first key-value database; if the storage tag is found in each of the databases, the corresponding execution data is updated to the corresponding server log in each of the databases to generate transaction data and complete the transaction commit; after the transaction commit is successful in each of the databases, the transaction data is submitted to the second key-value database for transaction commit status verification.
[0042] Among them, reference Figure 3 The step of determining whether the data in the first key-value database and the second key-value database are consistent includes: Step S31: The execution data corresponding to the first key-value database and the second key-value database is checked by a timed query task; Step S32: If the first key-value database includes execution data that does not exist in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent. Step S33: If the execution data in the first key-value database also exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
[0043] In this embodiment of the application, it should be noted that this embodiment provides a method for determining whether a distributed transaction has been successfully committed by checking the data in a first key-value database and a second key-value database. The transaction data in the second key-value database includes the data before and after the transaction execution for each database.
[0044] As an example, steps S31 to S33 include: obtaining the scheduled query frequency, setting a scheduled query task based on the scheduled query frequency; checking the pre-transaction and post-transaction data corresponding to the first key-value database and the second key-value database using the scheduled query task, and determining whether the first key-value database includes pre-transaction and post-transaction data that are not present in the second key-value database; if the first key-value database includes execution data that is not present in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent; if the execution data in the first key-value database exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
[0045] Additionally, refer to Figure 3 After the step of determining whether the data in the first key-value database and the second key-value database are consistent, the method further includes: Step S34: If they match, the distributed transaction is determined to have been successfully committed, and the data in the first key-value database and the second key-value database is cleared. Step S35: If there is no consistency, the distributed transaction submission is determined to have failed, and the transaction is submitted based on the execution data in the first key-value database through the service corresponding to each of the databases. If the transaction submission fails within a preset time, the transaction submission is abandoned and the original data is restored by synchronizing the pre-execution data of the first key-value database to the first database.
[0046] In this application embodiment, it should be noted that this application embodiment provides a method for determining whether a distributed transaction has been successfully committed based on the consistency of data between the first key-value database and the second key-value database, and for handling the case after successful or failed commit.
[0047] As an example, steps S34 to S35 include: when the data in the first key-value database is consistent with the data in the second key-value database, the distributed transaction is determined to have been successfully committed; the data in the first key-value database and the second key-value database is cleared to receive the execution data and transaction data corresponding to the next distributed transaction; when the data in the first key-value database is inconsistent with the data in the second key-value database, the distributed transaction is determined to have failed to commit; the corresponding execution data in the first key-value database is extracted through each of the databases and the transaction is committed again; if the transaction commit fails within a preset time, the transaction is abandoned and the data before execution in the first key-value database is synchronized to the first database to restore the original data.
[0048] The step of submitting transactions based on execution data in the first key-value database through each of the databases includes: Step S351: The transaction is committed through each of the databases according to the execution data corresponding to the first key-value database, and the generated transaction data is stored in the second key-value database. Then, the execution step is returned: Determine whether the data in the first key-value database and the second key-value database are consistent. Step S352: When the number of times the distributed transaction commit fails reaches a preset number, synchronize the data before the execution of the transaction committed by the first database in the first key-value database to the first database, and return a data request execution failure.
[0049] In this embodiment of the application, it should be noted that this embodiment provides a method for handling the situation when the data in the first key-value database and the second key-value database are found to be inconsistent, i.e., after the distributed transaction commit fails.
[0050] As an example, steps S351 to S352 include: extracting the pre-transaction data and post-transaction data corresponding to the first key-value database through each of the databases, and updating the pre-transaction data and post-transaction data to the server log to commit the transaction and generate the corresponding transaction data; returning to step S30: determining whether the data in the first key-value database and the second key-value database are consistent; if consistent, determining that the distributed transaction has been successfully committed; clearing the data in the first key-value database and the second key-value database to receive the execution data and transaction data corresponding to the next distributed transaction; if inconsistent, returning to step S351: committing the transaction through each of the databases according to the corresponding execution data in the first key-value database, and storing the generated transaction data in the second key-value database, until the number of times the distributed transaction commit failure is determined reaches a preset number, synchronizing the pre-transaction data committed by the first database in the first key-value database to the first database to restore the state before processing, and pushing a visual reminder of the data request execution failure to the user for reference.
[0051] This application provides a solution for distributed transaction data consistency. First, the execution data of each database corresponding to different services is remotely invoked to the corresponding preceding database, and the execution data is stored in a first key-value database. The databases are arranged according to the order of distributed transaction execution. The execution data includes data before and after transaction execution. When the execution data is successfully stored, each database commits a transaction based on the corresponding execution data and submits the corresponding transaction data to a second key-value database. Finally, it is determined whether the data in the first and second key-value databases are consistent. If they are consistent, the distributed transaction is successfully committed. This application's technical solution uses a method of storing data before and after execution and transaction data after successful transaction commit in the key-value databases, and then determining whether the data in the two key-value databases are consistent. This ensures successful distributed transaction commit and data consistency without introducing an additional framework to develop a distributed transaction data consistency solution system. It overcomes the technical shortcomings of synchronously executing transaction commits by judging whether the distributed transaction execution is successful, which requires significant development costs and learning costs for developers, thus reducing the cost of the distributed transaction data consistency solution.
[0052] Example 2 This application also provides a distributed transaction data consistency resolution device, which is applied to a distributed transaction data consistency resolution equipment, as described above. Figure 4 The distributed transaction data consistency resolution device includes: The data storage module 101 is used to remotely call the execution data of each database corresponding to different services to the corresponding previous database, and store the execution data in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before execution and data after execution. The transaction commit module 102 is used to commit transactions based on the corresponding execution data through each of the databases when each of the execution data is successfully stored, and to commit the corresponding transaction data to the second key-value database. The consistency judgment module 103 determines whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
[0053] Optionally, the data storage module 101 is further configured to: A data request is sent to a first database, and the data request is processed by the service corresponding to the first database to generate first execution data; The corresponding transactions in the data request are executed sequentially by the services corresponding to each of the databases to generate the execution data corresponding to the data request.
[0054] Optionally, the data storage module 101 is further configured to: The execution data corresponding to the next database received is stored in the first key-value database through each of the aforementioned databases; The step of storing the received execution data corresponding to the next database into the first key-value database through each of the databases further includes: storing the received second execution data and the corresponding first execution data into the first key-value database through the first database.
[0055] Optionally, the transaction commit module 102 is further configured to: The storage marker in the first key-value database is queried through each of the databases. If the storage marker is found, it is determined that each of the execution data is successfully stored. The storage marker is used to indicate that the first database has stored the corresponding first execution data in the first key-value database. The corresponding execution data is updated to the corresponding server logs through each of the databases to generate transaction data and complete the transaction commit. Each of the aforementioned databases submits the corresponding transaction data to the second key-value database.
[0056] Optionally, the consistency determination module 103 is further configured to: The execution data corresponding to the first key-value database and the second key-value database is checked by periodically querying the task. If the first key-value database contains execution data that does not exist in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent. If the execution data in the first key-value database also exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
[0057] Optionally, the consistency determination module 103 is further configured to: If they match, the distributed transaction is deemed to have been successfully committed, and the data in the first key-value database and the second key-value database is cleared. If there is a discrepancy, the distributed transaction is determined to have failed to commit, and the transaction is committed based on the execution data in the first key-value database through the service corresponding to each of the databases. If the transaction commit fails within a preset time, the transaction is abandoned and the original data is restored by synchronizing the pre-execution data of the first key-value database to the first database.
[0058] Optionally, the consistency determination module 103 is further configured to: The transaction is committed by each of the databases according to the execution data corresponding to the first key-value database, and the generated transaction data is stored in the second key-value database. The execution step is then returned: determine whether the data in the first key-value database and the second key-value database are consistent. When the number of times the distributed transaction commit fails reaches a preset number, the data before the execution of the transaction committed by the first database in the first key-value database is synchronized to the first database, and a data request execution failure is returned.
[0059] The distributed transaction data consistency resolution apparatus provided in this application adopts the distributed transaction data consistency resolution method in the above embodiments, solving the technical problem of high cost of distributed transaction data consistency solutions. Compared with the prior art, the beneficial effects of the distributed transaction data consistency resolution apparatus provided in this application are the same as the beneficial effects of the distributed transaction data consistency resolution method provided in the above embodiments, and other technical features in this distributed transaction data consistency resolution apparatus are the same as the features disclosed in the method of the previous embodiment, and will not be repeated here.
[0060] Example 3 This application provides an electronic device, which includes: at least one processor; and a memory communicatively linked to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the distributed transaction data consistency solution in Embodiment 1 above.
[0061] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0062] like Figure 5 As shown, an electronic device may include a processing unit (such as a central processing unit, graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage device into random access memory (RAM). The RAM also stores various programs and data required for the operation of the electronic device. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.
[0063] Typically, the following systems can be connected to the I / O interface: input devices including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices including, for example, magnetic tapes, hard disks, etc.; and communication devices. Communication devices allow electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although electronic devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.
[0064] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, it performs the functions defined above in the methods of embodiments of this disclosure.
[0065] The electronic device provided in this application employs the distributed transaction data consistency solution described in the above embodiments, thus solving the technical problem of high cost in distributed transaction data consistency solutions. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the distributed transaction data consistency solution provided in Embodiment 1 above, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.
[0066] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.
[0067] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0068] Example 4 This embodiment provides a computer-readable storage medium having computer-readable program instructions stored thereon, which are used to execute the distributed transaction data consistency solution method in Embodiment 1 above.
[0069] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.
[0070] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.
[0071] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device causes the following: remotely invokes execution data from each database corresponding to different services to the corresponding preceding database, and stores each of the execution data in a first key-value database, wherein each of the databases is arranged according to the order of execution of distributed transactions, and the execution data includes data before transaction execution and data after transaction execution; when each of the execution data is successfully stored, a transaction is submitted through each database based on the corresponding execution data, and the corresponding transaction data is submitted to a second key-value database; it is determined whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully submitted.
[0072] Computer program code for performing the operations of this disclosure can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or database. In cases involving remote computers, the remote computer can be linked to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be linked to an external computer (e.g., via the Internet using an Internet service provider).
[0073] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0074] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0075] The computer-readable storage medium provided in this application stores computer-readable program instructions for executing the above-described distributed transaction data consistency solution, thus solving the technical problem of high cost in distributed transaction data consistency solutions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the distributed transaction data consistency solution provided in the above-described embodiments, and will not be repeated here.
[0076] Example 5 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the distributed transaction data consistency solution described above.
[0077] The computer program product provided in this application solves the technical problem of high cost in distributed transaction data consistency solutions. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the distributed transaction data consistency solution provided in the above embodiments, and will not be repeated here.
[0078] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.
Claims
1. A distributed transaction data consistency solution, characterized in that, The distributed transaction data consistency solution includes: The execution data of each database corresponding to different services is remotely called to the corresponding previous database, and the execution data is stored in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before transaction execution and data after transaction execution. When each execution data is successfully stored, a transaction is submitted through each database based on the corresponding execution data, and the corresponding transaction data is submitted to the second key-value database. Determine whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
2. The distributed transaction data consistency solution as described in claim 1, characterized in that, Before the step of remotely calling the execution data of each database corresponding to different services to the corresponding previous database, the method further includes: A data request is sent to a first database, and the data request is processed by the service corresponding to the first database to generate first execution data; The corresponding transactions in the data request are executed sequentially by the services corresponding to each of the databases to generate the execution data corresponding to the data request.
3. The distributed transaction data consistency solution as described in claim 1, characterized in that, The step of storing each of the execution data into the first key-value database includes: The execution data corresponding to the next database received is stored in the first key-value database through each of the aforementioned databases; The step of storing the received execution data corresponding to the next database into the first key-value database through each of the databases further includes: storing the received second execution data and the corresponding first execution data into the first key-value database through the first database.
4. The distributed transaction data consistency solution as described in claim 1, characterized in that, The step of submitting a transaction based on the corresponding execution data through each database and submitting the corresponding transaction data to the second key-value database when each of the execution data is successfully stored includes: The storage marker in the first key-value database is queried through each of the databases. If the storage marker is found, it is determined that each of the execution data is successfully stored. The storage marker is used to indicate that the first database has stored the corresponding first execution data in the first key-value database. The corresponding execution data is updated to the corresponding server logs through each of the databases to generate transaction data and complete the transaction commit. Each of the aforementioned databases submits the corresponding transaction data to the second key-value database.
5. The distributed transaction data consistency solution as described in claim 1, characterized in that, The step of determining whether the data in the first key-value database and the second key-value database are consistent includes: The execution data corresponding to the first key-value database and the second key-value database is checked by periodically querying the task. If the first key-value database contains execution data that does not exist in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are inconsistent. If the execution data in the first key-value database also exists in the second key-value database, then it is determined that the data in the first key-value database and the second key-value database are consistent.
6. The distributed transaction data consistency solution as described in claim 1, characterized in that, After the step of determining whether the data in the first key-value database and the second key-value database are consistent, the method further includes: If they match, the distributed transaction is deemed to have been successfully committed, and the data in the first key-value database and the second key-value database is cleared. If there is a discrepancy, the distributed transaction is determined to have failed to commit, and the transaction is committed based on the execution data in the first key-value database through the service corresponding to each of the databases. If the transaction commit fails within a preset time, the transaction is abandoned and the original data is restored by synchronizing the pre-execution data of the first key-value database to the first database.
7. The distributed transaction data consistency solution as described in claim 6, characterized in that, The step of submitting transactions based on the execution data in the first key-value database through each of the databases includes: The transaction is committed by each of the databases according to the execution data corresponding to the first key-value database, and the generated transaction data is stored in the second key-value database. The execution step is then returned: determine whether the data in the first key-value database and the second key-value database are consistent. When the number of times the distributed transaction commit fails reaches a preset number, the data before the execution of the transaction committed by the first database in the first key-value database is synchronized to the first database, and a data request execution failure is returned.
8. A distributed transaction data consistency resolution device, characterized in that, The distributed transaction data consistency resolution device includes: The data storage module is used to remotely call the execution data of each database corresponding to different services to the corresponding previous database, and store the execution data in the first key-value database. The databases are arranged according to the order of execution of distributed transactions, and the execution data includes data before execution and data after execution. The transaction commit module is used to commit transactions based on the corresponding execution data through each of the databases when each of the execution data is successfully stored, and to commit the corresponding transaction data to the second key-value database. The consistency judgment module determines whether the data in the first key-value database and the second key-value database are consistent. If they are consistent, the distributed transaction is successfully committed.
9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the steps of the distributed transaction data consistency solution according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for implementing a distributed transaction data consistency solution, which is executed by a processor to implement the steps of the distributed transaction data consistency solution as described in any one of claims 1 to 7.