preface

Take notes on a couple of blog posts you’ve read recently about distributed transactions. Ha ha ~

Github.com/whx123/Java…

Database transaction

Database transaction (referred to as: transaction), is a logical unit in the process of database management system execution. It consists of a limited sequence of database operations, which are either all executed or not executed. It is an indivisible work unit.

The typical characteristics of database transactions are Atomicity, Consistency, Isolation, and Durabilily (ACID for short).

  • Atomicity: The transaction is executed as a whole, and all or none of the operations on the database contained within it are executed.
  • Consistency: data will not be destroyed before and after the transaction. If account A transfers 10 yuan to account B, the total amount of account A and B will remain the same regardless of success or failure.
  • Isolation: When multiple transactions are accessed concurrently, transactions are isolated from each other, that is, one transaction does not affect the performance of other transactions. In short, there is no trespass between things.
  • Persistence: Indicates that after a transaction is complete, operational changes made by the transaction to the database will be persisted in the database.

How transactions are implemented

Local transactions

Traditional single-server, single-relational database transactions are local transactions. Local transactions are managed by resource managers, and JDBC transactions are a very typical local transaction.

The transaction log

Innodb transaction logs include redo log and undo log.

Redo log

A redo log is a physical log that records physical changes made to a data page, not the changes made to a particular row or rows. It is used to restore the physical data page after a commit.

Undo log

The undo log is a logical log, which is different from the redo log. You can assume that when a record is deleted, the Undo log records a corresponding INSERT record, and when an update record is updated, it records a corresponding reverse update record.

The idea of implementing the transaction ACID feature

  • Atomicity: It is implemented using undo log. If an error occurs during the transaction execution or the user performs rollback, the system returns the status of the beginning of the transaction using undo log logs.
  • Persistence: Use the redo log to restore data in the event of a system crash, as long as the redo log is persisted.
  • Isolation: Transactions are isolated from each other through locks and MVCC.
  • Consistency: Consistency is achieved through rollback, recovery, and isolation in concurrent cases.

Distributed transaction

Distributed transactions: the participants of a transaction, the server supporting the transaction, the resource server, and the transaction manager are located on different nodes in different distributed systems. To put it simply, distributed transactions refer to transactions in distributed systems, which exist to ensure data consistency between different database nodes.

Why distributed transactions? The following two aspects are elaborated:

Distributed transactions under microservices architecture

With the rapid development of the Internet, lightweight and clearly defined functions of micro-services, onto the stage of history. For example, if a user places an order to buy live gifts, the service is split into three services, namely coinService, orderService and giftService. These services are deployed on different machines (nodes), and the corresponding databases (gold database, order database, gift database) are on different nodes.

Users order to buy gifts, gift database, gold database, order database on different nodes, using local transactions is not possible, so how to ensure data consistency on different databases (nodes)? This requires distributed transactions

Distributed transactions under sub-tables

With the development of the business, the data of the database is increasingly huge, more than ten million levels of data, we need to separate its database and table (the company used myCAT database and table, and then sharing-JDBC). Data is distributed on different nodes, such as shenzhen machine room and Beijing machine room. If you want to use local transactions to ensure that, you have no concern about it.

For example, if A transfers 10 yuan to B, A’s account data is in Beijing machine room, and B’s account data is in Shenzhen machine room. The process is as follows:

CAP theory &BASE theory

To study distributed transactions, it is necessary to understand CAP theory and BASE theory.

Theory of CAP

As the basic theory of distributed system, CAP theory refers to Consistency, Availability and Partition tolerance in a distributed system, which can only achieve two points at most at the same time.

C: Consistency:

Consistency is the property of data consistency across multiple copies. For example, after one partition node is updated, the data read from other partition nodes is also updated.

A: Availability:

Availability means that the services provided by the system must always be available, and the results of each operation request can always be returned within a limited period of time. The emphasis here is on “finite time” and “return result”.

P:Partition tolerance:

When a distributed system encounters any network partition failure, it still needs to be able to provide consistent and available services.

choose instructions
CA Abandon partition fault tolerance, enhance consistency and availability, in fact, is the traditional stand-alone database choice
AP Forgo consistency, partition fault tolerance, and availability, which are the design choices of many distributed systems
CP Forgo availability in favor of consistency and partition fault tolerance, and network problems can directly render the entire system unusable

The BASE theory of

BASE theory is an extension of AP in CAP. For our business system, we consider sacrificing consistency in exchange for system availability and partition fault tolerance. BASE is Basically Available, Soft state, and Eventually consistent.

Basically Available

Basic availability: This is achieved by supporting local failures rather than system-wide failures. If users are partitioned across five database servers, the failure of one user database affects only the 20% of users on that particular host, leaving the rest unaffected.

Soft State

Soft state, the state can be out of sync for a period of time

Eventually Consistent

Finally consistent, the final data is consistent, not always strong consistent.

Several solutions for distributed transactions

Distributed transaction solutions mainly include the following:

  • 2PC(Two-stage submission) scheme
  • TCC (Try, Confirm, Cancel)
  • Local message table
  • Best effort notice
  • Saga transaction

Two-stage proposal submission

Two-phase commit scheme is a common distributed transaction solution. The submission of a transaction is divided into two phases: the preparation phase and the submission of the execution plan.

Phase 2 commit is successful

In the prepare phase, the transaction manager sends a prepare message to each resource manager and returns success if the resource manager’s local transaction operation is successful.

In the commit execution phase, if the transaction manager receives a success message from all resource managers, it sends a commit message to each resource manager, and the RM executes the commit according to TM’s instructions. As shown in figure:

Phase 2 commit failure

In the prepare phase, the transaction manager sends a prepare message to each resource manager, returning success if the resource manager’s local transaction operation was successfully executed, and failure if it failed.

During commit execution, if the transaction manager receives a message that any of the resource managers failed, it sends a rollback message to each resource manager. The resource manager rolls back the local transaction operation according to the instructions of the transaction manager, releasing all lock resources used during the transaction processing.

Advantages and disadvantages of two-phase commit

2PC scheme is simple to implement and has low cost, but it has the following disadvantages:

  • Single point of problem: If the transaction manager fails, the resource manager remains locked.
  • Performance problem: All resource managers are blocked synchronously during the transaction commit phase, occupying system resources and releasing resources until the commit is completed, which can easily lead to performance bottlenecks.
  • Data consistency issues: If some resource managers receive committed messages and others do not, data inconsistency issues can occur.

TCC (Compensation Mechanism)

TCC uses a compensation mechanism, the core idea of which is that for each operation, a corresponding acknowledgement and compensation (undo) operation is registered.

TCC (try-confirm-Cancel) model

Try-confirm-cancel (TCC) implements distributed transactions through decomposition of business logic. For a specific business service, TCC distributed transaction model requires business systems to implement the following three sections of logic:

Try phase: Perform the consistency check for all services and reserve necessary service resources.

Confirm phase: Services are submitted without any check because the try phase has already been checked. By default, no error occurs in the Confirm phase.

Cancel phase: This phase releases all service resources occupied by the try phase and rolls back all operations performed in the Confirm phase if services fail to be executed.

The TCC distributed transaction model consists of three parts: master business service, slave business service and business activity manager.

  • Master Business Service: The master business service is responsible for initiating and completing the entire business activity.
  • Slave service: The slave service is a participant of the entire business activity and implements the Try, Confirm, and Cancel operations for the main business service to invoke.
  • Business Activity Manager: The business activity manager manages and controls the entire business activity, including recording the transaction state, invoking the Confirm operation from the business service, invoking the Cancel operation from the business service, etc.

The following example is used to simulate the process of TCC implementing distributed transactions:

Let’s say user A has A balance of 100 gold pieces and has 5 gifts. A spends 10 gold coins, places an order, buys 10 roses. Balances, orders, gifts are all in different databases.

Try phase of TCC:

  • Generates an order record with an order status to confirm.
  • Update the balance of the gold coin in user A’s account to 90 and freeze the gold coin to 10 (reserved business resources)
  • Set the number of gifts for the user to 5 and pre-increase the number to 10.
  • After the Try succeeds, the Confirm phase is entered
  • If any exception occurs during the Try process, it enters the Cancel phase

TCC Confirm phase:

  • Order status updated to paid
  • Update user balance is 90, can be frozen to 0
  • User gift count updated to 15, pre-increased to 0
  • If any exception occurs during the Confirm process, the Cancel phase is entered
  • If the Confirm process is successful, the transaction ends

Cancel phase of TCC:

  • Change the order status to Cancelled
  • Update the user balance back to 100
  • Update user gift count to 5

TCC pros and cons

The TCC solution allows applications to customize the granularity of database operations, which reduces lock conflicts and improves performance, but also has the following disadvantages:

  • The application is highly intrusive and requires service logic to implement the try, Confirm, and Cancel phases.
  • It is difficult to implement different rollback strategies based on network and system failures. Generally, TCC frameworks such as ByteTCC, TCC-Transaction, and Himly are used.

Local message table

Ebay originally proposed the local message table solution to solve the distributed transaction problem. At present, this scheme is widely used in the industry. Its core idea is to split distributed transactions into local transactions for processing. Take a look at the basic implementation flowchart:

Basic implementation idea

Sender:

  • You need a message table that records information about message status.
  • The business data and the message table are in the same database, that is, ensure that they are both in the same local transaction.
  • After the business data and write message table operations are processed in the local transaction, messages are written to the MQ message queue.
  • The message is sent to the message consumer. If the message fails to be sent, a retry is performed.

Message consumer:

  • Process messages in message queues to complete your own business logic.
  • If the local transaction is successfully processed, the transaction is successfully processed.
  • If the local transaction fails, execution is retried.
  • If the fault is a service failure, a service compensation message is sent to the message producer to notify the rollback.

Producers and consumers periodically scan the local message table to resend incomplete or failed messages. If there is a sound automatic reconciliation logic, this scheme is very practical.

Advantages & Disadvantages:

The advantage of this scheme is that it solves the distributed transaction problem and achieves the final consistency. The disadvantage is that the message table is coupled to the business system.

Best effort notice

What is maximum notification

Maximum effort notification is also a distributed transaction solution. The following is an example of enterprise e-bank transfer

  • The enterprise e-banking system invokes the front interface to jump to the transfer page
  • Enterprise e-bank invokes transfer system interface
  • The transfer system completes the transfer process and sends the notification of the transfer result to the e-banking system of the enterprise. If the notification fails, the transfer system will repeat the notification according to the policy.
  • If the enterprise e-banking system does not receive the notification, it proactively invokes the interface of the transfer system to query the transfer result.
  • The transfer system will come back regularly to check the account in case of exchange refund.

The goal of the maximum effort notification scheme is that the sender of the notification tries its best to notify the recipient of the result of the business process through a certain mechanism. The maximum effort notification implementation mechanism is as follows:

Best efforts to notify the solution

For maximum effort notification, MQ’s ACK mechanism can be used.

plan

  • 1. The originator sends the notification to MQ.
  • 2. The receiver listens for MQ messages.
  • 3. After receiving the message, the receiving party processes the service and responds to the ACK.
  • 4. If the receiving party does not respond to the ACK, MQ will notify the receiving party repeatedly at intervals of 1, 5, and 10 minutes.
  • 5. The receiving party can use message proofreading interface to ensure message consistency.

Flow chart of transfer service realization:

  • 1. The user requests the transfer system for transfer.
  • 2. The transfer system completes the transfer and sends the transfer result to MQ.
  • 3. Enterprise e-banking system monitors MQ and receives notification of transfer result. If no message is received, MQ will send notification repeatedly. Receive the transfer result and update the transfer status.
  • 4. The enterprise e-banking system can also take the initiative to query the transfer result query interface of the transfer system and update the transfer status.

Saga transaction

Saga transactions were proposed by Hector Garcia-Molina and Kenneth Salem of Princeton University. The core idea of Saga transactions is to split long transactions into multiple local short transactions, which are coordinated by the Saga transaction Coordinator. The compensation operations are invoked once in reverse order.

Saga profile

  • Saga = Long Live Transaction (LLT)
  • LLT = T1 + T2 + T3 + … + Ti (Ti for local short transaction)
  • Each local transaction Ti has a corresponding compensation Ci

Sequence of Saga execution

  • Normal condition: T1, T2, T3… Tn
  • Abnormal conditions: T1 T2 T3 C3 C2 C1

Saga two recovery strategies

  • Backward recovery, compensating for completed transactions if any local subtransactions fail. For example, in abnormal cases, the execution sequence is T1, T2, Ti, Ci, C2, C1.
  • Restore forward, that is, retry failed transactions, assuming that each subtransaction will eventually succeed. Order of execution: T1, T2… , Tj(failed), Tj(retry),… , Tn.

For example, if a user places an order and buys more than 10 roses for $10, there is

T1= place an order, T2= deduct 10 yuan from the user, T3= add 10 roses to the user, T4= reduce 10 roses from the inventory

C1= cancel the order, C2= add $10 to the user, C3 = subtract 10 roses from the user, C4= add 10 roses from inventory

Suppose an abnormal rollback occurs when the transaction is executed at T4, and when the rose is added back to the inventory in C4, it is found that all the rose of the user is used up. This is a weakness of Saga, which is caused by the lack of isolation between transactions.

You can solve this problem by:

  • Add logic locking at the application level.
  • Session level isolation ensures serialization operations.
  • At the business level, this part of the capital is isolated by pre-freezing funds.
  • Obtain updates by reading the current status during service operations.

Reference and thanks

  • A dry | article take you learn distributed transactions
  • Next time someone asks you about distributed transactions, throw this article to them
  • Talk about distributed transactions, and talk about solutions
  • Mysql transaction implementation principle
  • Redo log and undo log
  • Saga Distributed Transaction Solutions and Practices
  • Best efforts notification for distributed transaction solutions

Personal public account

  • If you think it’s good, give me a thumbs up and attention. Thank you
  • At the same time, I am looking forward to friends can pay attention to my public account, behind slowly launch better dry goods ~ hee hee
  • Github address: github.com/whx123/Java…