Chạy Spring Batch phân tán không cần message broker: biến cơ sở dữ liệu thành mặt phẳng điều phối

Khi triển khai Spring Batch theo mô hình phân vùng (partitioning) trên nhiều node, đội phát triển thường mặc định phải có thêm một message broker như Kafka hay RabbitMQ để điều phối công việc giữa các node. Tuy nhiên, một thực tế ít được chú ý là Spring Batch vốn đã yêu cầu một job repository dùng chung và bền vững — tức là một cơ sở dữ liệu quan hệ đáng tin cậy. Bài viết của tác giả Janardhan Reddy Chejarla trên InfoQ lập luận rằng chính cơ sở dữ liệu này có thể đảm nhận toàn bộ vai trò điều phối, giúp hệ thống bớt đi một hạ tầng phức tạp mà vẫn đảm bảo tính đúng đắn.

Vì sao bỏ được broker?

Trong mô hình phân vùng cổ điển, một master node chia dữ liệu thành nhiều partition rồi gửi yêu cầu tới các worker. Message broker thường được dùng để chuyển tiếp các yêu cầu này và thu thập kết quả. Nhưng vì job repository — nơi lưu trạng thái của job, step và từng lần thực thi — đã là điểm chung bắt buộc, ta có thể dùng nó làm mặt phẳng điều phối duy nhất.

Cách tiếp cận này mang lại vài lợi ích rõ rệt:

• Giảm độ phức tạp vận hành: không cần thêm cụm Kafka hay RabbitMQ, không phải lo về độ bền của message, offset hay việc xử lý lại.
• Một nguồn sự thật duy nhất: trạng thái công việc và trạng thái điều phối nằm cùng một chỗ, tránh tình trạng lệch pha giữa broker và cơ sở dữ liệu.
• Tính nhất quán giao dịch: việc đánh dấu một partition đã được nhận và ghi nhận kết quả có thể nằm trong cùng một giao dịch cơ sở dữ liệu.

Điểm mấu chốt là công việc điều phối ở đây rất đơn giản: chia việc, nhận việc, báo xong. Những thao tác này không cần đến khả năng truyền tải message phức tạp của một broker chuyên dụng.

Chia việc theo số node đang sống

Thay vì chia cứng số partition theo cấu hình tĩnh, hệ thống có thể đếm số node worker đang hoạt động tại thời điểm chạy rồi chia công việc tương ứng. Cách làm này giúp tận dụng tốt hơn tài nguyên: nếu một node gặp sự cố và rời cụm, các node còn lại vẫn nhận được khối lượng việc hợp lý thay vì để sót những partition không ai xử lý.

Tuy nhiên, cần lưu ý rằng việc chia lại động đòi hỏi cơ chế theo dõi node chính xác, và đây là lúc heartbeat phát huy vai trò.

Master theo từng job, không có coordinator thường trực

Một điểm thiết kế đáng chú ý là hệ thống không duy trì một coordinator thường trực. Thay vào đó, mỗi khi một job được kích hoạt, một node sẽ tạm thời đảm nhận vai trò master cho riêng job đó. Khi job kết thúc, vai trò này cũng chấm dứt.

Cách tiếp cận "master theo từng job" giúp loại bỏ điểm lỗi đơn (single point of failure) vốn có của mô hình coordinator cố định, đồng thời tránh được chi phí duy trì một tiến trình luôn chạy chỉ để điều phối.

Claim bằng compare-and-set để chống chạy trùng

Rủi ro lớn nhất khi điều phối qua cơ sở dữ liệu là hai worker cùng nhận một partition và thực thi trùng lặp. Để chặn điều này, bài viết đề xuất cơ chế claim bằng compare-and-set (CAS): một worker chỉ giành được partition nếu bản ghi trạng thái vẫn đang ở trạng thái "chưa được nhận" tại thời điểm cập nhật.

Cụ thể, câu lệnh cập nhật sẽ có dạng "đặt trạng thái thành đang xử lý, với điều kiện trạng thái hiện tại là chưa nhận". Nếu số dòng bị ảnh hưởng bằng 0, nghĩa là worker khác đã nhanh tay hơn và worker này phải thử partition khác. Đây là một kỹ thuật kinh điển, nhưng được áp dụng rất hiệu quả ở đây vì nó tận dụng tính nguyên tử của giao dịch cơ sở dữ liệu.

Chuyển đổi dự phòng bằng heartbeat hai pha

Khi master của một job gặp sự cố giữa chừng, hệ thống cần phát hiện và bầu master mới. Cơ chế heartbeat hai pha giải quyết bài toán này: node giữ vai trò master ghi nhận nhịp tim định kỳ vào cơ sở dữ liệu, còn các node khác theo dõi. Nếu nhịp tim quá hạn, một node sẽ cố gắng tiếp quản — nhưng việc tiếp quản cũng dùng CAS để đảm bảo chỉ một node thành công.

Hai pha ở đây giúp phân biệt rõ giữa "master có thể đã chết" và "master chắc chắn đã chết", tránh việc bầu nhầm master mới trong khi master cũ vẫn đang chạy và gây ra hai master cùng lúc.

Khi nào vẫn nên dùng broker?

Bài viết cũng thẳng thắn chỉ ra giới hạn của cách làm này. Message broker vẫn là lựa chọn đúng trong một số tình huống:

• Khối lượng công việc rất lớn và tần suất cao, khi việc liên tục truy vấn cơ sở dữ liệu để giành việc trở thành nút thắt cổ chai.
• Hệ thống đã có sẵn hạ tầng broker và đội ngũ đã quen vận hành, khi đó thêm một cơ chế điều phối mới chỉ làm tăng độ phức tạp.
• Cần các mẫu giao tiếp phức tạp như fan-out, lọc message hay xử lý luồng sự kiện theo thời gian thực.

Với các hệ thống batch nội bộ quy mô vừa, nơi cơ sở dữ liệu vốn đã là thành phần bắt buộc, việc tận dụng nó làm mặt phẳng điều phối là một lựa chọn đáng cân nhắc. Với các đội phát triển tại Việt Nam đang vận hành hệ thống xử lý dữ liệu định kỳ như đối soát giao dịch, xuất báo cáo hay đồng bộ dữ liệu, cách tiếp cận này có thể giúp giảm đáng kể gánh nặng hạ tầng mà không đánh đổi tính đúng đắn.