Understanding Distributed Transactions: ACID, CAP, 2PC, 3PC, TCC and Sharding

What is a Distributed Transaction

In everyday life many operations must be performed completely or not at all; similarly a transaction groups multiple steps that must either all succeed or all fail. When data is stored across multiple databases, guaranteeing atomic execution becomes a distributed transaction problem.

Atomicity

Atomicity means a transaction cannot be divided; it must be executed as an indivisible unit, analogous to an atom that cannot be split.

Consistency

Consistency ensures that the total amount of money remains unchanged before and after a transfer, and that queries across distributed nodes return the same result.

Isolation

Isolation guarantees that an unfinished transaction does not affect other concurrent transactions.

Durability

Durability means that once a transaction is committed, its changes are persisted to disk and survive failures.

Consistency Discussion

ACID aims to protect data consistency, but strict consistency can hurt performance. Three consistency models are discussed:

Strong Consistency

Every read returns the most recent write; all nodes see the same data at any moment.

Weak Consistency

Updates may not be immediately visible to all nodes, allowing temporary divergence.

Eventual Consistency

Data may be inconsistent temporarily, but will converge to the same state over time.

Sharding (Database Partitioning)

Sharding splits data across multiple databases to alleviate single‑node bottlenecks. It can be vertical (different tables or databases for loosely coupled business domains) or horizontal (splitting rows by key ranges or hash).

Vertical Sharding

Vertical sharding stores low‑coupling tables in separate databases, similar to micro‑service data isolation.

Benefits: reduces business coupling, improves resource utilization, eases scaling.

Drawbacks: joins become difficult, distributed transaction handling is complex, single tables may still become large.

Horizontal Sharding

Horizontal sharding distributes rows of a large table across multiple databases, often by ID range or hash.

Advantages: controllable table size, easy horizontal scaling, efficient range queries.

Disadvantages: hotspot data can cause performance bottlenecks.

Problems Introduced by Sharding

Sharding breaks the traditional ACID guarantees because a single transaction may involve multiple shards, requiring distributed transaction mechanisms such as XA or two‑phase commit.

CAP Principle

CAP states that a distributed system can simultaneously provide at most two of Consistency, Availability, and Partition tolerance. Partition tolerance is mandatory; the trade‑off between consistency and availability must be considered.

BASE Theory

BASE (Basically Available, Soft state, Eventually consistent) relaxes ACID constraints for large‑scale internet systems, allowing temporary inconsistency in exchange for higher availability.

Two‑Phase Commit (2PC)

2PC splits a distributed transaction into a voting phase and a commit phase, coordinated by a single coordinator.

Phase 1: Voting

Coordinator sends transaction request to participants and waits for responses.

Participants execute the transaction locally, write logs, but do not commit.

Participants report their status to the coordinator and wait.

Phase 2: Commit

Based on participants' responses, the coordinator either sends a commit command to all participants or a rollback command.

Single‑point failure: coordinator outage blocks the whole process.

Synchronous blocking: participants wait for the coordinator, reducing throughput.

Potential inconsistency if commit messages are lost.

Three‑Phase Commit (3PC)

3PC adds a pre‑commit phase and timeout handling to reduce blocking.

Phase 1: Pre‑query

Coordinator asks participants if they can commit; participants respond with a tentative “yes” or “no”.

Phase 2: Pre‑commit

If all say “yes”, the coordinator asks participants to prepare without committing; otherwise it aborts.

Phase 3: Commit

Coordinator finally sends commit or rollback based on the pre‑commit outcome.

TCC Pattern

TCC (Try‑Confirm‑Cancel) moves transaction logic to the service layer. “Try” reserves resources, “Confirm” finalizes them, and “Cancel” releases them if needed.

Try corresponds to the prepare phase of 2PC with business checks.

Confirm maps to the commit phase.

Cancel maps to the rollback phase.

Source: https://www.cnblogs.com/Courage129/p/14433462.html