Trong kiến trúc SOA, khi các dịch vụ phân tán cần duy trì tính nhất quán dữ liệu xuyên suốt qua nhiều transaction độc lập, tại sao việc sử dụng mô hình Distributed Transactions truyền thống dựa trên Two-Phase Commit lại không còn phù hợp, và giải pháp Sagas Pattern được thiết kế để giải quyết bài toán này như thế nào?

Question

Accepted Answer

Bản chất vấn đề
Trong hệ thống SOA, mỗi dịch vụ sở hữu cơ sở dữ liệu riêng biệt. Khi một nghiệp vụ nghiệp vụ nghiệp vụ nghiệp nghiệp vụ (Business Transaction) đi qua nhiều dịch vụ, việc đảm bảo tính nhất quán là tối quan trọng. 
Tại sao Two-Phase Commit (2PC) thất bại trong SOA

Khóa tài nguyên (Resource Locking): 2PC yêu cầu giữ khóa trên tất cả các cơ sở dữ liệu tham gia cho đến khi toàn bộ quá trình hoàn tất. Điều này làm giảm nghiêm trọng tính sẵn sàng (Availability) và hiệu năng của hệ thống phân tán.
Điểm lỗi đơn (Single Point of Failure): Coordinator quản lý transaction nếu gặp sự cố sẽ khiến toàn bộ hệ thống bị treo ở trạng thái không xác định.
Độ trễ mạng cao: Hệ thống SOA thường có độ trễ mạng lớn hơn hệ thống monolithic, làm tăng thời gian giữ khóa.

Giải pháp Sagas Pattern
Sagas Pattern thay thế Distributed Transactions đồng bộ bằng một chuỗi các Local Transactions tuần tự hoặc bất đồng bộ. Mỗi bước cập nhật dữ liệu trên một dịch vụ và phát ra một Event hoặc Message để kích hoạt bước tiếp theo.

Choreography-based Saga: Các dịch vụ tự lắng nghe sự kiện và thực hiện bước tiếp theo mà không cần bộ điều phối trung tâm.
Orchestration-based Saga: Một Saga Orchestrator chịu trách nhiệm điều phối toàn bộ luồng nghiệp vụ, gọi lần lượt các dịch vụ và xử lý logic.

Cơ chế Compensating Transactions
Vì các local transaction đã được commit ngay lập tức, khi một bước nào đó ở giữa chuỗi thất bại, hệ thống không thể rollback trực tiếp. Thay vào đó, Sagas sử dụng Compensating Transactions (Giao dịch bù trừ) để thực hiện các thao tác ngược lại nhằm đưa trạng thái hệ thống về mốc an toàn ban đầu (Ví dụ: Bước tạo đơn hàng thành công, bước thanh toán thất bại thì gọi bù trừ là hủy đơn hàng).
Kinh nghiệm thực chiến
Khi thiết kế Sagas Pattern ở cấp độ Middle, lập trình viên cần lưu ý:

Đảm bảo tính Idempotency cho mọi Compensating Transactions để tránh lỗi khi thực hiện lặp lại.
Chấp nhận tính nhất quán cuối cùng (Eventual Consistency) thay vì tính nhất quán mạnh (Strong Consistency).
Xây dựng cơ chế Dead Letter Queue (DLQ) để xử lý các Compensating Transactions gặp lỗi ngoại lệ liên tục.

Bản chất vấn đề

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi soa liên quan cùng chủ đề