Chạy cronjob trên nhiều node NestJS mà không trùng thế nào?

Question

IT Interview Practice · Accepted Answer

Trước tiên cần làm rõ “chỉ một node chạy cronjob” nghĩa là gì. **Không chạy đồng thời và không tạo tác dụng nghiệp vụ lặp là hai yêu cầu khác nhau.** Bộ lập lịch dùng chung phối hợp việc chạy; bản thân thao tác vẫn phải an toàn khi lỗi rồi chạy lại.

Lấy ví dụ job tạo hóa đơn hằng ngày được triển khai trên ba node NestJS. Ta muốn công việc chạy đúng lịch, đồng thời không sinh thêm hóa đơn khi worker khởi động lại.

## 1. Hiểu vì sao mọi node cùng bắt đầu

Mỗi instance ứng dụng đăng ký callback cron riêng. Đến giờ, từng instance có thể tự chạy:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Cờ isRunning cục bộ chỉ tồn tại trong một process. waitForCompletion của NestJS có thể ngăn callback chồng nhau trên instance đó, nhưng không phối hợp với node khác. Thêm cùng một cờ vào ba node vẫn là ba quyết định riêng. [Lập lịch trong NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Vì vậy, cần một nơi dùng chung để quyết định công việc nào tồn tại và ai được xử lý.

## 2. Chọn cách phối hợp

| Tình huống | Hướng cân nhắc | Trách nhiệm còn lại |
| --- | --- | --- |
| Nền tảng đã có dịch vụ chạy theo lịch | Đưa lập lịch ra ngoài các instance web | Cấu hình chạy chồng, khôi phục và xử lý lượt bị bỏ lỡ. |
| Team đã vận hành BullMQ | Job Scheduler dùng chung và queue riêng | Cấu hình concurrency toàn cục và retry an toàn. |
| Tác vụ hiện tại phải nằm trên các node ứng dụng | Lock hoặc lease dùng chung | Xử lý đúng quyền sở hữu, hết hạn và worker cũ. |

Với ví dụ hóa đơn, nếu đã có Redis và BullMQ, scheduler dùng chung với ID ổn định là phương án đáng cân nhắc. Tách lịch khỏi worker để việc thêm node web không tạo thêm lịch độc lập.

Ở phiên bản BullMQ hỗ trợ, đặt global concurrency của queue riêng bằng một. Nó giới hạn job active trên tất cả worker; đặt local concurrency bằng một ở từng worker vẫn cho phép nhiều worker chạy các job khác nhau. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Quy định khi việc hôm qua còn chạy thì hôm nay sẽ chờ, bỏ qua hay gộp lượt. Xác định múi giờ và có cần chạy bù các ngày nghiệp vụ bị bỏ lỡ sau downtime không.

## 3. Bảo vệ hóa đơn, không chỉ bảo vệ job

Giả sử worker đã tạo hóa đơn rồi bị lỗi trước khi ghi nhận job hoàn tất. Cơ chế phục hồi có thể chạy lại job dù hóa đơn đã tồn tại.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Dùng khóa nghiệp vụ ổn định, chẳng hạn khách hàng kết hợp kỳ thanh toán. Với thao tác trong database, unique constraint và transaction có thể gắn việc tạo hóa đơn với bản ghi đã hoàn tất. Khi retry, hệ thống tìm lại kết quả thay vì tạo thêm hóa đơn.

Với nhà cung cấp bên ngoài, dùng idempotency key nếu được hỗ trợ và đối soát kết quả chưa rõ. Chỉ dùng job ID hoặc giữ bản ghi job trong queue không phải bảo đảm vĩnh viễn rằng tác dụng nghiệp vụ không lặp. [Job có tính idempotent](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Hiểu lock bảo đảm được gì

Lock dùng chung phải được lấy bằng thao tác nguyên tử. Dùng token sở hữu, thời hạn và gia hạn; chỉ nhả lock khi token vẫn khớp. Nếu không, worker cũ có thể nhả nhầm lock của worker mới.

Hết hạn còn tạo một tình huống khác: worker bị tạm dừng chạy tiếp sau khi lease hết hạn, trong lúc worker mới đã bắt đầu. Ghi dữ liệu quan trọng có thể cần fencing token, tức số quyền sở hữu tăng dần để nơi nhận từ chối worker lỗi thời. Chỉ đặt timeout dài không loại bỏ được rủi ro này.

Nếu hệ thống phối hợp không truy cập được, cần quyết định tác vụ có nên chờ thay vì chạy không có quyền sở hữu. Với công việc có hậu quả nghiệp vụ, chờ thường là lựa chọn an toàn hơn.

## 5. Kiểm chứng các tình huống lỗi

Thử nhiều node, crash sau khi tạo hóa đơn, tạm dừng lâu hơn lease, mất kết nối Redis và rolling deployment. Ghi lại ngày nghiệp vụ, worker, lần thử và kết quả để phân biệt chạy lại với tạo tác dụng lặp.

**Cách nhớ:** phối hợp lịch → giới hạn thực thi dùng chung → làm thao tác nghiệp vụ retry an toàn → thử phục hồi. “Một job active” chưa chứng minh nghiệp vụ chỉ xảy ra đúng một lần.

Tình huống	Hướng cân nhắc	Trách nhiệm còn lại
Nền tảng đã có dịch vụ chạy theo lịch	Đưa lập lịch ra ngoài các instance web	Cấu hình chạy chồng, khôi phục và xử lý lượt bị bỏ lỡ.
Team đã vận hành BullMQ	Job Scheduler dùng chung và queue riêng	Cấu hình concurrency toàn cục và retry an toàn.
Tác vụ hiện tại phải nằm trên các node ứng dụng	Lock hoặc lease dùng chung	Xử lý đúng quyền sở hữu, hết hạn và worker cũ.

1. Hiểu vì sao mọi node cùng bắt đầu

2. Chọn cách phối hợp

3. Bảo vệ hóa đơn, không chỉ bảo vệ job

4. Hiểu lock bảo đảm được gì

5. Kiểm chứng các tình huống lỗi

Câu hỏi liên quan