Yige

Yige

Build
HomeArchives作品集

Distributed Transactions

#分布式28
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
Distributed transactions involve a series of operations within a defined boundary, either fully executing or rolling back. They are composed of multiple local transactions in a distributed system. Key concepts include: 1. **ACID Properties**: - **Atomicity**: Transactions are all-or-nothing. - **Consistency**: Transactions lead to a consistent state. - **Isolation**: Transactions operate independently. - **Durability**: Once a transaction is committed, it remains so. 2. **CAP Theorem**: States that a distributed system cannot simultaneously guarantee consistency, availability, and partition tolerance; it can only satisfy two of these at any time. 3. **BASE Theory**: Opposes ACID by allowing eventual consistency, focusing on basic availability, soft state, and eventual consistency. 4. **Methods for Implementing Distributed Transactions**: - **Two-Phase Commit (2PC)**: A coordinator manages the commit process but can lead to blocking and single points of failure. - **Three-Phase Commit (3PC)**: An improvement over 2PC that introduces a pre-commit phase to reduce blocking. - **TCC (Try-Confirm-Cancel)**: Involves a try phase for resource reservation, a confirm phase for execution, and a cancel phase for rollback. - **Local Message Table**: Uses asynchronous messaging for transaction processing, allowing for retries. - **Saga**: Breaks long transactions into shorter ones, coordinating compensating actions for failures. 5. **Transaction Types**: - **Rigid Transactions**: Follow ACID principles with strong consistency. - **Flexible Transactions**: Allow temporary inconsistencies for eventual consistency, following BASE principles. In summary, distributed transactions balance the need for consistency and availability, employing various methods to manage complexities in distributed systems.

Distributed Transactions#

Content from

  1. Geek Time Column: “Principles and Algorithm Analysis of Distributed Technology”
  2. If someone asks you about distributed transactions, throw this article at them
  3. Understanding Distributed Transactions and Two-Phase Commit, Three-Phase Commit

A transaction is actually a bounded sequence of operations with a clear start and end marker, which must either be fully executed or completely rolled back. A distributed transaction is a transaction that runs in a distributed system, composed of multiple local transactions.

Basic Characteristics of Transactions ACID#

  • Atomicity
  • Consistency
  • Isolation
  • Durability

CAP and BASE Theory#

CAP#

  • Consistency: For a specified client, read operations can return the latest write operations. For data distributed across different nodes, if data is updated on one node, and other nodes can read this latest data, it is called strong consistency; if any node fails to read it, it is distributed inconsistency.
  • Availability: Non-faulty nodes return reasonable responses (not error or timeout responses) within a reasonable time. The two keys to availability are reasonable time and reasonable response. Reasonable time means requests cannot be blocked indefinitely and should return within a reasonable time. Reasonable response means the system should clearly return results, and the results should be correct, for example, returning 50 instead of 40.
  • Partition tolerance: The system can continue to operate when a network partition occurs. For example, if a cluster has multiple machines and one machine has a network issue, the cluster can still function normally.

The CAP theorem tells us that a distributed system cannot simultaneously satisfy all three basic requirements: Consistency (C), Availability (A), and Partition tolerance (P), and can satisfy at most two of them. Reference links:

BASE#

BASE theory includes Basically Available, Soft State, and Eventual Consistency.

  • Basically Available: When a distributed system fails, it allows for the loss of some functionality. For example, during certain e-commerce promotions, some non-core functionalities may be downgraded.
  • Soft State: In flexible transactions, the system is allowed to have intermediate states, and this intermediate state does not affect the overall availability of the system. For example, in database read-write separation, there is a delay in synchronizing the write database to the read database (master to slave), which is a kind of soft state.
  • Eventual Consistency: During the operation of a transaction, inconsistencies may arise due to synchronization delays, but in the end state, the data is consistent.

BASE addresses the lack of network delay in CAP theory, using soft state and eventual consistency to ensure consistency after delays. BASE is the opposite of ACID; it is fundamentally different from the strong consistency model of ACID, sacrificing strong consistency to achieve availability and allowing data to be inconsistent for a period of time, but ultimately reaching a consistent state.

Methods for Implementing Distributed Transactions#

  1. Two-Phase Commit Protocol based on XA protocol;
  2. Three-Phase Commit Protocol;
  3. TCC Transaction Mechanism;
  4. Local Message Table;
  5. Saga Transaction.

Among these, the Two-Phase Commit Protocol based on XA protocol and the Three-Phase Commit Protocol adopt strong consistency and comply with ACID, while the message-based eventual consistency methods adopt eventual consistency and comply with BASE theory.

1. Two-Phase Commit Method Based on XA Protocol (2PC)#

The principle of XA for implementing distributed transactions is similar to centralized algorithms in distributed mutual exclusion, with a transaction manager acting as the coordinator, responsible for committing and rolling back various local resources.

Process#

image.png

First Phase: The transaction manager requests each database involved in the transaction to precommit this operation and reflects whether it can be committed.

Second Phase: The transaction coordinator requests each database to commit or roll back the data.

Disadvantages Analysis#

  • Synchronous Blocking Issue: The two-phase commit algorithm is blocking for all participating nodes during execution. This means that when a local resource manager holds critical resources, other resource managers trying to access the same critical resource will be in a blocked state.
  • Single Point of Failure Issue: The XA-based two-phase commit algorithm is similar to centralized algorithms; once the transaction manager fails, the entire system comes to a standstill. Especially during the commit phase, if the transaction manager fails, resource managers will lock the transaction resources while waiting for the manager's message, causing the entire system to be blocked.
  • Data Inconsistency Issue: During the commit phase, if a local network anomaly occurs after the coordinator sends a DoCommit request to participants, or if the coordinator fails while sending the commit request, only some participants may receive the commit request and execute the commit operation, while others that did not receive the request cannot execute the transaction commit. This leads to data inconsistency in the entire distributed system.

2. Three-Phase Commit Protocol Method (3PC)#

The Three-Phase Commit Protocol (3PC) is an improvement over the Two-Phase Commit (2PC), introducing a timeout mechanism and a preparation phase:

  • Timeout Mechanism: If the coordinator or participants do not receive responses from other nodes within the specified time, they will choose to commit or abort the entire transaction based on the current state.
  • Preparation Phase: Before the commit phase, a pre-commit phase is added to eliminate some inconsistent situations and ensure that the states of all participating nodes are consistent before the final commit.

Process#

3PC divides the commit phase of 2PC into two, resulting in three phases: CanCommit, PreCommit, and DoCommit.
image.png

  • CanCommit:
    The CanCommit phase is similar to the voting phase of 2PC: the coordinator sends a request operation (CanCommit request) to participants, asking whether they can perform the transaction commit operation, and then waits for the participants' responses; participants reply Yes if they can successfully execute the transaction; otherwise, they reply No.

  • PreCommit: The coordinator decides whether to perform the PreCommit operation based on the participants' responses.

    1. If all participants reply "Yes," the coordinator will perform the pre-execution of the transaction.
    2. If any participant sends a "No" message to the coordinator, or if the coordinator does not receive responses from participants after a timeout, it will interrupt the transaction.

  • DoCommit: The DoCommit phase performs the actual transaction commit based on the messages sent by the coordinator during the PreCommit phase, entering either the commit phase or the transaction interruption phase.

Comparison with 2PC#

  • Compared to 2PC, 3PC sets timeout periods for both the coordinator and participants, while 2PC only has a timeout mechanism for the coordinator. This avoids the issue where participants cannot release resources when they cannot communicate with the coordinator for a long time (if the coordinator fails), as participants have their own timeout mechanism to automatically commit locally after timing out, thus releasing resources. This mechanism also indirectly reduces the blocking time and scope of the entire transaction.
  • A pre-commit phase (PreCommit) is added between the preparation and commit phases of 2PC, acting as a buffer phase to ensure that the states of all participating nodes are consistent before the final commit phase.

3. TCC Transaction Mechanism#

TCC (Try-Confirm-Cancel) is also known as compensation transactions. Its core idea is: "For each operation, a corresponding confirmation and compensation (rollback operation) must be registered." It consists of three operations:

  • Try Phase: Mainly for detecting the business system and reserving resources.
  • Confirm Phase: Confirming the execution of the business operation.
  • Cancel Phase: Cancelling the execution of the business operation.

image.png

Applicable Scenarios

  • Activities with strong isolation and strict consistency requirements.
  • Business operations with relatively short execution times.

4. Local Message Table#

In eBay's distributed system architecture, the core idea for solving consistency issues is: to asynchronously execute transactions that need to be processed in a distributed manner through messages or logs, which can be stored in local files, databases, or message queues, and then retry failures based on business rules. Reference: Base: An Acid Alternative

5. Saga Transaction#

Saga is a concept mentioned in a database ethics paper 30 years ago. Its core idea is to split long transactions into multiple local short transactions, coordinated by a Saga transaction coordinator. If it ends normally, it completes normally; if a step fails, it calls the compensation operation in reverse order.

It should be noted that in the saga model, isolation cannot be guaranteed because resources are not locked, and other transactions can still overwrite or affect the current transaction. A solution from Huawei can be referenced: adding a session and locking mechanism from the business layer to ensure that resource operations can be serialized. Alternatively, resources can be isolated by pre-freezing funds at the business level, and the latest updates can be obtained by timely reading the current state during business operations.

Specific examples: Refer to Huawei's servicecomb.

Expansion#

Rigid Transactions vs. Flexible Transactions#

  • Rigid transactions follow the ACID principles and have strong consistency. For example, database transactions.
  • Flexible transactions implement eventual consistency using different methods based on different business scenarios, meaning we can make partial trade-offs based on business characteristics and tolerate some data inconsistency for a certain period.

In summary, unlike rigid transactions, flexible transactions allow for data inconsistency across different nodes for a certain period but require eventual consistency. The eventual consistency of flexible transactions follows the BASE theory.

Relationship Between Distributed Mutual Exclusion and Distributed Transactions#

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.