Understanding Distributed Transactions, Consistency Models, Sharding, and Commit Protocols

What Is a Distributed Transaction

In everyday life a transaction is an all‑or‑nothing operation, such as transferring money between accounts; the same principle applies to databases where a transaction must either fully succeed or fully fail. When data spans multiple databases, guaranteeing atomicity across network partitions becomes a core challenge.

ACID Properties

Atomicity : a transaction cannot be split into independent parts.

Consistency : the system must move from one valid state to another; intermediate inconsistent states are not allowed.

Isolation : concurrent transactions do not interfere with each other.

Durability : once committed, the changes survive crashes and are persisted to storage.

Consistency Discussion

Three consistency models are introduced:

Strong consistency : every read sees the most recent write.

Weak consistency : reads may see stale data, acceptable when the application can tolerate it.

Eventual consistency : data will become consistent over time, even if temporary divergences exist.

Database Sharding (分库分表)

Sharding reduces the load on a single database by splitting data across multiple instances.

Vertical Sharding

Separate low‑coupling tables into different databases (or split a wide table into multiple tables based on logical groups such as personal info, location info, and education info).

Horizontal Sharding

Distribute rows based on a key range or hash, e.g., user IDs 1‑10,000 go to DB1, 10,001‑20,000 to DB2, etc.

Problems Introduced by Sharding

Sharding breaks traditional ACID guarantees, leading to distributed transactions that must coordinate across multiple nodes, increasing the risk of conflicts, deadlocks, and data inconsistency.

CAP Principle and BASE Theory

CAP states that a distributed system can only simultaneously guarantee two of three properties: Consistency, Availability, and Partition tolerance (the latter is mandatory). BASE (Basically Available, Soft state, Eventually consistent) offers a pragmatic alternative to strict ACID in large‑scale systems.

Two‑Phase Commit (2PC)

2PC splits a distributed transaction into a voting phase and a commit phase, coordinated by a single coordinator. It ensures atomicity but suffers from single‑point‑of‑failure and blocking issues.

Three‑Phase Commit (3PC)

3PC adds a pre‑commit (can_commit) phase and timeout mechanisms to reduce blocking, improving safety at the cost of higher complexity.

TCC Pattern

TCC (Try‑Confirm‑Cancel) moves transaction logic to the service layer: Try reserves resources, Confirm finalizes them, and Cancel releases them. It provides business‑level checks and compensation mechanisms.

Additional Notes

The article also contains promotional material and disclaimer statements, which are not part of the technical content.