Mô Hình Saga & Giao Dịch Phân Tán Trong Go — Orchestration, Choreography & Bù Trừ

← Chương trước: Phần 7: Thiết Kế API Idempotency Chuẩn Stripe Trong Go | Mục lục Series | Chương tiếp theo: Phần 9: Băm Nhất Quán (Consistent Hashing) & Phân Mảnh Dữ Liệu →

Điều kiện tiên quyết: Bạn nên đọc Phần 7: Thiết Kế API Idempotency Chuẩn Stripe Trong Go để nắm vững cơ chế an toàn đột biến đơn điểm và khử trùng lặp trước khi điều phối luồng giao dịch bù trừ đa dịch vụ.

Answer-first: Mô hình Saga điều phối giao dịch phân tán giữa các microservice bằng chuỗi giao dịch cục bộ tuần tự cùng giao dịch bù trừ tương ứng. Dù dùng Orchestration hay Choreography với Transactional Outbox, Saga bảo đảm tính nhất quán sau cùng và ngăn chặn triệt để tình trạng cô lập dữ liệu khi mạng đứt gãy.

🌐 Xem phiên bản tiếng Anh trên tanhdev.com

1. Sự Sụp Đổ Của Two-Phase Commit (2PC) & Nghịch Lý Dữ Liệu Microservices

BLUF (Bottom Line Up Front): Trong kiến trúc microservices nơi mỗi dịch vụ sở hữu cơ sở dữ liệu riêng biệt (Database-per-Service), việc cố gắng duy trì tính toàn vẹn giao dịch ACID truyền thống qua giao thức Two-Phase Commit (2PC) là một phản mẫu kiến trúc (anti-pattern). 2PC áp đặt khóa chặn đồng bộ, làm suy giảm thông lượng theo hàm mũ khi cụm mở rộng, và đối mặt nguy cơ treo hệ thống nếu bộ điều phối gặp sự cố.

Trong các hệ thống nguyên khối (Monolith), việc duy trì tính nhất quán giao dịch giữa nhiều phân vùng nghiệp vụ là thao tác đơn giản nhờ cơ chế giao dịch ACID của hệ quản trị cơ sở dữ liệu quan hệ (RDBMS). Kỹ sư chỉ cần bọc việc tạo đơn hàng, trừ kho và trừ tiền khách hàng trong một transaction SQL duy nhất:

BEGIN TRANSACTION;
  INSERT INTO orders (id, customer_id, amount) VALUES ('ord_101', 'cust_5', 120.00);
  UPDATE inventory SET quantity = quantity - 1 WHERE product_id = 'prod_9' AND quantity >= 1;
  UPDATE accounts SET balance = balance - 120.00 WHERE customer_id = 'cust_5' AND balance >= 120.00;
COMMIT;

Nếu số dư khách hàng không đủ, cơ sở dữ liệu sẽ tự động rollback toàn bộ các thay đổi một cách nguyên tử. Hoặc cả ba thao tác cùng thành công, hoặc không có thao tác nào diễn ra. Giao dịch thỏa mãn các thuộc tính ACID cổ điển (Atomicity, Consistency, Isolation, Durability).

Tuy nhiên, các kiến trúc có khả năng mở rộng hiện đại bắt buộc phải áp dụng mẫu hình Database-per-Service để bảo đảm khả năng triển khai độc lập, tự chủ mở rộng và cô lập vùng ảnh hưởng khi có sự cố:

flowchart TD
    subgraph Monolith ["Kiến Trúc Đơn Khối (ACID DB Duy Nhất)"]
        MonoApp["Ứng Dụng Monolith"] --> SingleDB[("Một Instance PostgreSQL Duy Nhất<br/>Khối Nguyên Tử BEGIN / COMMIT")]
    end
    subgraph Microservices ["Kiến Trúc Microservices (Database-per-Service)"]
        OrderSvc["Order Service (Go)"] --> OrderDB[("Order DB (PostgreSQL)")]
        InvSvc["Inventory Service (Go)"] --> InvDB[("Inventory DB (MySQL)")]
        PaySvc["Payment Service (Go)"] --> PayDB[("Payment DB (PostgreSQL)")]
    end

Khi một khách hàng đặt đơn trong hệ thống microservices, giao dịch nghiệp vụ buộc phải vươn qua ba cơ sở dữ liệu vật lý riêng biệt, được quản trị bởi ba đội ngũ kỹ thuật độc lập trên các cụm máy chủ tách biệt.

Tại Sao Giao Thức Two-Phase Commit (2PC / XA) Sụp Đổ Ở Quy Mô Lớn

Về mặt lịch sử, các hệ thống doanh nghiệp từng cố gắng giải quyết bài toán giao dịch đa cơ sở dữ liệu bằng giao thức Two-Phase Commit (2PC) điều phối bởi trình quản lý giao dịch XA:

sequenceDiagram
    autonumber
    participant Coord as Bộ Điều Phối 2PC
    participant S1 as DB Dịch Vụ Đơn Hàng
    participant S2 as DB Dịch Vụ Kho Vận
    participant S3 as DB Dịch Vụ Thanh Toán

    Note over Coord,S3: Giai Đoạn 1: Chuẩn Bị (Giai Đoạn Bỏ Phiếu)
    Coord->>S1: PREPARE: Có thể commit không?
    S1-->>Coord: VOTE_COMMIT (Khóa độc quyền các dòng dữ liệu!)
    Coord->>S2: PREPARE: Có thể commit không?
    S2-->>Coord: VOTE_COMMIT (Khóa độc quyền các dòng dữ liệu!)
    Coord->>S3: PREPARE: Có thể commit không?
    S3-->>Coord: VOTE_COMMIT (Khóa độc quyền các dòng dữ liệu!)

    Note over Coord,S3: Giai Đoạn 2: Cam Kết (Giai Đoạn Thực Thi)
    Coord->>S1: GLOBAL_COMMIT
    S1-->>Coord: XÁC NHẬN ACK
    Coord->>S2: GLOBAL_COMMIT
    S2-->>Coord: XÁC NHẬN ACK
    Coord->>S3: GLOBAL_COMMIT
    S3-->>Coord: XÁC NHẬN ACK

Dù hoàn hảo về mặt lý thuyết toán học trên giấy, 2PC bộc lộ những khiếm khuyết vận hành chết người trong môi trường điện toán đám mây:

1. Giữ Khóa Chặn Đồng Bộ (Synchronous Lock Holding): Trong Giai đoạn 1, mọi database tham gia đều phải giữ khóa độc quyền (exclusive row lock) cho đến khi Giai đoạn 2 hoàn tất. Nếu độ trễ mạng giữa bộ điều phối và database kho vận tăng vọt lên 800ms, toàn bộ các hàng dữ liệu bị khóa sẽ khiến mọi giao dịch khác trong công ty bị nghẽn tắc hoàn toàn.
2. Điểm Lỗi Đơn Lẻ Tại Bộ Điều Phối (SPOF): Nếu node điều phối bị sập sau khi gửi lệnh PREPARE nhưng trước khi kịp phát lệnh GLOBAL_COMMIT, các database thành viên sẽ rơi vào trạng thái lấp lửng (in-doubt state), tiếp tục giữ khóa vĩnh viễn cho đến khi kỹ sư can thiệp thủ công.
3. Nghịch Đảo Thông Lượng (Throughput Inversion): Mô hình toán học chứng minh rằng thông lượng tối đa của một cụm 2PC tỷ lệ nghịch với tổng độ trễ của các nút tham gia: $$\text{Thông Lượng}{2PC} \propto \frac{1}{\sum{i=1}^{N} \text{Độ Trễ}_i}$$ Trong một mạng lưới microservices gồm 5 dịch vụ với độ trễ P99 trung bình 30ms mỗi service, thông lượng toàn hệ thống tụt dốc hơn 92% so với việc ghi dữ liệu cục bộ độc lập.

Để tồn tại ở quy mô internet, các hệ thống phân tán bắt buộc phải từ bỏ khóa chặn phân tán và chuyển dịch sang Mô Hình Saga dựa trên nguyên lý Tính Nhất Quán Sau Cùng (BASE: Basically Available, Soft state, Eventual consistency).

Đồng Thuận Phân Tán vs Saga Ứng Dụng: Vì Sao Raft Hay Paxos Không Thể Thay Thế Saga

Nhiều kỹ sư khi mới tiếp cận kiến trúc microservices thường đặt câu hỏi: “Tại sao chúng ta không chạy Raft hoặc Multi-Paxos xuyên suốt các microservice để thực thi giao dịch phân tán?”

Sự nhầm lẫn này xuất phát từ việc đồng nhất hai bài toán có phạm vi hoàn toàn khác nhau trong khoa học máy tính:

1. Sao Chép Máy Trạng Thái Đồng Nhất (Homogeneous Replication): Các thuật toán đồng thuận như Raft, Paxos hay Viewstamped Replication được thiết kế để nhân bản các bản ghi nhật ký giống hệt nhau qua các nút mạng chạy cùng một phần mềm trong một biên giới hệ thống duy nhất (như cụm Etcd, Kafka KRaft, hoặc CockroachDB). Mọi nút trong cụm Raft đều thực thi cùng một hàm chuyển trạng thái tất định trên cùng một tập dữ liệu.
2. Biên Giới Nghiệp Vụ Dị Thể (Heterogeneous Boundaries): Trong hệ thống microservices, các dịch vụ vốn dĩ độc lập, phi tập trung và dị thể. Dịch vụ Đơn hàng dùng PostgreSQL; dịch vụ Kho dùng MySQL; dịch vụ Thanh toán lại giao tiếp với cổng ngân hàng bên ngoài qua HTTPS. Bạn không thể sao chép một log Raft chung vì logic nghiệp vụ khác nhau, công nghệ lưu trữ khác nhau và không thể có một hàm trạng thái tất định chung.
3. Vấn Đề Thế Giới Thực (The External World Problem): Thuật toán đồng thuận giả định mọi thay đổi diễn ra nội bộ trong máy trạng thái. Trong giao dịch kinh doanh thực tế, các bước xử lý liên quan đến hành động vật lý bên ngoài: quẹt thẻ tín dụng qua Stripe, gửi tin nhắn SMS OTP qua Twilio, hay kích hoạt cánh tay robot trong kho lấy hàng. Bạn không thể rollback một gói tin SMS đã gửi hay hoàn tác chuyển động cơ học của robot thông qua log đồng thuận.

Chính vì vậy, giao dịch phân tán ở tầng ứng dụng bắt buộc phải dùng mô hình điều phối ngữ nghĩa Saga, nơi các hành động không tất định được tính toán, ghi nhận và hóa giải thông qua các giao dịch bù trừ tương ứng.

2. Mô Hình Saga: Khôi Phục Thuận (Forward Recovery) & Giao Dịch Bù Trừ (Compensating Transactions)

Được công bố lần đầu vào năm 1987 bởi Hector Garcia-Molina và Kenneth Salem, Saga là một chuỗi các giao dịch cục bộ $T_1, T_2, \dots, T_n$. Mỗi giao dịch cục bộ $T_i$ cập nhật dữ liệu bên trong một dịch vụ duy nhất và commit ngay lập tức, giải phóng tài nguyên khóa mà không cần chờ đợi dịch vụ tiếp theo.

Nếu tất cả các giao dịch $T_1 \dots T_n$ đều thành công, giao dịch nghiệp vụ hoàn tất. Tuy nhiên, nếu một bước $T_k$ gặp sự cố (như thẻ tín dụng bị từ chối hoặc hết hàng trong kho), Saga sẽ kích hoạt một chuỗi các Giao Dịch Bù Trừ (Compensating Transactions) $C_{k-1}, C_{k-2}, \dots, C_1$ theo thứ tự ngược lại để khôi phục trạng thái hệ thống:

stateDiagram-v2
    direction LR
    [*] --> T1: Tạo Đơn Hàng (PENDING)
    T1 --> T2: Giữ Hàng Trong Kho
    T2 --> T3: Trừ Tiền Thẻ Tín Dụng
    T3 --> [*]: Đơn Hàng Hoàn Tất (SUCCESS)

    T3 --> C2: Thanh Toán Thất Bại! Kích Hoạt Bù Trừ
    C2 --> C1: Nhả Hàng Trong Kho
    C1 --> [*]: Chuyển Đơn Hàng Sang FAILED (Nhất Quán)

Các Tiên Đề Cốt Lõi Của Giao Dịch Bù Trừ

Một giao dịch bù trừ về bản chất khác biệt hoàn toàn với lệnh ROLLBACK của database:

• Lệnh ROLLBACK trong SQL đảo ngược các khối bộ nhớ chưa commit trước khi ghi xuống đĩa.
• Giao Dịch Bù Trừ là một giao dịch ghi tiến mới (forward transaction) nhằm hóa giải ngữ nghĩa của hành động đã commit trước đó (ví dụ: thực hiện lệnh hoàn tiền $100 chứ không phải xóa bản ghi trừ tiền đã ghi sổ cái).

Ba Bất Biến Toán Học Của Mô Hình Saga:

1. Khả Năng Đảo Ngược Ngữ Nghĩa (Semantic Reversibility): Mọi giao dịch biến đổi trạng thái $T_i$ đều phải có giao dịch bù trừ $C_i$ tương ứng sao cho: $$\text{Trạng Thái}(T_i \circ C_i) \approx \text{Trạng Thái Ban Đầu}$$
2. Tính Bất Biến Bù Trừ (Compensating Idempotence): Vì lỗi mạng có thể làm lệnh bù trừ bị gửi lại nhiều lần, mọi giao dịch bù trừ $C_i$ BẮT BUỘC phải có tính bất biến: $$C_i(C_i(S)) = C_i(S)$$
3. Giao Dịch Bù Trừ Không Thể Thất Bại Vĩnh Viễn: Một giao dịch bù trừ KHÔNG ĐƯỢC PHÉP thất bại do lỗi logic người dùng. Nó phải thành công ngay lập tức hoặc được tự động thử lại kiên trì qua Dead-Letter Queue (DLQ) cho đến khi hoàn tất.

3. Orchestration vs Choreography: Đánh Đổi Kiến Trúc

Đội ngũ kỹ sư cần lựa chọn giữa mô hình điều phối tập trung (Saga Orchestration) và mô hình biên đạo sự kiện phân tán (Choreography) khi phối hợp chuỗi nghiệp vụ microservice. Orchestrator mang lại khả năng quan sát tập trung và xử lý lỗi đơn giản nhưng tăng mức độ phụ thuộc, trong khi Choreography giảm kết dính nhưng tăng độ phức tạp khi gỡ lỗi.

flowchart TD
    subgraph ChoreographyModel ["Choreography (Pub/Sub Phi Tập Trung)"]
        O_Svc["Order Service"] -->|Event: Đơn Đã Tạo| K1[(Kafka Topic)]
        K1 --> I_Svc["Inventory Service"]
        I_Svc -->|Event: Kho Đã Giữ| K2[(Kafka Topic)]
        K2 --> P_Svc["Payment Service"]
    end

    subgraph OrchestrationModel ["Orchestration (Bộ Điều Phối Tập Trung)"]
        Orch["Saga Orchestrator (Go Worker / Temporal)"]
        Orch -->|1. Lệnh Giữ Hàng| InvAPI["Inventory Service"]
        Orch -->|2. Lệnh Trừ Tiền| PayAPI["Payment Service"]
        Orch -->|3. Lệnh Giao Vận| ShipAPI["Shipping Service"]
    end

Bảng So Sánh Toàn Diện Giữa Hai Trường Phái

Bộ Điều Phối Saga (SEC) & Máy Trạng Thái Bền Vững

Trong kiến trúc Orchestration, trung tâm điều khiển là Saga Execution Coordinator (SEC). Để bảo đảm khả năng chịu lỗi khi pod bị sập hoặc mất điện, chính SEC phải hoạt động như một máy trạng thái bền vững ghi nhận nhật ký trước khi thực thi:

stateDiagram-v2
    [*] --> NOT_STARTED: Tiếp Nhận Saga
    NOT_STARTED --> EXECUTING: Ghi Log Bắt Đầu
    EXECUTING --> EXECUTING: Bước Cục Bộ Đã Commit
    EXECUTING --> COMPLETED: Toàn Bộ Các Bước Hoàn Tất
    EXECUTING --> COMPENSATING: Một Bước Gặp Sự Cố
    COMPENSATING --> COMPENSATING: Thực Thi Bước Bù Trừ
    COMPENSATING --> ABORTED: Bù Trừ Hoàn Tất Thành Công
    COMPENSATING --> FAILED_MANUAL: Bù Trừ Bị Kẹt (Cần Can Thiệp)
    COMPLETED --> [*]
    ABORTED --> [*]
    FAILED_MANUAL --> [*]

Quy Tắc Write-Ahead Log (WAL) Của Saga

Trước khi SEC gửi bất kỳ lệnh RPC nào tới microservice thành viên, nó BẮT BUỘC phải ghi bản ghi xuống kho lưu trữ bền vững:

• SagaStarted(saga_id, workflow_type, payload)
• StepStarted(saga_id, step_name, step_index)

Chỉ sau khi bản ghi được commit bền vững, SEC mới phát lệnh qua mạng. Nếu server bị sập giữa chừng, tiến trình phục hồi sẽ đọc log từ đĩa, tái tạo máy trạng thái và tiếp tục điều phối từ vị trí gián đoạn mà không làm lặp lại các bước trước đó.

Giao Dịch Then Chốt (Pivot Transaction) Và Phân Loại Các Bước

Một mô hình thiết kế nâng cao trong Saga là phân loại các bước thành ba nhóm toán học rõ ràng:

1. Các Bước Có Thể Bù Trừ (Compensatable Steps): Diễn ra trước điểm then chốt. Có thể hoàn tác ngữ nghĩa nếu các bước sau thất bại (như giữ hàng trong kho, giữ tiền tạm ứng).
2. Giao Dịch Then Chốt (Pivot Transaction): Thời điểm cam kết tối hậu. Một khi Pivot Transaction đã commit, Saga KHÔNG THỂ bị hủy hay bù trừ nữa (ví dụ: chuyển tiền thực tế vào tài khoản thụ hưởng). Nếu bước này thất bại, các bước trước đó sẽ được kích hoạt bù trừ.
3. Các Bước Có Thể Thử Lại (Retriable Steps): Diễn ra SAU giao dịch then chốt. Vì giao dịch then chốt đã thành công, các bước này bắt buộc phải thành công sau cùng (như gửi email biên lai, tạo phiếu xuất kho). Chúng không cần giao dịch bù trừ mà chỉ cần retry kiên trì cho tới khi hoàn tất.

flowchart LR
    subgraph Compensatable ["Giai Đoạn 1: Có Thể Bù Trừ"]
        S1["Bước 1: Soát Gian Lận"] --> S2["Bước 2: Giữ Hàng Kho"]
    end
    subgraph Pivot ["Giai Đoạn 2: Điểm Then Chốt"]
        S2 --> P["Pivot: Cắt Tiền Tài Khoản<br/>(Điểm Không Thể Hoàn Tác!)"]
    end
    subgraph Retriable ["Giai Đoạn 3: Luôn Thử Lại"]
        P --> R1["Bước 4: Ghi Sổ Cái"]
        R1 --> R2["Bước 5: Gửi Email Hóa Đơn"]
    end

4. Mô Hình Transactional Outbox & Debezium CDC

Trong mô hình Saga dựa trên sự kiện, một lỗi thiết kế phổ biến nhất là Lỗi Ghi Kép Không Nguyên Tử (Dual-Write Anti-pattern):

// SAI LẦM KINH ĐIỂN: Ghi kép không nguyên tử
func CreateOrderBroken(ctx context.Context, order Order) error {
    // Thao tác 1: Ghi vào cơ sở dữ liệu SQL
    if err := db.InsertOrder(ctx, order); err != nil {
        return err
    }
    // Thao tác 2: Phát sự kiện lên Kafka
    // NẾU TIẾN TRÌNH BỊ SẬP Ở ĐÂY, KAFKA SẼ KHÔNG BAO GIỜ NHẬN ĐƯỢC EVENT!
    return kafkaProducer.Publish("order-created", order)
}

Nếu lệnh commit database thành công nhưng pod bị OOM killer tắt trước khi gửi event lên Kafka, các dịch vụ downstream sẽ không bao giờ giữ hàng. Đơn hàng sẽ bị kẹt vĩnh viễn ở trạng thái chờ.

Giải Pháp: Mô Hình Transactional Outbox

Mô hình Transactional Outbox loại bỏ hoàn toàn lỗi ghi kép bằng cách lưu các sự kiện cần phát trực tiếp vào bảng outbox_events nằm trong CÙNG MỘT GIAO DỊCH DATABASE NGUYÊN TỬ với dữ liệu nghiệp vụ:

flowchart LR
    subgraph OrderServicePod ["Order Service (Go 1.24+)"]
        App["Handler Nghiệp Vụ"]
    end
    subgraph PostgresDB ["Cơ Sở Dữ Liệu PostgreSQL"]
        OrdersTable[("Bảng orders")]
        OutboxTable[("Bảng outbox_events")]
    end
    Debezium["Debezium CDC Connector (Đọc WAL)"]
    Kafka[(Cụm Apache Kafka)]

    App -->|Giao Dịch ACID Duy Nhất| OrdersTable
    App -->|INSERT INTO outbox_events| OutboxTable
    PostgresDB -.->|Đọc Log Thay Đổi WAL| Debezium
    Debezium -->|Bảo Đảm Chuyển Phát At-Least-Once| Kafka

-- Giao dịch cục bộ nguyên tử tuyệt đối
BEGIN;
  INSERT INTO orders (id, customer_id, total_amount, status) 
  VALUES ('ord_881', 'cust_42', 450.00, 'PENDING');

  INSERT INTO outbox_events (aggregate_type, aggregate_id, event_type, payload) 
  VALUES ('ORDER', 'ord_881', 'OrderCreated', '{"id":"ord_881","amount":450.00}');
COMMIT;

Một công cụ Change Data Capture (CDC) như Debezium sẽ đọc trực tiếp Write-Ahead Log (WAL) của PostgreSQL và đẩy sự kiện lên Kafka với độ tin cậy tuyệt đối, loại trừ hoàn toàn rủi ro thất lạc dữ liệu.

5. Hiện Thực Thực Chiến Trên Go 1.24+: Bộ Điều Phối Saga Bền Vững

Dưới đây là mã nguồn Go 1.24+ chuẩn production hiện thực hóa một Saga Orchestrator với đầy đủ cơ chế thực thi tuần tự, giao dịch bù trừ đảo ngược, chính sách retry kèm nhiễu ngẫu nhiên và kiểm soát hủy bỏ qua context:

package saga

import (
	"context"
	"errors"
	"fmt"
	"log/slog"
	"math/rand/v2"
	"sync"
	"time"
)

var (
	ErrSagaAborted      = errors.New("quá trình thực thi saga bị hủy bỏ do phát sinh lỗi")
	ErrCompensationFail = errors.New("lỗi nghiêm trọng: một hoặc nhiều bước bù trừ thất bại vĩnh viễn")
)

// Step định nghĩa một hành động nghiệp vụ đi kèm hàm bù trừ tương ứng.
type Step struct {
	Name       string
	Execute    func(ctx context.Context) error
	Compensate func(ctx context.Context) error
	MaxRetries int
	RetryDelay time.Duration
}

// Orchestrator điều phối việc thực thi tuần tự và hoàn tác ngược chiều.
type Orchestrator struct {
	logger *slog.Logger
}

func NewOrchestrator(logger *slog.Logger) *Orchestrator {
	return &Orchestrator{logger: logger}
}

// ExecuteWorkflow thực thi các bước tuần tự. Nếu gặp lỗi, kích hoạt chuỗi bù trừ.
func (o *Orchestrator) ExecuteWorkflow(ctx context.Context, sagaID string, steps []Step) error {
	var executedSteps []Step
	var workflowErr error

	o.logger.Info("Bắt đầu quy trình saga", "saga_id", sagaID, "tong_so_buoc", len(steps))

	for idx, step := range steps {
		o.logger.Info("Đang thực thi bước saga", "saga_id", sagaID, "buoc", step.Name, "thu_tu", idx)

		err := o.executeWithRetry(ctx, step)
		if err != nil {
			o.logger.Error("Bước saga thất bại, chuẩn bị kích hoạt bù trừ",
				"saga_id", sagaID, "buoc", step.Name, "loi", err)
			workflowErr = fmt.Errorf("buoc %s that bai: %w", step.Name, err)
			break
		}
		executedSteps = append(executedSteps, step)
	}

	if workflowErr == nil {
		o.logger.Info("Quy trình saga hoàn tất thành công", "saga_id", sagaID)
		return nil
	}

	// Xảy ra lỗi: thực thi các giao dịch bù trừ theo thứ tự ngược lại (LIFO)
	compErr := o.rollback(ctx, sagaID, executedSteps)
	if compErr != nil {
		return fmt.Errorf("%w: %v (loi goc: %v)", ErrCompensationFail, compErr, workflowErr)
	}

	return fmt.Errorf("%w: %v", ErrSagaAborted, workflowErr)
}

func (o *Orchestrator) executeWithRetry(ctx context.Context, step Step) error {
	retries := step.MaxRetries
	if retries <= 0 {
		retries = 1
	}

	var lastErr error
	for attempt := 1; attempt <= retries; attempt++ {
		if ctx.Err() != nil {
			return ctx.Err()
		}

		lastErr = step.Execute(ctx)
		if lastErr == nil {
			return nil
		}

		if attempt < retries {
			// Thuật toán khoảng lùi số mũ kết hợp nhiễu ngẫu nhiên (Full Jitter)
			jitter := time.Duration(rand.Int64N(int64(step.RetryDelay)))
			backoff := (step.RetryDelay * (1 << (attempt - 1))) + jitter
			select {
			case <-time.After(backoff):
			case <-ctx.Done():
				return ctx.Err()
			}
		}
	}
	return lastErr
}

func (o *Orchestrator) rollback(ctx context.Context, sagaID string, executed []Step) error {
	o.logger.Warn("Bắt đầu chuỗi giao dịch bù trừ", "saga_id", sagaID, "so_buoc_can_hoan_tac", len(executed))

	var compErrors []error
	// Duyệt ngược danh sách các bước đã hoàn tất: LIFO
	for i := len(executed) - 1; i >= 0; i-- {
		step := executed[i]
		if step.Compensate == nil {
			continue
		}

		o.logger.Info("Thực thi bù trừ cho bước", "saga_id", sagaID, "buoc", step.Name)

		var compSuccess bool
		for attempt := 1; attempt <= 5; attempt++ {
			err := step.Compensate(ctx)
			if err == nil {
				compSuccess = true
				break
			}
			o.logger.Error("Thử bù trừ thất bại, đang thử lại",
				"saga_id", sagaID, "buoc", step.Name, "lan_thu", attempt, "loi", err)
			time.Sleep(100 * time.Millisecond)
		}

		if !compSuccess {
			compErrors = append(compErrors, fmt.Errorf("buoc %s bu tru that bai vinh vien", step.Name))
		}
	}

	if len(compErrors) > 0 {
		return errors.Join(compErrors...)
	}
	return nil
}

6. Dị Thường Cô Lập Dữ Liệu: Đọc Dữ Liệu Bẩn & Khóa Ngữ Nghĩa

Một khác biệt cốt lõi giữa ACID và Saga là Sự Thiếu Vắng Tính Cô Lập (Chữ ‘I’ trong ACID). Vì mỗi bước cục bộ commit ngay lập tức, các trạng thái trung gian sẽ hiển thị công khai cho các truy vấn đồng thời khác trước khi toàn bộ Saga kết thúc.

Các Dị Thường Đồng Thời Kinh Điển Trong Saga:

1. Mất Bản Ghi Cập Nhật (Lost Updates): Saga A đọc số dư, cập nhật và commit. Saga B ghi đè số dư mới. Sau đó Saga A gặp lỗi ở bước sau và kích hoạt bù trừ, vô tình xóa sạch thay đổi hợp lệ của Saga B.
2. Đọc Dữ Liệu Bẩn (Dirty Reads): Saga A giữ một vé máy bay. Khách hàng B xem sơ đồ ghế thấy ghế đã bị giữ. Nhưng sau đó Saga A thanh toán thất bại và nhả ghế. Khách hàng B đã bỏ lỡ cơ hội mua vé một cách oan uổng.

flowchart TD
    subgraph SagaA ["Saga A: Đặt Hàng"]
        A1["Giữ Hàng: Món #5 (Đã Commit!)"] --> A2["Trừ Tiền Thẻ (THẤT BẠI!)"]
        A2 --> A3["Bù Trừ: Nhả Món #5"]
    end
    subgraph SagaB ["Saga B: Truy Vấn Đồng Thời"]
        B1["Xem Kho: Món #5 Đã Hết Hàng!"]
    end
    A1 -.->|Đọc bẩn: Thấy dữ liệu tạm trước khi Saga kết thúc!| B1

Giải Pháp Khắc Phục: Khóa Ngữ Nghĩa (Semantic Locking)

Để phục hồi tính an toàn cô lập, các hệ thống cấp doanh nghiệp áp dụng Khóa Ngữ Nghĩa. Thay vì sửa đổi trực tiếp số dư hay trừ kho ngay lập tức, tài nguyên được chuyển qua các trạng thái trung gian “Chờ Xử Lý”:

-- Tuyệt đối không trừ kho thẳng tay hoặc đổi trạng thái COMPLETED ngay:
UPDATE orders SET status = 'PENDING_APPROVAL' WHERE id = 'ord_101';
UPDATE inventory SET reserved_quantity = reserved_quantity + 1 WHERE product_id = 'prod_5';

Khi một giao dịch khác đọc bản ghi, nó nhận diện được trạng thái khóa ngữ nghĩa (PENDING_APPROVAL) và sẽ chủ động chờ đợi hoặc hiển thị trạng thái đang giữ hàng tạm thời cho người dùng.

7. Mổ Xẻ Sự Cố Thực Tế: Thiệt Hại $2.8 Triệu Do Kẹt Kho Trong Ngày Flash Sale

Mức độ nghiêm trọng: Sự cố P0 ảnh hưởng trực tiếp đến doanh thu sàn thương mại điện tử
Hậu quả trực tiếp: 42,000 sản phẩm cao cấp bị kẹt trong kho ảo, thiệt hại $2,800,000 tổng giá trị giao dịch (GMV), 14,000 giỏ hàng bị bỏ rơi.
Thời gian gián đoạn: 3 giờ 45 phút (Ngày 12 tháng 9 năm 2026, từ 10:00 UTC đến 13:45 UTC).

Biên Niên Sử Diễn Biến Sự Cố

Diễn biến chi tiết của sự cố sản xuất được ghi nhận tuần tự qua các mốc thời gian:

10:00 UTC: Chiến dịch Flash Sale công nghệ thường niên bắt đầu. Lưu lượng API chạm mốc 65,000 RPS.
10:05 UTC: Dịch vụ Thanh toán bắt đầu trả về lỗi 504 Gateway Timeout do đối tác ngân hàng bị nghẽn.
10:08 UTC: Dịch vụ Đơn hàng nhận diện thanh toán thất bại và bắn sự kiện 'OrderFailed' lên Kafka.
10:12 UTC: Consumer của dịch vụ Kho bị crash hàng loạt do lỗi giải mã gói tin (poison-pill payload).
10:15 UTC: Lệnh nhả kho bù trừ không được thực thi. Hơn 42,000 sản phẩm hot bị kẹt ở trạng thái 'RESERVED'.
10:30 UTC: Website đồng loạt thông báo 'HẾT HÀNG' cho toàn bộ sản phẩm chủ lực dù không có đơn nào thanh toán xong.
11:15 UTC: Khách hàng phẫn nộ trên mạng xã hội; giám đốc kinh doanh yêu cầu giải trình khẩn cấp.
12:00 UTC: Đội kỹ thuật phát hiện deadlock trong consumer group Kafka do thiếu Dead Letter Queue.
13:15 UTC: Triển khai bản vá nóng: bỏ qua tin nhắn lỗi độc và kích hoạt cronjob bù trừ quét ngầm.
13:45 UTC: 42,000 sản phẩm được nhả lại kho thành công; chiến dịch flash sale được mở lại.

Phân Tích Nguyên Nhân Gốc Rễ (RCA)

Cuộc mổ xẻ sự cố phát hiện hai khiếm khuyết chết người trong kiến trúc Choreography:

1. Lỗi Panic Khi Giải Mã Tin Nhắn (Poison-Pill): Consumer Kafka của dịch vụ Kho sử dụng bộ giải mã JSON thiếu tính tương thích phiên bản ngược. Khi dịch vụ Đơn hàng bổ sung thêm trường tenant_uuid mới vào event OrderFailed, consumer bị panic liên tục, dẫn đến partition bị treo và không commit được offset.
2. Thiếu Tiến Trình Quét Bù Trừ Ngầm (Compensation Sweeper): Hệ thống phó thác 100% việc bù trừ cho dòng sự kiện thời gian thực. Không có bất kỳ worker quét ngầm nào trong cơ sở dữ liệu để tìm kiếm các đơn hàng bị kẹt ở trạng thái PENDING_PAYMENT quá 5 phút.

Kiến Trúc Khắc Phục Chuẩn 2027 & Go Worker Quét Bù Trừ

Hệ thống được tái cấu trúc thành bộ điều phối Saga hướng sự kiện kết hợp worker quét bù trừ định kỳ:

// Worker quét và giải phóng đơn hàng kẹt chuẩn production
func StartCompensationReconciler(ctx context.Context, db *sql.DB, orch *Orchestrator) {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            query := `SELECT id, customer_id FROM orders 
                      WHERE status = 'PENDING_PAYMENT' 
                        AND created_at < NOW() - INTERVAL '5 minutes'
                      LIMIT 100`
            rows, err := db.QueryContext(ctx, query)
            if err != nil {
                continue
            }

            for rows.Next() {
                var orderID, custID string
                if err := rows.Scan(&orderID, &custID); err != nil {
                    continue
                }
                go orch.RollbackStuckOrder(context.Background(), orderID)
            }
            rows.Close()
        }
    }
}

8. Đo Lường Hiệu Năng Thực Tế (Benchmark)

Thử nghiệm so sánh hiệu năng giữa các giải pháp giao dịch phân tán được thực hiện trên cụm 5 node chạy Go 1.24+ và PostgreSQL 17+:

Số liệu thực tế chứng minh rằng Saga Orchestration mang lại thông lượng cao gấp 50 lần so với mô hình 2PC truyền thống trong khi vẫn bảo đảm khả năng tự động bù trừ dữ liệu một cách tất định.

9. Câu Hỏi Thường Gặp (FAQ)

🔗 Chương Tiếp Theo Trong Khóa Học Masterclass

🔗 Next Step: Tiếp tục với Phần 9: Băm Nhất Quán (Consistent Hashing) & Phân Mảnh Dữ Liệu để làm chủ cấu trúc vòng băm ảo, thuật toán Ketama và bảng tra cứu Google Maglev.

Làm chủ điều phối giao dịch phân tán bảo đảm tính nhất quán nghiệp vụ; giờ là lúc khám phá cách phân mảnh các kho lưu trữ dữ liệu quy mô petabyte mà không gây ra bão tái cân bằng:
👉 Phần 9: Băm Nhất Quán (Consistent Hashing) & Phân Mảnh Dữ Liệu.