[TOC]

Introduction

(from Wikipedia)

A distributed transaction is a database transaction in which two or more network hosts are involved.

Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources.

Distributed transactions, as any other transactions, must have all four ACID (atomicity, consistency, isolation, durability) properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).

distributed transactions = distributed commit + concurrency control

柔性事务满足 BASE 理论（基本可用，最终一致）, 刚性事务满足 ACID 理论

Solution

1. 2PC (XA、JTA/JTS)

   

   Idea:

   • tentative changes, later commit or undo (abort)
   • single entity decides whether to commit —— Transaction Coordinator (TC)

   But it has a bad reputation:

   • slow because of multiple phases / message exchanges
   • locks are held over the prepare/commit exchanges; blocks other transactions
   • TC crash can cause indefinite blocking, with locks held

   Conclusion: - Used in sharded DBs when a transaction uses data on multiple shards - Usually used only in a single small domain (E.g. not between banks, not between airlines, not over wide area)

2. 3PC

   

   Improvement:

   • 3PC is non-blocking: it places an upper bound on the amount of time required before a transaction either commits or aborts. This property ensures that if a given transaction is attempting to commit via 3PC and holds some resource locks, it will release the locks after the timeout.

3. MQ (RabbitMQ, Kafka)

   Idea: Decoupling, Eventually Consistency, broadcast, flow control,

   Duplicated message, Sequence, Reliability

4. TCC (Try/Confirm/Cancel)

   事务补偿型

   Transactions for SOA

   ByteTCC

Reference

1. Distributed transaction
2. 消息队列设计精要
3. 数学之美番外篇：快排为什么那样快