How to solve distributed transaction problems in RPC calls? What are the common distributed transaction solutions?

Distributed transactions are a difficult problem in RPC calls, involving data consistency guarantees between multiple services:

Problem Background: In microservice architecture, a business operation may involve calls to multiple services. How to ensure data consistency between these services is a challenge.

Distributed Transaction Theory:

1. CAP Theorem

• Consistency: All nodes see the same data at the same time
• Availability: Every request gets a response
• Partition Tolerance: System continues to operate during network partitions
• Conclusion: In distributed systems, can only satisfy two characteristics simultaneously

2. BASE Theory

• Basically Available: System guarantees basic availability
• Soft State: Allows data to exist in intermediate states
• Eventually Consistent: Data eventually becomes consistent after some time

Common Solutions:

1. Two-Phase Commit (2PC)

• Prepare Phase: Coordinator asks all participants if they can commit
• Commit Phase: Decides to commit or rollback based on participant feedback
• Advantages: Strong consistency
• Disadvantages: Poor performance, single point of failure, blocking
• Applicable Scenarios: Scenarios with extremely high consistency requirements

2. Three-Phase Commit (3PC)

• Adds pre-commit phase on top of 2PC
• Reduces blocking time
• Still has performance issues

3. TCC (Try-Confirm-Cancel)

• Try Phase: Reserve resources, check business rules
• Confirm Phase: Confirm execution of business operation
• Cancel Phase: Cancel operation, release resources
• Advantages: Good performance, eventual consistency
• Disadvantages: High code intrusion, need to implement three interfaces
• Implementation Example:

  java
  public interface OrderService {
      // Try: Create order, pre-deduct inventory
      @Compensable
      boolean createOrder(Order order);
      
      // Confirm: Confirm order
      void confirmOrder(Long orderId);
      
      // Cancel: Cancel order, rollback inventory
      void cancelOrder(Long orderId);
  }

4. Local Message Table

• Record messages in local database
• Scheduled task scans message table and sends
• Delete record after message consumption succeeds
• Advantages: Simple implementation, high reliability
• Disadvantages: Need additional storage and scheduled tasks
• Applicable Scenarios: Asynchronous scenarios, eventual consistency

5. Transactional Message (like RocketMQ)

• Send half message
• Execute local transaction
• Commit or rollback message
• Consumer consumes message
• Advantages: Good performance, supports high concurrency
• Disadvantages: Depends on message middleware
• Applicable Scenarios: High concurrency scenarios, eventual consistency

6. Saga Pattern

• Split long transaction into multiple local transactions
• Each local transaction has corresponding compensation operation
• Execute in order, execute compensation on failure
• Advantages: Good performance, suitable for long transactions
• Disadvantages: Need to design compensation logic, may produce dirty reads
• Applicable Scenarios: Long transactions, complex business processes

7. Seata (Alibaba Open Source)

• Supports AT, TCC, SAGA, XA modes
• AT Mode:
  • Phase 1: Parse SQL, record before and after images
  • Phase 2: Commit or rollback, recover through image data
• Advantages: Low intrusion to business code
• Disadvantages: Requires database support
• Applicable Scenarios: Java ecosystem, Spring Cloud microservices

Implementation Example (Seata AT Mode):

java
@GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
public void createOrder(Order order) {
    // Deduct inventory
    inventoryService.deductStock(order.getProductId(), order.getQuantity());
    
    // Create order
    orderMapper.insert(order);
    
    // Deduct balance
    accountService.deductBalance(order.getUserId(), order.getAmount());
}

Selection Recommendations:

• Strong Consistency Requirements: 2PC, 3PC, Seata XA
• High Concurrency Scenarios: TCC, Transactional Message, Seata AT
• Long Transactions: Saga Pattern
• Simple Scenarios: Local Message Table
• Java Ecosystem: Seata Framework
• Eventual Consistency Acceptable: TCC, Saga, Transactional Message

Notes:

• Choose appropriate solution based on business scenario
• Consider balance between performance and consistency
• Design idempotency well
• Comprehensive monitoring and alerting mechanisms
• Regularly conduct fault drills