Distributed transaction solution

Distributed transaction

What is distributed transaction

It means that a large operation consists of different small operations distributed on different servers. Distributed transactions need to ensure that these small operations either succeed or fail. In essence, distributed transaction is to ensure the data consistency of different databases.

Typical distributed transaction scenario: cross bank transfer involves invoking two remote bank services

Causes of distributed

1. Database sub table

When the data in a single table of the database reaches tens of millions of levels, it is necessary to consider database and table splitting, so it will change from one database to multiple databases. For example, if an operation operates library 01 and library 02, and also ensures data consistency, distributed transactions are used.

2. Application SOA

The so-called SOA is the service of business. For example, when an e-commerce platform places an order, it will call the inventory service to deduct inventory and the order service to update order data. Then it will be designed into the order database and inventory database. In order to ensure the consistency of data, distributed transactions are required.

Summary: in fact, in the final analysis, the above two scenarios are distributed transactions generated by operating multiple databases and ensuring data consistency.

CAP theory of distributed transactions

CAP Theory: CAP principle, also known as CAP theorem, refers to that in a distributed system, Consistency, Availability and Partition tolerance cannot be obtained at the same time.

CAP principle is the cornerstone of NOSQL database.

CAP theory of distributed system: firstly, the three characteristics of distributed system are summarized as follows:

Consistency (C): the characteristic of whether data can be consistent between multiple copies.

Availability (A): the services provided by the system must be consistently available. For each user's request, the results are always returned within a limited time. After that, the system is considered unavailable

Partition fault tolerance (P): in case of any network partition failure, the distributed system still needs to be able to provide services that meet consistency and availability, unless the whole network environment fails.

BASE theory: BASE is basically available, soft state and final consistency. It is the result of consistency and availability permissions in CAP. It is evolved based on the CAP theorem. The core idea is that even if strong consistency cannot be achieved, each application can adopt appropriate methods to achieve the final consistency of the system according to its own business specific

4 common distributed solutions

2PC submission

Two phase commit refers to dividing the transaction commit into two parts: preparation phase and submission phase. The initiator of a transaction is called the coordinator, and the executor of a transaction is called the participant.

Stage 1: preparation stage

The coordinator initiates and transmits the request with transaction information to each participant, asks whether the transaction can be submitted, and waits for the return result.

Participants perform transaction operations and put Undo and Redo into the transaction log (but do not commit)

If the participant executes successfully, it returns YES (transaction can be committed) and no (transaction cannot be committed) if it fails

Phase II: submission phase

This stage is divided into two situations: all participants return YES and any participant returns NO

When all participants feedback YES, the transaction is submitted.

When any participant feeds back NO, the transaction is interrupted.

3PC submission

3PC, a three-phase commit protocol, is an improved version of 2PC, that is, the transaction commit process is divided into three stages: CanCommit, PreCommit and do Commit.

Phase I: CanCommit

1. The coordinator sends a CanCommit request containing the transaction content to all participants, asks whether the transaction can be submitted, and waits for the response of all participants.

2. After receiving the CanCommit request, if the participant thinks that the transaction operation can be executed, it will feed back YES and enter the preparation state, otherwise it will feed back NO.
Phase 2: PreCommit

This stage is divided into two situations:

1. All participants are requested and return YES.

2. If any participant returns NO, or any participant times out and the coordinator cannot receive feedback, the transaction is interrupted

Transaction pre submission: (when all participants give feedback YES)

1. The coordinator sends a PreCommit request to all participants to enter the preparation phase.

2. After receiving the PreCommit request, the participant executes the transaction operation and records the Undo and Redo information in the transaction log (but does not commit the transaction).

3. Each participant feeds back the Ack response or No response to the coordinator and waits for the final instruction.

Interrupt transaction: (when any participant feeds back NO, or the coordinator cannot receive feedback from all participants after waiting for timeout)

1. The coordinator sends an abort request to all participants.

2. Participants interrupt the transaction whether they receive an abort request from the coordinator or a timeout occurs while waiting for the coordinator's request.

Phase 3: do Commit

There are also two situations at this stage:

1. All participants feedback the Ack response, that is, to execute the real transaction submission.

2. Any participant feeds back NO, or the coordinator cannot receive feedback from all participants after waiting for timeout, that is, interrupt the transaction.

Local message table (Alibaba Seata)

Seata's distributed transaction solution is a business level solution that only depends on the transaction capability of a single database. A distributed transaction in the Seata framework contains three roles:

Transaction Coordinator (TC): a transaction coordinator, which maintains the running state of global transactions, coordinates and drives the submission or rollback of global transactions.

Transaction Manager (TM): controls the boundary of global transactions, is responsible for starting a global transaction, and finally initiates the resolution of global commit or global rollback.

Resource Manager (RM): controls branch transactions, is responsible for branch registration and status reporting, receives instructions from the transaction coordinator, and drives the submission and rollback of branch (local) transactions.

TM is the initiator and terminator of a distributed transaction. TC is responsible for maintaining the running state of distributed transactions, while RM is responsible for the running of local transactions. As shown in the figure below:

ack manual compensation transaction of mq (rabbitmq)

There are three main transaction related methods in RabbitMQ:

txSelect()

txCommit()

txRollback()

try {
            // Open transaction
            channel.txSelect();
            // Send a message to the queue, using the rabbitmq default switch
            channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
            // Commit transaction
            channel.txCommit();
        } catch (Exception e) {
            e.printStackTrace();
            // Transaction rollback
            channel.txRollback();
        }

The message producer mainly performs four steps to send a message:

1: Client sends Tx.Select

2: Broker sends tx.select-ok (after it, send message)

3: Client sends Tx.Commit

4: Broker sends Tx.Commit-Ok

Consumer manual ack confirmation

// Turn off automatic confirmation
  channel.basicConsume(QUEUE_NAME, false, queueingConsumer1);
 //Manually confirm whether the ack is batch processed. true: all messages less than deliveryTag will be acked at one time
 channel.basicAck(delivery1.getEnvelope().getDeliveryTag(), false);

  public static void main(String[] args)  throws Exception {
       Connection connection = RabbitConnectionUtil.getConnection("127.0.0.1", 5672, "/", "guest", "guest");
       Channel channel = connection.createChannel();
       //3. Claim queue
       channel.queueDeclare(QUEUE_NAME, false, false, false, null);
       //Set the number of messages obtained from the queue each time. Those who can do more work will not stop when they are finished quickly!
       channel.basicQos(1);
       //4. Define the consumers of the queue
       QueueingConsumer queueingConsumer1 = new QueueingConsumer(channel);
        /*
    true:Indicates automatic confirmation. As long as the message is obtained from the queue, whether the consumer successfully consumes the message after obtaining the message or not, the message will be considered as successfully consumed
    false:Indicates manual confirmation. After the consumer obtains the message, the server will mark the message as unavailable and wait for the consumer's feedback,
    If the consumer has no feedback, the message will always be unavailable, and the server will think that the consumer has hung up and will not send messages to him,
    Until the consumer gives feedback. For example: channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
     */
       //b:ack
       channel.basicConsume(QUEUE_NAME, false, queueingConsumer1);
       //6. Get message
       while (true) {
           anInt += 1;
           QueueingConsumer.Delivery delivery1 = queueingConsumer1.nextDelivery(); 
           String message1 = String.valueOf(delivery1.getBody());          
           System.out.println("[" + String.valueOf(anInt) + "]:receve msg:" + message1);
           //Manually confirm whether the ack is batch processed. true: all messages less than deliveryTag will be acked at one time
           channel.basicAck(delivery1.getEnvelope().getDeliveryTag(), false);
           // System.out.println("[x] Received '" + message2 + "'");
           Thread.sleep(100);
       }
   }

Fro ICH Commando
Fu Xiaoxiong
November 2021