How 2PC & 3PC Ensure Distributed Transaction Consistency – CAP, ACID, and Messaging

Distributed System Characteristics

In distributed systems, it is impossible to simultaneously satisfy the three CAP properties—Consistency, Availability, and Partition Tolerance. Most scenarios sacrifice strong consistency for high availability, aiming for eventual consistency.

CAP Explained

Consistency : All nodes see the same data at the same time.

Availability : Reads and writes always succeed.

Partition Tolerance : The system continues to operate despite network failures or node partitions.

ACID Explained

Atomicity : All operations in a transaction succeed or none do.

Consistency : Database integrity is preserved before and after the transaction.

Isolation : Concurrent transactions do not interfere with each other.

Durability : Once committed, changes survive system failures.

Distributed Transaction Basics

Distributed Transaction Service (DTS) provides a framework to guarantee eventual consistency across large‑scale distributed environments. Because network latency and packet loss are inevitable, systems prioritize partition tolerance and balance consistency with availability.

Data Consistency Types

Strong Consistency : After an update, all subsequent reads return the latest value.

Weak Consistency : Reads may return stale data; no guarantee on when the latest value becomes visible.

Eventual Consistency : A form of weak consistency where the system eventually returns the last updated value, e.g., DNS.

Common Distributed Techniques

1. Local Message Table

Inspired by eBay, this approach splits a remote distributed transaction into a series of local transactions. Example: cross‑bank transfer where the first step inserts a voucher message into a local table within a local transaction.

Second step notifies the counterpart bank, either via high‑throughput MQ with subscription or via periodic polling of the message table.

2. Message Middleware

Non‑transactional middleware cannot guarantee that a message is successfully sent after the local DB operation, leading to consistency challenges.

Transactional middleware such as Alibaba RocketMQ implements a three‑phase protocol: a prepared message is sent, the local transaction executes, then the message is confirmed or rolled back based on the transaction outcome.

If the confirmation fails, RocketMQ periodically scans for prepared messages and retries according to the sender’s policy.

2PC (Two‑Phase Commit)

2PC uses a coordinator to gather votes from participants (prepare phase) and then instructs them to commit or rollback (commit phase). It ensures atomicity across nodes but suffers from a single‑point coordinator failure, blocking, and possible inconsistency if messages are lost.

3PC (Three‑Phase Commit)

3PC adds a pre‑commit phase to reduce blocking. The phases are can_commit, pre_commit, and do_commit, allowing participants to abort early if they cannot guarantee successful execution.

Both protocols involve the coordinator sending commit or rollback notifications based on participants’ responses, with timeout handling to avoid indefinite blocking.

Source: http://www.linkedkeeper.com/detail/blog.action?bid=1013