Distributed System Characteristics and Solutions for Distributed Transaction Consistency

1. Distributed System Characteristics

In modern Internet, distributed systems and micro‑service architectures are prevalent. The CAP theorem tells us that when designing a distributed system we must consider consistency, availability and partition tolerance together.

CAP theorem : In a distributed system, at most two of the three properties—Consistency, Availability, Partition tolerance—can be simultaneously satisfied. Consistency means strong data consistency across nodes; Availability means the service can return a result within a bounded time; Partition tolerance refers to the ability to operate despite network partitions.

Examples: Cassandra, Dynamo prioritize AP (weakening C); HBase, MongoDB prioritize CP (weakening A).

BASE theory : Basically Available, Soft state, Eventual consistency. It relaxes ACID to improve availability.

2. Consistency Models

Data consistency models can be classified into three types:

Strong consistency : after a successful update, all replicas reflect the change immediately, usually implemented synchronously.

Weak consistency : the system does not guarantee that a read will see the latest write immediately.

Eventual consistency : a form of weak consistency where updates will eventually propagate to all replicas.

These models can be analyzed with the Quorum NRW algorithm.

3. Distributed Transactions

Distributed transactions aim to guarantee data consistency across distributed storage, but traditional ACID cannot be fully achieved due to node failures.

3.1 Two‑Phase Commit (2PC)

2PC uses a coordinator to collect votes from participants and then decides to commit or rollback. The first phase asks participants if they can commit; the second phase issues the final commit or rollback command. The protocol suffers from blocking if a participant does not receive the decision in the second phase.

3.2 Try‑Confirm‑Cancel (TCC)

TCC splits a business into Try, Confirm and Cancel interfaces. Try reserves resources, Confirm executes the business without further checks, and Cancel releases resources. It operates at the service layer rather than the resource layer, but ensuring idempotency of Confirm and Cancel is difficult.

3.3 Message‑Based Distributed Transactions

Two approaches exist: transaction messages and local messages. Transaction messages keep the message in a “prepared” state until the local transaction succeeds, then become consumable. Local‑message pattern stores a pending message in a local table and a scheduled task retries sending it to the message queue. Both rely on reliable messaging and idempotent consumers.

Summary

There is no single perfect solution for distributed transaction consistency; the choice depends on trade‑offs among availability, performance and complexity. As a pragmatic approach, asynchronous messaging that ensures eventual consistency is often the most balanced choice.