Distributed Transaction Consistency Solutions

Distributed Transaction Consistency Solutions

1. What Is a Distributed Transaction

1.1 Transaction

A database transaction (Transaction) is a logical unit of work consisting of a finite sequence of database operations. It possesses the ACID properties: Atomicity, Consistency, Isolation, and Durability.

1.2 Distributed Transaction

Unlike a local transaction that accesses a single database, a distributed transaction involves participants, resource servers, and a transaction manager located on different nodes of a distributed system, possibly belonging to different applications. It must guarantee that all operations either succeed together or fail together, ensuring data consistency across databases.

1.3 Foundations of Data Consistency

Weak Consistency : After a write succeeds, the system does not guarantee that the latest value can be read immediately.

Eventual Consistency : A specific form of weak consistency where, in the absence of further updates, the system eventually returns the last updated value.

Strong Consistency : Once new data is written, any subsequent read returns the latest value.

1.4 CAP Theorem

The CAP theorem (Consistency, Availability, Partition tolerance) states that a distributed system can satisfy at most two of these three properties simultaneously. The trade‑offs are illustrated with CA (unrealistic), CP (e.g., ZooKeeper), and AP (e.g., Cassandra) designs.

1.5 BASE Theory

Basically Available : The system remains functional even when some components fail.

Soft State : Intermediate states may exist without affecting overall availability.

Eventual Consistency : All nodes converge to a consistent state after some time.

2. Distributed Transaction Consistency Solutions

2.1 Two‑Phase Commit (2PC)

2PC involves a coordinator and multiple participants. Phase 1 (prepare) asks participants to vote; if all vote Yes, Phase 2 commits the transaction. If any vote No, the coordinator rolls back. The process ensures all‑or‑nothing semantics.

2.2 Three‑Phase Commit (3PC)

3PC splits the first phase of 2PC into two sub‑phases to avoid blocking when the coordinator fails. It adds a pre‑commit step that does not lock resources until all participants agree. However, network partitions after pre‑commit can still cause inconsistencies.

2.3 TCC (Try‑Confirm‑Cancel)

TCC divides a business operation into three steps: Try (resource reservation), Confirm (final execution), and Cancel (rollback). It does not rely on resource managers' transaction support but on business‑level compensation. Advantages include simpler logic than 2PC; disadvantages are the difficulty of guaranteeing idempotency and high coupling to business code.

2.4 Local Message Table

This pattern splits a distributed transaction into a local transaction plus an asynchronous message. The producer writes business data and a message record in the same DB transaction; a message broker later delivers the message. It is simple and low‑cost but tightly coupled to the business schema.

2.5 MQ (Non‑Transactional Message)

Non‑transactional MQ cannot guarantee atomicity between local DB updates and message delivery. Typical solutions involve idempotent consumers, retry mechanisms, and compensation logic when messages fail after the business operation succeeds.

2.6 MQ Transactional Message

RocketMQ supports transactional messages using a half‑message (invisible to consumers) followed by a commit or rollback. A broker periodically checks pending half‑messages and invokes a user‑provided transaction status check to decide the final outcome.

2.7 Seata

Seata is an open‑source distributed transaction framework offering four modes: AT (automatic two‑phase commit for plain SQL), TCC (application‑level Try‑Confirm‑Cancel), Saga (long‑running compensating transactions), and XA (standard two‑phase commit with lower performance).

Conclusion

Distributed transaction consistency remains a challenging problem due to unreliable network communication. Each solution—2PC, 3PC, TCC, local message tables, MQ approaches, RocketMQ transactional messages, Seata—has its own strengths, weaknesses, and suitable scenarios. In practice, combining confirmation, retry, and compensation mechanisms and often opting for asynchronous eventual consistency yields the most balanced results.