Distributed Transaction Processing: Ensuring Cross-Node Data Consistency
1. Everyday Analogy: Group House Purchase and Escrow Accounts
Imagine several people jointly buying a house. Each person must first deposit funds into an escrow account. Only when all funds are confirmed does the transaction complete; if someone backs out or funds are insufficient, the entire deal is canceled. Distributed transactions solve similar “all-or-nothing” operations across multiple nodes.
2. Basic Concepts and Properties of Transactions
| Transaction Property (ACID) | Explanation | Everyday Analogy |
|---|---|---|
| Atomicity | All operations within a transaction either succeed completely or fail completely | All funds in group purchase are either fully deposited or the deal is void |
| Consistency | System remains in a valid state before and after the transaction | The ledger numbers are accurate and correct |
| Isolation | Concurrent transactions do not interfere with each other | Multiple people signing contracts simultaneously without impact |
| Durability | Results of a completed transaction are permanently saved | Property registration is completed and cannot be lost |
3. Challenges of Distributed Transaction Processing
- Network delays and failures: Communications may timeout or drop packets
- Partial node crashes: Some participants may be unavailable, making decisions difficult
- Coordination difficulty: Multiple nodes must unanimously “agree” or “reject”
- Blocking issues: Participants may be blocked waiting for coordinator instructions for a long time
4. Two-Phase Commit Protocol (2PC)
Phase 1: Prepare
Coordinator ------> Participants: Request to prepare to commit
Participants ------> Coordinator: Respond ready (Yes/No)
Phase 2: Commit/Rollback
Coordinator ------> Participants: Global commit or rollback command
Participants ------> Coordinator: Acknowledge completion
Advantages
- Simple to implement, guarantees atomic commit
Disadvantages
- Blocking: If coordinator crashes, participants wait indefinitely
- Single point of failure risk
5. Three-Phase Commit Protocol (3PC)
Phase 1: CanCommit?
Coordinator ------> Participants: Ask if they can commit
Participants ------> Coordinator: Reply Yes/No
Phase 2: PreCommit
Coordinator ------> Participants: Notify pre-commit
Participants ------> Coordinator: Confirm receipt
Phase 3: DoCommit
Coordinator ------> Participants: Final commit or rollback
Participants ------> Coordinator: Acknowledge completion
Advantages
- Reduces blocking, participants can make decisions if coordinator fails
- Improves fault tolerance
Disadvantages
- More complex protocol, higher implementation cost
- Still affected by network partitioning
6. Go Language Simple Example: Coordinator Logic for Two-Phase Commit
func coordinatorCommit(participants []Participant) bool {
// Phase 1: Prepare
for _, p := range participants {
if !p.Prepare() {
// Some participant rejects, rollback all
for _, p2 := range participants {
p2.Rollback()
}
return false
}
}
// Phase 2: Commit
for _, p := range participants {
p.Commit()
}
return true
}
7. Thought Exercises and Practice
- How can the blocking problem of 2PC be improved?
- Implement a simple 3PC simulation to observe failure recovery flow.
- Explore distributed transaction implementations based on Raft consensus.
8. Conclusion: The Art of Trade-offs in Distributed Transactions
Distributed transactions guarantee atomicity and consistency across nodes but come with complex coordination and fault handling challenges. Understanding and wisely choosing protocols like 2PC and 3PC is foundational for building strongly consistent distributed systems.