Thiết Kế Hệ Thống Quản Lý Công Việc Phân Tán (Distributed Job Scheduler): Từ A Đến Z!

Lê Lân

17/06/2025

Thiết Kế Hệ Thống Distributed Job Scheduler: Giải Pháp Cho Quản Lý Tác Vụ Nền Quy Mô Lớn

Mở Đầu

Trong kỷ nguyên số hiện nay, hàng loạt ứng dụng phần mềm cần thực thi các tác vụ nền một cách quy mô, tin cậy và đúng thời điểm. Việc lên lịch và quản lý các job này không chỉ đòi hỏi hệ thống mạnh mẽ mà còn phải đảm bảo độ bền dữ liệu, tính chính xác và khả năng mở rộng cao. Bài viết này sẽ cung cấp một cái nhìn toàn diện về thiết kế hệ thống Distributed Job Scheduler — từ yêu cầu chức năng, phi chức năng, thiết kế kiến trúc, lựa chọn lưu trữ đến xử lý đảm bảo idempotency, tích hợp với các công cụ phổ biến như AWS SQS và Kafka.

Chúng ta sẽ cùng tìm hiểu cách xây dựng một hệ thống có khả năng xử lý hàng tỷ job mỗi ngày, áp dụng các kỹ thuật và mô hình thiết kế phù hợp để đáp ứng các tiêu chí về độ trễ, khả năng chịu lỗi và hiệu năng.

Yêu Cầu Hệ Thống

Yêu Cầu Chức Năng

Submit Job/Tác vụ theo lịch trình cụ thể.

Hỗ trợ kích hoạt thủ công các job.

Job là các script Python (mở rộng cho các ngôn ngữ khác sau này).

Đảm bảo thực thi ít nhất một lần cho các job được lên lịch.

Hỗ trợ job định kỳ, có thể bật/tắt theo nhu cầu.

Hỗ trợ chuỗi thực thi các job (ví dụ Job1 -> Job2 -> Job3).

Yêu Cầu Phi Chức Năng

Độ sẵn sàng cao (High Availability).

Thực thi các job gần đúng thời gian (độ trễ 2-4 giây chấp nhận được).

Độ bền dữ liệu cao: không mất mát job dù hệ thống gặp sự cố.

Gửi thông báo trì hoãn đến người dùng khi cần.

Khả năng mở rộng lên đến 10 tỷ job/ngày.

Ước Lượng Thông Số Qua Lại & Lưu Trữ

Thông lượng: khoảng 10⁹ job/ngày tương đương 10,000 job/giây.

Dữ liệu lưu trữ: giả sử mỗi job 200 dòng, mỗi dòng ~50 bytes, tổng ~10 TB/ngày cho mã nguồn job.

Thiết Kế Tổng Quan

API Thiết Kế

Phương Thức	Endpoint	Mô Tả	Ví Dụ Payload
POST	`/api/v1/jobs`	Tạo mới job	`{ "taskId": "someUniqueId", "cron": "/5 * * *", "params": { "p1": "val1" }}`
GET	`/api/v1/jobs/:jobId`	Lấy trạng thái job	-

Lựa Chọn Cơ Sở Dữ Liệu

Tại Sao Chọn NoSQL?

Đặc điểm hệ thống viết nhiều hơn đọc.

Không cần quan hệ phức tạp, loại bỏ yêu cầu chuẩn hóa dữ liệu.

ACID không quá quan trọng, ưu tiên hiệu năng và khả năng mở rộng.

Các lựa chọn phù hợp: DynamoDB, Cassandra, MongoDB.

Mẫu Schema

Trường	Mô Tả
time_bucket	Thời gian theo khoảng (ví dụ: phút)
execution_time	Thời gian dự kiến thực thi
job_id	Mã định danh job
user_id	Mã người dùng
status	Trạng thái (PENDING, SUCCESS, FAIL)
attempt	Lượt thử thực hiện
script_url	Đường dẫn tới script (ví dụ S3)

{
  "time_bucket": "2025-05-24T10:00:00Z",
  "execution_time": "2025-05-24T10:00:05Z",
  "job_id": "job_abc_123",
  "user_id": "user_123",
  "status": "PENDING",
  "attempt": 0,
  "script_url": "s3://bucket-name/path-to-script.py"
}

Lưu ý quan trọng: Cách lập chỉ mục theo time_bucket giúp nhanh chóng lọc những job cần chạy trong cửa sổ thời gian kế tiếp.

Quy Trình Lập Lịch Và Thực Thi

Luồng Thực Thi

Watcher Service định kỳ (ví dụ mỗi phút) truy vấn DB lấy các job có lịch trình thực thi trong vòng 1 phút tới.

Đưa các job này vào FIFO SQS queue để đảm bảo thứ tự xử lý.

Executor Service liên tục kéo job từ SQS.

Tạo môi trường thực thi cô lập bằng ECS Container cho mỗi job.

Thực hiện kiểm tra idempotency trước khi chạy.

Chạy job, cập nhật trạng thái trong DB sau khi hoàn thành.

Mô Tả Sequence Diagram

Luồng công việc được thiết kế để đảm bảo đẳng thứ tự, khả năng chịu lỗi và tính bền vững của từng job được thực thi.

Bảo Đảm Không Xử Lý Trùng (Idempotency)

Vấn Đề Phát Sinh

Khi Executor gặp sự cố giữa chừng hoặc chưa kịp gọi DeleteMessage() với SQS, thông điệp có thể được gửi lại (redelivered), dẫn đến việc thực thi job nhiều lần.

Giải Pháp

Trước khi thực thi, kiểm tra trạng thái jobRunId trong DB:

Nếu đã thành công (status SUCCESS ), bỏ qua.

Nếu chưa, chạy và cập nhật.

Cách Hoạt Động Với SQS FIFO

Bước	Mô Tả
ReceiveMessage	Executor polling nhận message, bắt đầu `Visibility Timeout` .
Xử lý thành công	Gọi `DeleteMessage()` để xóa message khỏi queue.
Không xóa trong timeout	Message được đưa lại queue và có thể bị xử lý lại.

Ví Dụ Boilerplate Java

AmazonSQS sqs = AmazonSQSClientBuilder.defaultClient();
String queueUrl = "https://sqs.us-east-1.amazonaws.com/your-queue-url";
ReceiveMessageRequest request = new ReceiveMessageRequest()
    .withQueueUrl(queueUrl)
    .withWaitTimeSeconds(10)
    .withMaxNumberOfMessages(1);

while (true) {
    List<Message> messages = sqs.receiveMessage(request).getMessages();
    for (Message msg : messages) {
        String body = msg.getBody();
        // Deserialize và kiểm tra idempotency
        // Thực thi job nếu chưa làm
        sqs.deleteMessage(queueUrl, msg.getReceiptHandle());
    }
}

So Sánh Kafka Với SQS

Tiêu chí	AWS SQS	Kafka
Xóa message	Consumer phải explicit gọi xóa	Message tự động lưu, offset commit
Xử lý trùng	Dùng idempotency trong consumer	Dùng idempotency + commit offset

Kafka khác với SQS ở chỗ không tự động xóa message mà consumer tự commit offset khi đã xử lý thành công.

Khái Niệm Idempotency

Một quy trình là idempotent nếu chạy nhiều lần liên tiếp có cùng kết quả như chạy một lần duy nhất.

Ví dụ: Nếu một jobRunId đã được đánh dấu completed, khi gặp lại sẽ skip để tránh chạy lại.

Điều này đặc biệt thiết yếu trong môi trường bất đồng bộ, retry liên tục như distributed job scheduler.

Giám Sát & Chỉ Số

Các Metrics Cần Thiết

Số job được submit/ thực thi (phút/giờ/ngày).

Thời gian thực thi trung bình.

Tỷ lệ lỗi/thành công.

Tài nguyên hạ tầng: CPU, memory của Executor nodes.

Queue size, độ trễ (SQS hoặc Kafka lag).

Độ trễ đọc/ghi DB.

Cảnh Báo & Dashboard

Thiết lập cảnh báo cho:

Job bị trễ quá mức.

Job thất bại nhiều lần.

Số lần retry cao.

Công cụ gợi ý: Prometheus + Grafana, AWS CloudWatch.

Dùng Dead Letter Queues (DLQ) để xử lý job thất bại quá nhiều lần.

Lưu audit log đầy đủ để phục vụ truy vết, phân tích sau này (ví dụ Elasticsearch, S3).

Kết Luận

Bài viết đã phác thảo chi tiết thiết kế một hệ thống Distributed Job Scheduler có khả năng:

Xử lý tác vụ quy mô cực lớn (10 tỷ job/ngày),

Đảm bảo độ bền dữ liệu và at-least-once execution bằng kỹ thuật idempotency,

Quản lý hàng đợi FIFO qua AWS SQS,

Dễ dàng mở rộng và tích hợp với Kafka cũng như các nền tảng Pub/Sub khác.

Đây là một nền tảng phù hợp cho các doanh nghiệp và ứng dụng cần xử lý tác vụ nền phức tạp với độ tin cậy cao. Hãy cân nhắc tích hợp các module giám sát, cảnh báo để nâng cao hiệu quả vận hành hệ thống.

Tham Khảo

Gaurav Singh. "Distributed Job Scheduler at Scale". Dev.to, 2023. Link

AWS Official Documentation. "Amazon SQS Developer Guide". Link

Kafka Documentation. "Kafka Consumer Configurations". Link

Martin Fowler. "What is Idempotency?". Link

"Building Scalable Job Scheduling Systems". Medium, 2022. Link

Hãy theo dõi tác giả để nhận thêm các bài viết, kiến thức sâu sắc về thiết kế hệ thống và thuật toán mỗi tuần!