1. TCC Pattern

TCC (Try-Confirm-Cancel) distributed transaction model was first proposed by Microsoft architect Pat Helland for data consistency issues in distributed systems, using a service-oriented two-phase programming model.

1. Try Phase (Resource Reservation)

  • As a first-phase operation, responsible for completing all business checks
  • Reserve necessary business resources
  • Use “flexible check” mechanism, not directly operating actual business data

2. Confirm Phase (Business Submission)

  • As a second-phase commit operation, executes actual business logic
  • Idempotency design must be guaranteed
  • Actually deducts resources reserved in Try phase

3. Cancel Phase (Resource Release)

  • Rollback resources reserved in Try phase
  • Idempotency must also be guaranteed
  • Usually triggered during business exceptions or timeouts

Advantages Over Traditional XA Protocol

  1. Single point of failure: Delegates transaction control to business initiator
  2. Synchronous blocking issue: Introduces timeout mechanism, fine-grained resource control
  3. Data consistency issue: Provides complete compensation mechanism

2. Queue Pattern

Basic Concepts

Queue pattern is a distributed transaction solution achieving eventual consistency. Its core idea is to split distributed transactions into multiple local transactions for processing.

Implementation Principle

  1. Transaction splitting: Split complex distributed transactions into multiple independent local transactions
  2. Message logging: Record transaction status and operation instructions through message logs
  3. Async execution: Use message queue to achieve async communication between services

Technical Implementation

  • Message middleware selection: Kafka, RocketMQ, RabbitMQ
  • Message storage solution: Local file system, database storage, dedicated message middleware

Exception Handling Mechanism

  1. Auto retry: Configure maximum retry count for message consumption
  2. Manual intervention: Provide management interface to view failed messages
  3. Dead letter queue: Messages exceeding maximum retry count enter dead letter queue

Pros and Cons

  • Advantages: System decoupling, improved system throughput, reduced resource lock time
  • Disadvantages: High implementation complexity, brief data inconsistency window

3. Saga Pattern

Saga pattern originated from a database paper published by Hector Garcia-Molina and Kenneth Salem in 1987, decomposing long transactions into a series of short transactions.

Basic Principle

A Saga transaction is a global transaction composed of multiple local transactions, each with a predefined compensation transaction.

Saga Transaction Execution Flow

  1. Forward execution: Execute each sub-transaction in predetermined order
  2. Reverse compensation: When a sub-transaction fails, execute compensation operations in reverse order

Basic Protocols

  • Forward recovery: Retry when failure encountered during execution
  • Backward recovery: Cancel all previously successful sub-transactions when error occurs

Advantages Over Traditional 2PC

  1. Avoids long-term resource locking
  2. More suitable for loosely coupled microservice architecture
  3. Better scalability
  4. Less invasive to business

Limitations

  1. Compensation transaction may not completely restore original state
  2. Requires complete compensation logic design at business level
  3. May have “dirty read” issues