Mục lục nội dung

Bối cảnh và Nỗi đau khi Xử lý Giao dịch Phân tán trong Kiến trúc Microservices

Khi một hệ thống phần mềm phát triển từ mô hình nguyên khối sang kiến trúc dịch vụ phân tán, bài toán đồng bộ dữ liệu giữa các cơ sở dữ liệu độc lập trở thành thử thách lớn nhất đối với các kỹ sư phần mềm. Trong một hệ thống nguyên khối truyền thống, việc sử dụng cơ chế transaction ACID của cơ sở dữ liệu quan hệ giúp bảo vệ tính toàn vẹn của dữ liệu một cách tự động thông qua việc rollback khi xảy ra lỗi. Tuy nhiên, khi các dịch vụ bị chia tách, mỗi dịch vụ sở hữu một cơ sở dữ liệu riêng biệt, nguyên tắc ACID cục bộ không còn hiệu lực trên toàn bộ hệ thống.

Vấn đề lớn nhất xuất hiện khi một nghiệp vụ kinh doanh yêu cầu thực hiện ghi dữ liệu tuần tự qua nhiều dịch vụ khác nhau. Ví dụ điển hình trong hệ thống thương mại điện tử là quy trình đặt hàng, bao gồm việc trừ số lượng sản phẩm trong kho, tạo đơn hàng trong dịch vụ thanh toán, và cộng điểm tích lũy cho khách hàng. Nếu dịch vụ tạo đơn hàng gặp sự cố sau khi dịch vụ kho đã trừ số lượng sản phẩm, hệ thống sẽ rơi vào trạng thái bất nhất dữ liệu nghiêm trọng. Việc không thể sử dụng giao dịch phân tán truyền thống dựa trên giao thức Two Phase Commit do hiệu năng kém và tính khóa tài nguyên cao buộc các kỹ sư phải tìm kiếm những giải pháp thay thế hiệu quả hơn.

Sự thiếu sót trong việc thiết kế cơ chế xử lý lỗi và bù đắp dữ liệu thường dẫn đến những hậu quả nặng nề trong môi trường vận hành thực tế. Dữ liệu rác xuất hiện khắp nơi, khách hàng bị trừ tiền nhưng không nhận được đơn hàng, hoặc kho hàng bị sụt giảm số lượng ảo mà không có giao dịch tương ứng. Để giải quyết triệt để những nỗi đau này, việc áp dụng kết hợp giữa mô hình Saga Pattern và Outbox Pattern là tiêu chuẩn kỹ thuật bắt buộc trong các hệ thống backend hiện đại.

Phân tích Nguyên nhân Gốc rễ của Sự Bất nhất Dữ liệu

Nguyên nhân cốt lõi dẫn đến sự bất nhất dữ liệu trong hệ thống phân tán là do sự cô lập mạng và tính bất đồng bộ giữa các thành phần. Khi các dịch vụ giao tiếp với nhau qua mạng Internet hoặc mạng nội bộ thông qua các giao thức truyền thông điệp, các sự cố như mất kết nối, độ trễ cao, hoặc sập nguồn đột ngột là điều không thể tránh khỏi. Khi một yêu cầu HTTP hoặc một sự kiện được phát đi, việc thực thi ở bên nhận không đảm bảo sẽ diễn ra thành công 100 phần trăm.

Một sai lầm phổ biến của các lập trình viên mới chuyển sang làm việc với hệ thống phân tán là cố gắng gọi trực tiếp các API của dịch vụ khác tuần tự và xử lý khối lệnh try catch đơn giản. Cách tiếp cận này bỏ qua hoàn toàn các kịch bản khi dịch vụ gọi đi thành công nhưng dịch vụ nhận ghi dữ liệu thất bại hoặc phản hồi chậm khiến timeout. Hậu quả là luồng thực thi bị đứt gãy giữa chừng, để lại một nửa dữ liệu đã được thay đổi trong khi nửa còn lại vẫn giữ nguyên trạng thái cũ, tạo ra những lỗ hổng dữ liệu cực kỳ khó khắc phục thủ công.

Thách thức khi Đảm bảo Tính Nguyên tử trong Giao tiếp Bất đồng bộ

Giao tiếp bất đồng bộ thông qua message broker mang lại tính năng mở rộng tuyệt vời và giảm độ trễ cho hệ thống, nhưng nó lại đánh đổi bằng độ phức tạp trong việc đảm bảo tính nguyên tử giữa việc thao tác trên cơ sở dữ liệu và việc phát sự kiện. Trong nhiều trường hợp, lập trình viên thực hiện lưu dữ liệu vào cơ sở dữ liệu trước, sau đó gọi lệnh gửi thông điệp đi. Nếu tiến trình bị sập ngay sau câu lệnh lưu cơ sở dữ liệu nhưng trước khi gửi thông điệp, hệ thống sẽ mất đi sự kiện quan trọng đó, khiến các dịch vụ lắng nghe không bao giờ nhận được thông báo để thực hiện công việc tiếp theo.

Ngược lại, nếu gửi thông điệp trước khi lưu cơ sở dữ liệu, dịch vụ có thể phát đi sự kiện nhưng việc lưu dữ liệu cục bộ lại thất bại do lỗi ràng buộc dữ liệu. Cả hai trường hợp đều minh chứng cho việc không thể thực hiện hai thao tác ghi độc lập này mà không có một cơ chế điều phối cấp độ kiến trúc. Đây chính là lúc Outbox Pattern phát huy tác dụng tuyệt vời của mình trong việc đồng bộ trạng thái.

Kiến trúc Tổng quan của Saga Pattern và Outbox Pattern

Saga Pattern là một mẫu thiết kế quản lý các giao dịch phân tán thông qua một chuỗi các giao dịch cục bộ được thực thi trên từng dịch vụ liên quan. Mỗi bước trong Saga cập nhật cơ sở dữ liệu và phát ra một sự kiện hoặc lệnh để kích hoạt bước tiếp theo trong chuỗi. Nếu một bước bất kỳ trong Saga thất bại do vi phạm nghiệp vụ hoặc lỗi hệ thống, Saga sẽ thực hiện một chuỗi các giao dịch bù đắp để hoàn tác lại tất cả các thay đổi đã thực hiện trước đó, đưa hệ thống trở về trạng thái ban đầu.

Có hai cách tiếp cận chính để triển khai Saga Pattern là dựa trên sự kiện phân tán và dựa trên bộ điều phối trung tâm. Trong phương pháp dựa trên sự kiện, các dịch vụ tự lắng nghe sự kiện của nhau và tự quyết định hành động tiếp theo mà không có một thực thể trung tâm nào điều khiển. Phương pháp này phù hợp với các hệ thống nhỏ, nhưng khi logic nghiệp vụ phức tạp lên, việc theo dõi luồng dữ liệu trở nên cực kỳ khó khăn. Do đó, phương pháp sử dụng bộ điều phối trung tâm được ưa chuộng hơn trong các hệ thống enterprise nhờ khả năng kiểm soát luồng rõ ràng và dễ dàng ghi log trạng thái.

Cơ chế Hoạt động Nội tại của Outbox Pattern

Outbox Pattern giải quyết bài toán mất mát thông điệp giữa cơ sở dữ liệu cục bộ và message broker bằng cách sử dụng chính cơ sở dữ liệu của dịch vụ làm trung gian tạm thời. Thay vì gửi thông điệp trực tiếp ra bên ngoài, ứng dụng sẽ ghi đồng thời bản ghi dữ liệu nghiệp vụ và một bản ghi thông điệp vào trong cùng một bảng cơ sở dữ liệu thông qua một transaction cục bộ duy nhất.

Bằng cách đóng gói cả hai thao tác này trong một giao dịch cơ sở dữ liệu duy nhất, tính nguyên tử được đảm bảo tuyệt đối. Dữ liệu nghiệp vụ không thể được lưu mà thiếu đi thông điệp tương ứng, và ngược lại. Một tiến trình nền riêng biệt sẽ liên tục quét bảng outbox này, đọc các thông điệp chưa được gửi, đẩy chúng lên message broker, và sau đó đánh dấu là đã gửi thành công. Cơ chế này đảm bảo thông điệp không bao giờ bị thất lạc ngay cả khi ứng dụng khởi động lại đột ngột.

Sự Kết hợp Hoàn hảo giữa Saga và Outbox trong Backend Hiện đại

Khi kết hợp Saga Pattern với Outbox Pattern, chúng ta tạo ra một cơ chế giao dịch phân tán cực kỳ mạnh mẽ và đáng tin cậy. Bộ điều phối Saga đóng vai trò là bộ não điều hướng các bước thực hiện nghiệp vụ, trong khi Outbox Pattern đảm bảo mọi thông điệp lệnh và sự kiện được truyền tải chính xác giữa các dịch vụ mà không sợ thất lạc dữ liệu do lỗi mạng hay lỗi tiến trình.

Mô hình này loại bỏ hoàn toàn sự phụ thuộc vào các giao dịch phân tán nặng nề, cho phép các dịch vụ hoạt động độc lập, mở rộng quy mô linh hoạt và tự phục hồi khi có sự cố xảy ra. Các kỹ sư có thể dễ dàng theo dõi trạng thái của từng bước giao dịch thông qua bảng lưu trữ trạng thái Saga, từ đó cung cấp khả năng quan sát toàn diện cho hệ thống.

Triển khai Chi tiết Outbox Pattern với TypeScript và Cơ chế Polling

Để hiểu rõ bản chất kỹ thuật, chúng ta sẽ xây dựng một đoạn mã minh họa việc triển khai Outbox Pattern bằng TypeScript. Đoạn mã dưới đây thể hiện cách một dịch vụ lưu trữ đơn hàng đồng thời ghi thông điệp vào bảng outbox trong cùng một phiên làm việc với cơ sở dữ liệu.

import { DataSource, EntityManager } from 'typeorm';

export class OrderService {
  constructor(private readonly dataSource: DataSource) {}

  async createOrderWithOutbox(orderData: { userId: string; amount: number }): Promise<void> {
    const queryRunner = this.dataSource.createQueryRunner();
    await queryRunner.connect();
    await queryRunner.startTransaction();

    try {
      const orderRepository = queryRunner.manager.getRepository('Order');
      const outboxRepository = queryRunner.manager.getRepository('OutboxMessage');

      const newOrder = orderRepository.create({
        userId: orderData.userId,
        amount: orderData.amount,
        status: 'PENDING',
      });
      const savedOrder = await orderRepository.save(newOrder);

      const outboxMessage = outboxRepository.create({
        aggregateType: 'Order',
        aggregateId: savedOrder.id,
        eventType: 'OrderCreated',
        payload: JSON.stringify(savedOrder),
        processed: false,
      });
      await outboxRepository.save(outboxMessage);

      await queryRunner.commitTransaction();
    } catch (error) {
      await queryRunner.rollbackTransaction();
      throw new Error(`Failed to create order and outbox message: ${error.message}`);
    } finally {
      await queryRunner.release();
    }
  }
}

Đoạn mã trên sử dụng tính năng quản lý transaction thông qua trình quản lý truy vấn để đảm bảo rằng nếu bất kỳ thao tác nào gặp ngoại lệ, toàn bộ thay đổi sẽ được hoàn tác. Bảng outbox lưu giữ thông tin chi tiết của sự kiện dưới dạng chuỗi JSON, sẵn sàng để tiến trình nền quét và đẩy đi.

Xây dựng Tiến trình Nền Quét và Đẩy Thông điệp

Tiến trình nền đóng vai trò là cầu nối giữa cơ sở dữ liệu cục bộ và hệ thống truyền thông điệp phân tán. Tiến trình này cần được thiết kế hoạt động liên tục theo chu kỳ thời gian nhất định để xử lý các bản ghi chưa được gửi.

import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { OutboxMessage } from './outbox.entity';
import { MessageBrokerService } from './message-broker.service';

@Injectable()
export class OutboxProcessor {
  constructor(
    @InjectRepository(OutboxMessage)
    private readonly outboxRepository: Repository<OutboxMessage>,
    private readonly messageBroker: MessageBrokerService,
  ) {}

  @Cron(CronExpression.EVERY_SECOND)
  async processOutboxMessages(): Promise<void> {
    const messages = await.this.outboxRepository.find({
      where: { processed: false },
      take: 50,
      order: { createdAt: 'ASC' },
    });

    for (const message of messages) {
      try {
        await.this.messageBroker.publish(message.eventType, message.payload);
        message.processed = true;
        message.processedAt = new Date();
        await.this.outboxRepository.save(message);
      } catch (error) {
        console.error(`Failed to publish message ID ${message.id}:`, error.message);
      }
    }
  }
}

Phương thức định lịch quét mỗi giây giúp đảm bảo độ trễ thấp trong việc truyền tải thông điệp. Việc giới hạn số lượng bản ghi xử lý trong mỗi chu kỳ giúp kiểm soát bộ nhớ và tải của cơ sở dữ liệu, tránh tình trạng quá tải khi số lượng thông điệp tích tụ lớn.

Thiết kế Orchestrator Saga và Cơ chế Bù đắp Dữ liệu

Bộ điều phối Saga chịu trách nhiệm thực thi tuần tự các bước trong một quy trình kinh doanh lớn. Khi một bước thất bại, bộ điều phối sẽ tự động kích hoạt các hành động bù đắp theo thứ tự ngược lại để khôi phục trạng thái hệ thống.

export class OrderSagaOrchestrator {
  constructor(
    private readonly inventoryService: InventoryService,
    private readonly paymentService: PaymentService,
    private readonly orderService: OrderService,
  ) {}

  async executeSaga(orderId: string, items: any[], amount: number): Promise<boolean> {
    let inventoryReserved = false;
    let paymentProcessed = false;

    try {
      await.this.inventoryService.reserveStock(items);
      inventoryReserved = true;

      await.this.paymentService.processPayment(orderId, amount);
      paymentProcessed = true;

      await.this.orderService.completeOrder(orderId);
      return true;
    } catch (error) {
      if (paymentProcessed) {
        await.this.paymentService.refundPayment(orderId, amount);
      }
      if (inventoryReserved) {
        await.this.inventoryService.releaseStock(items);
      }
      await.this.orderService.failOrder(orderId);
      return false;
    }
  }
}

Cấu trúc điều phối trên đảm bảo rằng bất kể lỗi xảy ra ở bước nào, các tài nguyên đã bị chiếm giữ trước đó đều được giải phóng hoặc hoàn trả một cách chính xác. Biến cờ trạng thái giúp xác định chính xác các bước nào đã hoàn thành để chỉ thực hiện bù đắp những bước đó.

Xử lý Tình huống Biên và Tranh chấp Dữ liệu

Trong môi trường phân tán, các tình huống tranh chấp dữ liệu xảy ra thường xuyên khi nhiều tiến trình cùng cố gắng cập nhật một tài nguyên. Việc áp dụng cơ chế khóa lạc quan thông qua số phiên bản bản ghi giúp phát hiện kịp thời các xung đột ghi dữ liệu.

Khi một giao dịch cố gắng cập nhật bản ghi nhưng số phiên bản trong cơ sở dữ liệu đã thay đổi so với thời điểm đọc ban đầu, hệ thống sẽ từ chối giao dịch và buộc tiến trình thực hiện lại từ đầu. Điều này ngăn chặn hoàn toàn hiện tượng ghi đè dữ liệu trái phép giữa các luồng xử lý đồng thời.

Xử lý Lỗi Nâng cao và Chiến lược Thử lại Thông minh

Không phải mọi lỗi trong hệ thống phân tán đều mang tính vĩnh viễn. Các lỗi tạm thời như quá tải mạng cục bộ hoặc gián đoạn kết nối cơ sở dữ liệu ngắn hạn có thể được khắc phục tự động bằng chiến lược thử lại thông minh kết hợp thời gian chờ tăng dần.

export async function retryWithBackoff<T>(
  fn: () => Promise<T>,
  retries = 3,
  delay = 1000,
): Promise<T> {
  try {
    return await fn();
  } catch (error) {
    if (retries <= 0) {
      throw error;
    }
    await.new Promise((resolve) => setTimeout(resolve, delay));
    return retryWithBackoff(fn, retries - 1, delay * 2);
  }
}

Thuật toán trên tăng gấp đôi thời gian chờ sau mỗi lần thử lại thất bại, giúp giảm áp lực đáng kể cho các dịch vụ hạ tầng đang gặp sự cố quá tải, đồng thời tăng tỷ lệ thành công khi dịch vụ phục hồi trạng thái hoạt động bình thường.

Quản lý Hàng đợi Thư chết cho Thông điệp Lỗi

Những thông điệp vượt quá giới hạn số lần thử lại mà vẫn không thể xử lý thành công sẽ được chuyển hướng vào hàng đợi thư chết để phân tích chuyên sâu. Việc cô lập các thông điệp lỗi này giúp ngăn chặn hiện tượng tắc nghẽn hàng đợi chính, đồng thời cung cấp nguồn dữ liệu quan trọng cho các kỹ sư kiểm tra và vá lỗi hệ thống.

Sai lầm Phổ biến và Cách Phòng tránh khi Thiết kế Hệ thống Phân tán

Một trong những sai lầm phổ biến nhất là việc bỏ qua tính bất biến của các giao dịch bù đắp. Các hàm bù đắp phải được thiết kế theo tính chất lũy thừa, nghĩa là việc thực hiện một hành động bù đắp nhiều lần trên cùng một đối tượng vẫn mang lại kết quả duy nhất, không làm thay đổi sai lệch dữ liệu.

Sai lầm thứ hai là việc không thiết lập thời gian hết hạn cho các giao dịch Saga đang chờ xử lý. Nếu một tiến trình điều phối bị treo giữa chừng mà không có cơ chế hết hạn, tài nguyên của hệ thống sẽ bị khóa vĩnh viễn, dẫn đến hiện tượng cạn kiệt tài nguyên toàn hệ thống. Việc sử dụng tiến trình giám sát thời gian chờ là giải pháp bắt buộc để dọn dẹp các giao dịch bị kẹt.

Tối ưu hóa Hiệu năng và Chiến lược Mở rộng Quy mô

Khi số lượng thông điệp trong bảng outbox tăng lên hàng triệu bản ghi, việc thực hiện câu lệnh quét bảng định kỳ bằng cơ chế polling truyền thống sẽ gây áp lực lớn lên cơ sở dữ liệu quan hệ. Để giải quyết vấn đề này, các kỹ sư thường áp dụng kỹ thuật đọc thay đổi cơ sở dữ liệu thông qua nhật ký giao dịch, cho phép bắt sự kiện thay đổi dữ liệu thời gian thực mà không cần thực hiện các truy vấn quét bảng tốn kém tài nguyên.

Việc phân vùng bảng outbox theo thời gian hoặc theo định danh dịch vụ cũng là một chiến lược hiệu quả giúp tăng tốc độ truy vấn và tối ưu hóa hiệu suất làm việc của các tiến trình nền trong các hệ thống quy mô cực lớn.

Checklist Đúc kết Kinh nghiệm Thực chiến cho Kỹ sư Backend

 

  • Luôn đóng gói thao tác nghiệp vụ và ghi bảng outbox trong cùng một transaction cơ sở dữ liệu cục bộ.
  • Thiết kế tất cả các hành động bù đắp trong Saga theo chuẩn tính chất lũy thừa để đảm bảo an toàn khi chạy lặp lại.
  • Sử dụng chiến lược thử lại thông minh với thời gian chờ tăng dần cho các tác động gọi mạng sang dịch vụ ngoài.
  • Xây dựng cơ chế theo dõi thời gian sống của các tiến trình Saga để xử lý kịp thời các giao dịch bị treo.
  • Áp dụng kỹ thuật đọc nhật ký thay đổi cơ sở dữ liệu thay thế cho cơ chế quét bảng truyền thống khi hệ thống đạt quy mô lớn.

 

Việc nắm vững các kỹ thuật xây dựng giao dịch phân tán đòi hỏi nền tảng kiến thức vững chắc về lập trình backend và khả năng thiết kế hệ thống chịu lỗi cao. Để trang bị toàn diện các kỹ năng thực chiến này, bạn có thể Tham khảo khóa học "RESTful API với NestJS & TypeORM" tại đây.