How much do you know about the five distributed transactions?

1, Foreword

A Transaction is a Transaction between the beginning and the end of a Transaction.

To put it simply: either all are executed or all fail.

Distributed transactions are naturally transactions running in distributed systems, which are composed of transactions on multiple different machines. As above, only when all transactions in the distributed system are executed can it be successful, otherwise it will fail.

Basic characteristics of transaction ACID:

  • Atomicity: a transaction is an inseparable unit of work. The operations included in the transaction are either done or not done.
  • Consistency: the data is complete before and after the transaction is executed.
  • Isolation: the execution of a transaction cannot be disturbed by other transactions. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and the concurrent transactions cannot interfere with each other.
  • Persistence: also known as permanence. Once a transaction is committed, its changes to the data in the database should be permanently saved.

2, Objectives and practical application scenarios of distributed transactions

The goal of distributed transaction is to solve the problem of consistency of multiple independent transactions.

For example, we have a function, the order system, which spans multiple microservices. Since each microservice is not in a library, it is impossible to use database transactions to ensure transactions, so we can use distributed transactions at this time

For example, in the mall project, a user pays an order. In the payment system, the payment table is updated. In another order system, the status of the order in the order library will become paid. How can they ensure the transactions between the two databases in the order table and payment table

Payment operation: modify the balance of payment and order status

3, Distributed transaction solution

  1. Phase II submission agreement (2PC)
  2. Three phase submission agreement (3PC)
  3. Compensation transaction (TCC)
  4. Implementation of Message Oriented Middleware
  5. seata framework

4, Phase II submission agreement (2PC)

Based on XA protocol, it adopts strong consistency and complies with ACID

2PC: (2-phase submission protocol), which is based on XA/JTA specification.

4.1 XA

XA is a distributed transaction architecture (or protocol) proposed by X/Open organization. XA architecture mainly defines the interface between (global) Transaction Manager and (local) Resource Manager.

XA interface is a two-way system interface, which forms a communication bridge between Transaction Manager and one or more resource managers. In other words, in a transaction based on XA, we can manage multiple resources. For example, a system can access multiple databases, or access both databases and resources such as message middleware. In this way, we can directly implement all committed or cancelled transactions in multiple databases and message middleware. XA specification is not a java specification, but a general specification.

4.2 JTA

JTA(Java Transaction API) is the programming interface specification of J2EE. It is the JAVA implementation of XA protocol. It mainly defines:

A transaction manager interface javax transaction. Transaction manager, which defines the start, commit, withdraw and other operations of a transaction.
A resource definition interface meeting XA specification javax transaction. xa. XAResource, a resource. If it wants to support JTA transactions, its resources need to implement the XAResource interface and implement the two-stage submission related interface defined by the interface.

4.3 flow chart

4.4 submission process

1. Commit request phase, or voting phase, steps (1-5)
In the request phase, the coordinator will notify the transaction participants to submit or cancel the transaction, and then enter the voting process.
During the voting process, participants will inform the coordinator of their decision: agree (local job execution of transaction participants is successful) or cancel (local job execution failure).

2. commit phase, steps (6-7)
At this stage, the coordinator will make a decision based on the voting results of the first stage: submit or cancel.
If and only if all participants agree to submit the transaction, the coordinator will notify all participants to submit the transaction, otherwise the coordinator will notify all participants to cancel the transaction.
After receiving the message from the coordinator, the participant will perform the response operation.

4.5 disadvantages

  • Single point of failure: the initiation, submission or cancellation of transactions are managed by the boss coordinator. As long as the coordinator goes down, it will be cool.
  • Disadvantages of synchronous blocking: as can be seen from the above introduction and examples, when our participating system does not receive the real commit or cancel transaction instruction from the boss, it locks the current resources and does not really do transaction related operations. Therefore, the whole distributed system environment is blocked.
  • The disadvantage of inconsistent data: that is to say, when the boss coordinator sends the real commit transaction to the younger brothers, some networks fail, resulting in some systems not receiving the real instruction, then some commit and some fail to commit, which will lead to inconsistent data.

4.6 unsolvable problems

When the coordinator makes mistakes and the participant also makes mistakes, the two phases cannot guarantee the integrity of transaction execution.
Consider that the coordinator sends a commit message and then goes down, and the only participant who receives this message also goes down.
Even if there is a new coordinator, the state of the transaction is uncertain. No one knows whether the transaction has been committed. People who know have been killed.

5, Three phase submission agreement (3PC)

Strong compliance with ACID.
In the second phase, timeout and pre submission mechanisms are added.
There are three main stages: canCommit, preCommit and doCommit

5.1 flow chart

5.2 process

1.CanCommit stage: the CanCommit stage of 3PC is actually very similar to the preparation stage of 2PC. The coordinator sends a commit request to the participant. If the participant can submit, it returns a Yes response, otherwise it returns a No response.

2.PreCommit stage: the Coordinator decides whether to continue the PreCommit operation of the transaction according to the response of Cohort.

Depending on the response, there are two possibilities.
A. If the feedback obtained by the Coordinator from all cohorts is Yes, the transaction will be pre executed:
Send a pre submission request. The Coordinator sends a PreCommit request to Cohort and enters the Prepared phase.
Transaction pre commit. After receiving the PreCommit request, cohort (a group of soldiers) will execute the transaction operation and record the undo and redo information in the transaction log.
Respond to feedback. If Cohort successfully executes the transaction operation, it returns an ACK response and starts waiting for the final instruction.

B. If any Cohort sends a No response to the Coordinator, or the Coordinator does not receive a response from Cohort after waiting for a timeout, the transaction is interrupted:
Send interrupt request. The Coordinator sends an abort request to all cohorts.
Interrupt the transaction. After Cohort receives the abort request from the Coordinator (or fails to receive the Cohort request after timeout), the execution of the transaction is interrupted.

3.DoCommit stage: this stage is used for real transaction submission, which can also be divided into the following two cases:

Execute commit
A. Send a submit request. If the Coordinator receives the ACK response sent by Cohort, he will enter the submission state from the pre submission state. And send a doCommit request to all cohorts.
B. Transaction commit. After receiving the doCommit request, Cohort performs a formal transaction commit. And release all transaction resources after the transaction is committed.
C. Respond to feedback. After the transaction is committed, send an ACK response to the Coordinator.
D. Complete the transaction. The Coordinator completes the transaction after receiving the ACK responses of all cohorts.

Interrupt transaction
If the coordinator does not receive the ACK response sent by the participant, the interrupt transaction is executed.

A. Send interrupt request
The coordinator sends an abort request to all participants
B. Transaction rollback
After receiving the abort request, the participant uses the undo information recorded in phase 2 to perform the transaction rollback operation, and releases all transaction resources after the rollback is completed.
C. Feedback results
After the participant completes the transaction rollback, it sends an ACK message to the coordinator
D. Interrupt transaction
After the coordinator receives the ACK message fed back by the participant, the execution of the transaction is interrupted.


If the Coordinator sends an abort request after entering PreCommit, it is assumed that only one Cohort receives and performs an abort operation,
Other cohorts whose system status is unknown will continue to Commit according to 3PC. At this time, the system status is inconsistent.

5.4 difference between 2pc and 3PC

Added inquiry to increase the probability of success.

A timeout mechanism is set for both the coordinator and the participant (in 2PC, only the coordinator has a timeout mechanism, that is, if the message of cohort is not received within a certain time, it will fail by default). The coordinator hangs up. After the participant waits for a timeout, the transaction is committed by default. There is a loss of progress.

If the participant is abnormal and the coordinator is abnormal, it will cause other participants to submit.

Insert the pre submission stage between the preparation stage and submission stage of 2PC, so that 3PC has three stages: CanCommit, PreCommit and DoCommit.
PreCommit is a buffer that ensures that the states of participating nodes are consistent before the final submission stage.

6, Message based final consistency form

Take the final consistency and follow the BASE theory.

BASE: the full name is the abbreviation of three phrases: basically available, Soft state and Eventually consistent, which is proposed by the architect of eBay.

  • Basically available: in the distributed system environment, it is allowed to sacrifice the unavailability of some functions that do not affect the main process and degrade them to ensure the normal availability of core services.
  • Soft state: in a transaction, we allow the system to have an intermediate state without affecting our system. Take the master-slave replication of the database as an example. There is a delay when replication is fully allowed.
  • Eventually consistent: take the master-slave replication of the database as an example. Although the master-slave replication has a small delay, the data will be consistent in the end soon.

Distributed transactions cannot be solved 100% and can only improve the probability of success. Time between phases, in milliseconds.
Remedial measures:
Timing task compensation. Program or script compensation.
Manual intervention.

7, TCC

Solution: TCC (Try, Confirm, Cancel), two-stage compensation scheme.

As can be seen from the name, to implement a transaction, three API s need to be defined: pre occupy resources, confirm the submission of actual operation resources, and cancel possession = rollback.

If the latter two phases fail in half, log, compensate and notify the labor.

2PC: It is a distributed transaction at the resource level, which always holds the lock of resources.
	If you lock so many databases across more than a dozen databases, it will lead to an extreme waste of resources. Reduced throughput.
TCC: Distributed transactions at the business level are ultimately consistent and will not always hold locks. Reduce the granularity of the lock. After each library is operated, the lock is released.

Are relative: if there is only one request per day, use 2 PC than TCC High performance. because tcc More than one interface call. At this time, 2 PC Not afraid to occupy resources, there is only one call anyway. High concurrency scenario TCC The advantage should be big.

8, Implementation of Message Oriented Middleware

Message queue flexible transaction flow chart:

1. Operate the payment table, and then insert a piece of data in the event table. The status is new and put it into the database. This (1, 2 and 3) operation is in one transaction because they are all a database

2. The scheduled task reads the event table and sends the queue. After successful sending, change the status of the event table new to (published), listen to the event table and insert a piece of data into the event table

3. Whether the scheduled task reading library is a published event table. If it is a published event table, update the order table and update the event table to processed, so as to split a large transaction into several small transactions

Table design:

CREATE TABLE `t_order_event` (
  `id` int(16) NOT NULL,
  `order_type` varchar(32) DEFAULT NULL COMMENT 'Event type (payment table, payment completed, order table modification status)',
  `process` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT 'Event link( new,published,processed)',
  `content` varchar(255) DEFAULT NULL COMMENT 'Event content, which saves the data to be transmitted when the event occurs',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

9, seata framework

Seata is an open source distributed transaction solution, which is committed to providing high-performance and easy-to-use distributed transaction services. Seata will provide users with AT, TCC, SAGA and XA transaction modes to create a one-stop distributed solution for users.

Official website Api (highly recommended):

seata download address:

flow chart:

Operation steps:

1. Download seata server

2. Modify file conf

service {
  #transaction service group mapping
  #Modify, don't change, my_ test_ tx_ Just name yourself.
  vgroup_mapping.my_test_tx_group = "default"
  #only support when registry.type=file, please don't set multiple addresses
  # Address of this service
  default.grouplist = ""
  #disable seata
  disableGlobalTransaction = false

store {
  ## store mode: file,db
  # modify
  mode = "db"

  ## file store property
  file {
    ## store location dir
    dir = "sessionStore"

  ## database store property
  #db information modification
  db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp) etc.
    datasource = "druid"
    ## mysql/oracle/h2/oceanbase etc.
    db-type = "mysql"
    driver-class-name = "com.mysql.cj.jdbc.Driver"
    url = "jdbc:mysql://"
    user = "root"
    password = "root"

3. Modify registry conf

registry {
  # file ,nacos ,eureka,redis,zk,consul,etcd3,sofa
  type = "eureka"

  nacos {
    serverAddr = "localhost"
    namespace = ""
    cluster = "default"
  eureka {
    serviceUrl = "http://localhost:8761/eureka"
    application = "default"
    weight = "1"
  redis {
    serverAddr = "localhost:6379"
    db = "0"
  zk {
    cluster = "default"
    serverAddr = ""
    session.timeout = 6000
    connect.timeout = 2000
  consul {
    cluster = "default"
    serverAddr = ""
  etcd3 {
    cluster = "default"
    serverAddr = "http://localhost:2379"
  sofa {
    serverAddr = ""
    application = "default"
    region = "DEFAULT_ZONE"
    datacenter = "DefaultDataCenter"
    cluster = "default"
    group = "SEATA_GROUP"
    addressWaitTime = "3000"
  file {
    name = "file.conf"

config {
  # file,nacos ,apollo,zk,consul,etcd3
  type = "file"

  nacos {
    serverAddr = "localhost"
    namespace = ""
  consul {
    serverAddr = ""
  apollo { = "seata-server"
    apollo.meta = ""
  zk {
    serverAddr = ""
    session.timeout = 6000
    connect.timeout = 2000
  etcd3 {
    serverAddr = "http://localhost:2379"
  file {
    name = "file.conf"

4. Create database and create tables

Branch transaction table: branch_table
Global transaction table: global_table
Global lock: lock_table

Note: the structure of the table cannot be wrong

5. Add undo to each library_ Log for rollback

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) USING BTREE

10, Summary

The above is the introduction of distributed transactions. If you don't understand it, you can leave a message in the discussion. When you see it, the small farmers will reply to you at the first time. You are also welcome to supplement and exchange the deficiencies in the text. Thank you. Come on

Tags: Database Distributed lock Transaction

Posted by mingo on Wed, 18 May 2022 08:36:52 +0300