Skip to content
~/zcrossoverz

Distributed Transaction trong Microservices: 2PC, SAGA, Outbox Pattern và Eventual Consistency

By Nhân Nguyễn on Apr 19, 2026
#database#backend

Distributed Transaction trong Microservices: 2PC, SAGA, Outbox Pattern và Eventual Consistency

Làm sao để đảm bảo tính nhất quán dữ liệu khi một giao dịch trải rộng trên nhiều microservice và cơ sở dữ liệu khác nhau? Bài viết phân tích chuyên sâu các mô hình 2PC, SAGA, Outbox Pattern và chiến lược idempotency – những viên gạch nền tảng cho hệ thống ngân hàng lõi.

Nếu bạn đã từng xây dựng một hệ thống microservice, chắc hẳn bạn đã gặp câu hỏi: “Làm sao để đảm bảo một giao dịch trải dài trên nhiều service và nhiều database khác nhau vẫn có tính nhất quán?”

Trong thế giới monolithic, chúng ta quen với @Transactional – một lời hứa đẹp đẽ rằng “tất cả hoặc không gì cả”. Nhưng khi chuyển sang microservices, bức tường giao dịch ACID bị phá vỡ. Dữ liệu nằm rải rác ở PaymentService (PostgreSQL), LedgerService (MySQL), NotificationService (MongoDB). Không còn một database manager nào đứng ra làm “trọng tài” duy nhất.

Hôm nay, chúng ta sẽ cùng mổ xẻ vấn đề này qua lăng kính của một ngân hàng thực thụ – X Bank. Bài viết sẽ đi từ bài toán cụ thể, phân tích các giải pháp như 2PC, SAGA, Outbox Pattern, và cuối cùng là một thiết kế tham khảo có thể chịu tải 100.000 giao dịch mỗi giây.

1. Bài toán thực tế tại X Bank

Sau khi chuyển đổi từ monolith sang microservices, X Bank đối mặt với một nghiệp vụ tưởng chừng đơn giản: Khi khách hàng thực hiện thanh toán, hệ thống phải thực hiện đồng thời ba thao tác sau:

  1. Trừ tiền tài khoản người trả (PaymentService – PostgreSQL)
  2. Ghi nhận bút toán vào sổ cái tổng (LedgerService – MySQL)
  3. Lưu log gửi thông báo (NotificationService – MongoDB)

Đây là đoạn code “ngây thơ” mà nhiều lập trình viên có thể viết trong lần đầu tiên:

@Transactional
public void processPayment(PaymentRequest req) {
    // Bước 1: Trừ tiền - Transaction cục bộ thành công
    paymentService.debitAccount(req.getPayerId(), req.getAmount());

    // Bước 2: Ghi sổ cái - Gọi từ xa qua network
    try {
        ledgerService.recordTransaction(...);
    } catch (TimeoutException ex) {
        // Tài khoản đã bị trừ tiền, nhưng sổ cái thì chưa có bản ghi!
        throw ex;
    }

    // Bước 3: Gửi thông báo
    notificationService.sendNotification(...);
}

Vấn đề:

  • Transaction ở PaymentService đã được commit (tiền đã bị trừ).
  • Gọi sang LedgerService bị timeout do network chập chờn.
  • Hậu quả: Tiền “bốc hơi” khỏi tài khoản nhưng sổ kế toán không có dấu vết. Hệ thống rơi vào trạng thái không nhất quán.

Đây chính là bài toán Distributed Transaction kinh điển. Chúng ta sẽ cùng khám phá các giải pháp.

2. Two-Phase Commit (2PC) – Vì sao bị “từ chối” trong Microservices?

Cơ chế hoạt động

2PC hoạt động với một Coordinator (điều phối viên) và hai pha:

  • Phase 1 (Prepare – Bỏ phiếu): Coordinator gửi lệnh “Chuẩn bị commit” tới tất cả các service. Mỗi service sẽ lock tài nguyên (dòng dữ liệu) và trả lời READY hoặc ABORT.
  • Phase 2 (Commit): Nếu tất cả đều READY, Coordinator gửi lệnh COMMIT. Chỉ cần một service trả lời ABORT hoặc timeout, tất cả sẽ bị ROLLBACK.

Tại sao nó “chết yểu” trong kiến trúc phân tán?

Hãy tưởng tượng kịch bản sau tại X Bank:

  1. PaymentService và NotificationService báo READY. LedgerService cũng báo READY.
  2. Coordinator ra lệnh COMMIT.
  3. PaymentService commit xong (tiền bị trừ).
  4. LedgerService đang ghi dữ liệu thì server bị crash đột ngột 💥.
  5. NotificationService và Coordinator rơi vào trạng thái chờ vô hạn.

Hậu quả:

  • SPOF (Single Point of Failure): Coordinator chết → Tất cả các service tham gia bị treo, lock tài nguyên vô thời hạn.
  • Blocking Protocol: Trong suốt thời gian chờ commit, các service giữ lock database. Với hệ thống tải cao, điều này gây nghẽn cổ chai nghiêm trọng.
  • Không phù hợp với mạng không ổn định: Chỉ cần một network partition, Coordinator mất kết nối với một vài service → Dữ liệu sẽ bị chia cắt.

Kết luận: 2PC chỉ thực sự an toàn trong môi trường mạng LAN ổn định, ít service tham gia và thời gian xử lý nhanh. Trong thế giới Internet và microservices, nó gần như bị loại bỏ.

3. SAGA Pattern – Đi tới sự nhất quán cuối cùng (Eventual Consistency)

Thay vì cố gắng đảm bảo Atomicity (tính nguyên tử) tức thời bằng khóa (lock), SAGA chấp nhận rằng hệ thống sẽ nhất quán sau một khoảng thời gian ngắn (Eventual Consistency).

SAGA là một chuỗi các Local Transaction (giao dịch cục bộ). Nếu một bước thất bại, SAGA sẽ chạy Compensating Transaction để “undo” những bước đã thành công trước đó.

Ví dụ luồng thanh toán:

1. [PaymentService] Trừ tiền tài khoản (Thành công)
2. [LedgerService] Ghi sổ cái (Thất bại do lỗi DB)
3. [Compensation] [PaymentService] Hoàn tiền lại tài khoản.

Có hai cách triển khai SAGA phổ biến: Choreography và Orchestration.

a. Choreography (Biên đạo phân tán)

Các service giao tiếp với nhau qua Event. Mỗi service sau khi hoàn thành công việc sẽ phát ra một sự kiện. Service tiếp theo lắng nghe sự kiện đó để thực hiện phần việc của mình.

PaymentService → Event: "AccountDebited"
LedgerService  → Nhận event → Ghi sổ → Event: "LedgerRecorded"
Notification   → Nhận event → Gửi SMS

Ưu điểm:

  • Loosely Coupled: Các service không phụ thuộc trực tiếp vào nhau.

Nhược điểm (Cực kỳ quan trọng):

  • Luồng logic phân mảnh: Rất khó để hình dung toàn bộ quy trình. Khi xảy ra lỗi, việc xác định ai chịu trách nhiệm rollback là một cơn ác mộng.
  • Vòng lặp chết: Dễ gây ra circular dependency giữa các event.

b. Orchestration (Nhạc trưởng tập trung)

Đây là cách tiếp cận được ưa chuộng hơn trong các hệ thống phức tạp. Một Saga Orchestrator sẽ đứng ra điều phối tuần tự các bước. Nó gọi API của từng service và xử lý lỗi.

// Pseudo-code trong Orchestrator
try {
    payment = paymentService.debit(account, amount);
    ledgerService.record(payment);
    notificationService.send(payment);
} catch (Exception ex) {
    // Gọi hàm bù trừ theo thứ tự ngược lại
    ledgerService.reverse(payment);
    paymentService.credit(account, amount);
    throw new SagaFailedException();
}

Ưu điểm:

  • Logic tập trung, dễ hiểu, dễ debug.
  • Dễ dàng quản lý timeout và cơ chế retry.

Nhược điểm:

  • Orchestrator trở thành điểm tập trung logic (dù không lock dữ liệu như 2PC).

4. Outbox Pattern – Giải cứu bài toán “Dual Write”

Khi triển khai SAGA theo kiểu Choreography, chúng ta gặp một vấn đề nan giải: Làm sao để vừa ghi dữ liệu nghiệp vụ vào database vừa publish event một cách nguyên tử?

@Transactional
public void debitAccount(String id, BigDecimal amount) {
    // TX 1: Ghi DB
    account.debit(amount);
    accountRepo.save(account);

    // TX 2: Gửi Event (qua network)
    kafkaProducer.send(new AccountDebitedEvent(...)); 
    // Nếu network fail ở đây -> Event bị mất, LedgerService không bao giờ nhận được.
}

Đây gọi là vấn đề Dual Write.

Giải pháp: Transactional Outbox

Thay vì gửi event trực tiếp lên Kafka, chúng ta ghi event đó vào một bảng tên là outbox trong cùng một transaction với dữ liệu nghiệp vụ.

@Transactional
public void debitAccount(String accountId, BigDecimal amount) {
    // 1. Ghi nghiệp vụ
    account.debit(amount);
    accountRepo.save(account);

    // 2. Ghi sự kiện vào bảng Outbox (Cùng DB, cùng Connection)
    Outbox outbox = new Outbox(
        "ACCOUNT_DEBITED",
        "{accountId: '" + accountId + "', amount: " + amount + "}"
    );
    outboxRepo.save(outbox);
}

Cơ chế hoạt động:

  • Một Scheduled Job (Outbox Publisher) sẽ định kỳ quét bảng outbox.
  • Nó đọc các event chưa được gửi (published_at IS NULL) và gửi lên Kafka.
  • Nếu gửi thành công, nó đánh dấu published_at.
  • Nếu gửi thất bại, nó sẽ thử lại ở lần quét sau.

Ưu điểm vượt trội:

  • Độ tin cậy: Sự kiện được lưu trong DB, không sợ mất mát.
  • Tính nguyên tử: Việc trừ tiền và tạo event là all-or-nothing.

5. Idempotency – Chìa khóa cho “Exactly-Once Processing”

Outbox Pattern giải quyết việc publish event một cách tin cậy. Nhưng còn consumer thì sao?

  • Outbox Publisher quét bảng, gửi event lên Kafka. Kafka Broker nhận và gửi ACK.
  • Do mạng chập chờn, Publisher không nhận được ACK → Timeout.
  • Publisher đánh dấu event là chưa gửi và thử lại lần sau.
  • Kết quả: Consumer nhận được 2 event giống hệt nhau.

Nếu Consumer là LedgerService và nó ghi sổ cái 2 lần, sổ sách kế toán sẽ bị sai lệch nghiêm trọng (Double Posting).

Cách triển khai Idempotency

Chúng ta cần một Idempotency Key (Khóa định danh duy nhất) cho mỗi event.

  1. Producer: Khi tạo Outbox record, gán một UUID hoặc một key nghiệp vụ (ví dụ: payment_123_DEBIT).
  2. Consumer: Khi nhận event, kiểm tra xem key này đã được xử lý chưa (lưu trong Redis hoặc một bảng processed_events).
  3. Nếu đã xử lý → Bỏ qua.
  4. Nếu chưa xử lý → Xử lý nghiệp vụ và lưu Idempotency Key.
@KafkaListener(topics = "bank.account-debited")
public void onAccountDebited(AccountDebitedEvent event) {
    if (idempotencyService.isAlreadyProcessed(event.getIdempotencyKey())) {
        log.info("Bỏ qua event trùng lặp: {}", event.getIdempotencyKey());
        return;
    }
    
    ledgerService.record(event);
    idempotencyService.markProcessed(event.getIdempotencyKey());
}

6. Production-Grade Implementation (Spring Boot)

Dưới đây là đoạn code triển khai thực tế mà X Bank đã sử dụng.

6.1. Entity và Repository Outbox

@Entity
@Table(name = "outbox")
public class Outbox {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String eventType;

    @Column(nullable = false, columnDefinition = "TEXT")
    private String payload;

    @Column(nullable = false)
    private String aggregateId;

    @Column(nullable = false, unique = true)
    private String idempotencyKey;

    private LocalDateTime createdAt;
    private LocalDateTime publishedAt;
    private Integer retryCount = 0;

    // ... getters/setters
}

6.2. Payment Service với Outbox

@Service
public class PaymentService {

    private final AccountRepository accountRepo;
    private final OutboxRepository outboxRepo;

    @Transactional
    public Payment processPayment(String payerId, BigDecimal amount) {
        // 1. Trừ tiền
        Account account = accountRepo.findByAccountId(payerId)
            .orElseThrow(() -> new AccountNotFoundException(payerId));
        account.debit(amount);
        accountRepo.save(account);

        // 2. Lưu Payment record
        Payment payment = new Payment(payerId, amount, "DEBIT_PENDING");
        Payment savedPayment = paymentRepo.save(payment);

        // 3. Lưu Outbox (Cùng Transaction)
        String idempotencyKey = payerId + "_" + savedPayment.getId() + "_DEBIT";
        Outbox outbox = new Outbox(
            "ACCOUNT_DEBITED",
            buildPaymentEventJson(payerId, amount, savedPayment.getId()),
            payerId,
            idempotencyKey
        );
        outboxRepo.save(outbox);
        
        return savedPayment;
    }
}

6.3. Outbox Publisher (Scheduled Job)

@Component
public class OutboxPublisher {

    @Scheduled(fixedRate = 1000) // Chạy mỗi giây
    @Transactional
    public void publishUnpublishedEvents() {
        List<Outbox> unpublished = outboxRepo.findByPublishedAtIsNullOrderByCreatedAtAsc();
        
        for (Outbox event : unpublished) {
            try {
                kafkaProducer.send(getTopic(event), event.getIdempotencyKey(), event.getPayload());
                event.setPublishedAt(LocalDateTime.now());
                outboxRepo.save(event);
            } catch (Exception e) {
                event.incrementRetryCount();
                // Log lỗi và retry sau
            }
        }
    }
}

7. Trade-offs & Anti-Patterns Cần Tránh

❌ Anti-Pattern 1: Cố dùng 2PC cho Microservices

Hậu quả: Deadlock toàn hệ thống khi Coordinator hoặc một service chậm. Không thể scale.

❌ Anti-Pattern 2: SAGA không có Compensating Transaction

Hậu quả: Tiền bị trừ nhưng không có cách nào hoàn lại tự động. Nhân viên phải vào sửa tay.

❌ Anti-Pattern 3: Không dọn dẹp Outbox Table

Hậu quả: Sau 1 năm, bảng Outbox có 10 triệu bản ghi. Query quét published_at IS NULL bắt đầu chậm như rùa, kéo theo lag toàn hệ thống. Giải pháp: Chạy job định kỳ xóa hoặc archive các event đã publish quá 30 ngày.

❌ Anti-Pattern 4: Coi thường Idempotency ở Consumer

Hậu quả: Một lần gửi lặp của Kafka → Double Spending hoặc sai lệch sổ sách kế toán.

8. Thiết kế cho quy mô 100,000 TPS

Để kết thúc, chúng ta cùng phác thảo kiến trúc cho bài toán X Bank với 100,000 giao dịch/giây.

Yêu cầu:

  • Độ trễ chấp nhận được: < 500ms.
  • Failures thường xuyên (network, restart).
  • Không được mất tiền hoặc mất dấu vết kiểm toán.

Kiến trúc đề xuất:

  1. Tầng Ghi Dữ Liệu (PaymentService):

    • Sử dụng Outbox Pattern để đảm bảo COMMIT của account và event là nguyên tử.
    • Sử dụng Sharding Database theo account_id để xử lý tải ghi cao.

  2. Tầng Vận Chuyển (Message Broker):

    • Apache Kafka với 100 partitions.
    • Partition Key là account_id. Điều này đảm bảo các sự kiện của cùng một tài khoản được xử lý tuần tự, tránh race condition khi cập nhật số dư hoặc hạn mức.

  3. Tầng Tiêu Thụ (LedgerService & RiskService):

    • Idempotent Consumer: Mọi consumer đều phải check Idempotency Key trước khi ghi DB.
    • SAGA Orchestrator: Theo dõi trạng thái giao dịch. Nếu LedgerService không thể ghi nhận sau N lần retry, Orchestrator sẽ kích hoạt luồng bù trừ (hoàn tiền).

  4. Xử lý lỗi không thể hoàn tác:

    • Ví dụ: SMS đã gửi đi với nội dung “Thanh toán thành công”.
    • Giải pháp: Không thể unsend SMS. Hệ thống gửi một SMS mới: “Giao dịch trước đó đã bị hủy do lỗi hệ thống. Vui lòng kiểm tra lại số dư.”

9. Kết luận

Distributed Transaction trong Microservices không có “viên đạn bạc”. 2PC mang lại sự an toàn nhưng đánh đổi bằng hiệu năng và khả năng chịu lỗi. SAGA và Eventual Consistency mang lại khả năng mở rộng vượt trội nhưng đòi hỏi tư duy thiết kế cẩn thận về Compensation và Idempotency.

Nếu bạn đang xây dựng một hệ thống tài chính lõi, hãy ghi nhớ:

  • Outbox Pattern là bắt buộc để tránh mất sự kiện.
  • Idempotency Key là lá chắn cuối cùng bảo vệ sổ sách của bạn.
  • Hãy chuẩn bị tinh thần rằng SMS không thể thu hồi, và luôn có kịch bản xử lý thủ công cho những trường hợp hy hữu nhất.

Hy vọng bài viết giúp bạn tự tin hơn khi đối mặt với bài toán hóc búa này trong các dự án thực tế.

Hãy kết nối

Nếu bạn quan tâm tới việc hợp tác, có câu hỏi về bài viết, hay chỉ đơn giản muốn chuyện trò về backend — cứ ping mình nhé.

GitHubGửi email