NOTE
2.6 Distributed Transaction Solution: 3PC
1. What Is 3PC - A distributed transaction solution that guarantees strong consistency and is an improved version of 2PC. 2. 3PC Process - Split the first phase of 2PC into two steps, so the whole transaction process has three phases: CanCommit, PreCommit, and DoCommit.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is 3PC?
- A distributed transaction solution that guarantees strong consistency and is an improved version of 2PC.
2. 3PC Process
- Split the first phase of 2PC into two steps, so the whole transaction process has three phases: CanCommit, PreCommit, and DoCommit.
- CanCommit phase: the coordinator asks all participants, Can you complete this transaction? Each participant checks the health of its own state to see whether it is capable of performing the transaction, and then returns an ack message to the coordinator.
- PreCommit phase:
- Pre-commit transaction: if all participants return yes, the coordinator sends SQL to the participants. The participants execute the transaction locally and then return ack messages to the coordinator (note that the participants have not committed the transaction here).
- Abort transaction: if a participant node returns no, or the coordinator times out while waiting for participant-node feedback, the coordinator sends an abort request to all participants.
- DoCommit phase:
- Commit transaction: if all participants return yes in the PreCommit phase, the coordinator sends transaction commit requests to the participants and lets each participant commit its local transaction.
- Roll back transaction: in other cases, the coordinator sends transaction rollback requests to the participants.

3. 2PC vs 3PC
- Split the first phase of 2PC into two steps, so the whole transaction process has three phases: CanCommit, PreCommit, and DoCommit.
- A timeout mechanism is also introduced: timeout mechanisms are introduced for both the coordinator and the participants.
- Solves the single-point-failure problem + performance problem: once a participant cannot receive information from the coordinator in time, it executes commit by default instead of continuing to hold transaction resources and remain blocked.
4. Use Cases for 3PC
- Suitable for businesses that require strong consistency, are highly time-sensitive, and whose distributed transactions can be rolled back, such as financial transfer scenarios.
- A single service uses multiple data sources and all data sources are DBs, that is, a traditional monolith.
5. Problems with 3PC
- Consistency problem: for example, after entering the PreCommit phase, if the coordinator sends an abort instruction but some participants still do not receive the Abort instruction after waiting until timeout because of a network problem, those participants will execute commit, creating data inconsistency among different participants.
- Difficult to implement.
Discussion
Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub