Understanding Distributed Transaction Patterns: TCC, Asynchronous Assurance, and Maximum Effort Notification

The text begins with typical interview questions about framework source code, design patterns, Redis data types, connection pool design, and distributed transaction solutions, noting that two‑phase commit can lock multiple resources for a long time and is hard to extend.

TCC (Try‑Confirm‑Cancel) is presented as a compensation‑based transaction model that achieves eventual consistency. Compared with two‑phase commit, TCC locks resources individually, allowing faster completion of short‑duration operations and enabling partial asynchronous execution across services.

Advantages: independent resource locking, early release after short‑time try‑confirm, and ability to execute compensating transactions if needed.

Applicable scenarios: strict consistency, short execution time, high real‑time requirements (e.g., red‑packet distribution, payment processing).

Asynchronous Assurance Type transforms synchronous transaction steps into message‑driven asynchronous operations, reducing blocking in distributed transactions. It requires the message consumer to acknowledge successful processing; otherwise, the message is retried until consumption succeeds.

Key points: the message middleware must support high availability and avoid loss, and may need guarantees against duplication or disorder.

Applicable scenarios: long‑running processes, lower real‑time demands such as cross‑bank transfers, refunds, or batch financial accounting.

Maximum Effort Notification Type is the lowest‑guarantee pattern, also implemented via message middleware. After the message is delivered, the transaction can finish even if retries reach a maximum limit.

Applicable scenario: notifying transaction results where eventual delivery is sufficient.

Source: CSDN blog (http://blog.csdn.net/hxpjava1/article/details/77841791).