n8n xử lý hàng nghìn bản ghi: loop, batch hay queue?

Nhiều node n8n chạy một lần cho mỗi item đầu vào theo cơ chế mặc định. Thêm Loop Over Items với batch size 1 trong trường hợp này có thể làm workflow dài hơn, tăng overhead và khiến trace khó đọc mà không tạo thêm độ an toàn. Trước tiên hãy thử đưa nhiều items trực tiếp vào node đích và kiểm tra operation đó có hỗ trợ bulk hay tự lặp theo item hay không.

Loop hữu ích khi có yêu cầu rõ ràng: phân trang cho đến khi hết dữ liệu, chèn Wait giữa các batch để tuân thủ quota, tích lũy kết quả qua nhiều vòng, hoặc xử lý tuần tự vì thứ tự có ý nghĩa. Nếu một item lỗi, hãy xác định node dừng toàn bộ execution hay tiếp tục output lỗi. Không bật Continue On Error một cách mù quáng; record thất bại phải được ghi lại cùng correlation ID, lý do và trạng thái retry.

Batch giúp giới hạn số item tồn tại trong một bước, kích thước request, thời gian transaction và tốc độ gây tải lên API hoặc database. Nếu API hỗ trợ bulk endpoint, một batch 100 records có thể hiệu quả hơn 100 request đơn; nếu API áp quota theo request hoặc payload, batch size phải tuân theo cả hai. Với HTTP Request, n8n có tùy chọn batching theo số items và khoảng thời gian giữa các batch; tài liệu rate-limit cũng hướng dẫn kết hợp Loop Over Items với Wait khi cần.

Bắt đầu bằng batch nhỏ có cơ sở, chẳng hạn theo giới hạn chính thức của API, rồi load test. Đo throughput, p95 latency, tỷ lệ 429/5xx, memory peak và thời gian retry. Tăng batch cho đến trước điểm latency hoặc lỗi tăng mạnh. Mỗi batch cần batch_id, phạm vi record, attempt count và idempotency key. Chỉ đánh dấu hoàn tất sau khi downstream xác nhận; checkpoint theo batch giúp resume từ phần chưa xong thay vì chạy lại toàn bộ dataset.

Queue mode phù hợp khi nhiều workflow hoặc nhiều chunk có thể chạy độc lập và hệ thống cần scale worker ngang. Theo kiến trúc n8n, main instance nhận timer/webhook, tạo execution và đưa job qua Redis; worker thực thi và ghi kết quả vào database. Có thể đặt concurrency cho từng worker, nhưng tăng concurrency quá cao sẽ chuyển bottleneck sang Postgres, Redis, CPU, memory hoặc API đích.

Queue mode không phải message broker nghiệp vụ cho từng record. Nếu producer tải 50.000 records rồi truyền tất cả qua một execution, worker vẫn phải giữ và xử lý payload đó. Muốn song song an toàn, producer nên chia thành chunk và tạo nhiều execution nhỏ, hoặc ghi job vào database/outbox rồi kích hoạt worker workflow theo job. Mỗi job cần trạng thái pending, processing, completed, retryable_failed hoặc dead_lettered; lease timeout giúp thu hồi job khi worker chết giữa chừng.

Producer chỉ đọc nguồn theo cursor ổn định, chuẩn hóa khóa định danh và ghi job theo chunk vào bảng job/outbox. Unique constraint trên (source, record_id, operation_version) ngăn tạo job trùng. Một dispatcher claim job bằng thao tác atomic, gán lease và gọi worker workflow với job_id, không nhét toàn bộ payload lớn vào queue message. Worker lấy dữ liệu cần thiết, xử lý một batch, ghi kết quả theo idempotency key rồi ack.

Lỗi tạm thời như timeout, 429 hoặc 5xx được retry bằng exponential backoff có jitter và giới hạn attempt. Lỗi dữ liệu hoặc quyền truy cập sai đi thẳng vào DLQ để điều tra, không retry vô hạn. Nếu downstream không hỗ trợ idempotency key, lưu bảng operation ledger trước khi side effect và kiểm tra lại khi retry. Với Kubernetes, scale worker theo queue depth và tuổi job, nhưng luôn đặt ceiling dựa trên database pool và quota downstream.

Thiết lập bốn nhóm guardrail. Correctness: idempotency key, unique constraint, deterministic cursor và reconciliation sau chạy. Load control: batch size, worker concurrency, rate limiter và backpressure khi queue age tăng. Recovery: bounded retry, exponential backoff, checkpoint, lease timeout và DLQ có replay chọn lọc. Observability: records/second, success/failure theo reason, retry count, queue depth, oldest-job age, p95 job latency và memory peak.

Tránh giữ binary hoặc payload đầy đủ qua nhiều node; loại field không cần thiết càng sớm càng tốt. n8n khuyến nghị chia workflow và giới hạn dữ liệu sub-workflow trả về để giảm memory pressure. Cấu hình lưu/prune execution data theo nhu cầu audit thay vì lưu mọi payload vô thời hạn. Trước khi production, hãy kill một worker giữa batch, mô phỏng 429, gửi trùng cùng input và xác nhận hệ thống resume mà không thiếu hoặc tạo side effect lặp.

FAQ

1. Có bao nhiêu bản ghi thì phải dùng queue?
Không có ngưỡng chung. Queue cần thiết khi có nhiều execution độc lập, cần scale worker hoặc tách retry; vài nghìn records vẫn có thể xử lý tốt bằng bulk/batch nếu payload và SLA phù hợp.

2. Batch size nên là bao nhiêu?
Lấy giới hạn API/database làm trần, bắt đầu nhỏ rồi load test theo throughput, p95, lỗi và memory. Không sao chép một con số giữa hai connector khác nhau.

3. Loop Over Items với batch size 1 có an toàn hơn không?
Không mặc định. Nó giảm số item mỗi vòng nhưng tăng số lần gọi và thời gian; an toàn chỉ tăng khi có checkpoint, retry policy và lưu record lỗi đúng cách.

4. Bật n8n queue mode có tự chia items cho nhiều worker không?
Không. Queue mode phân phối workflow executions. Muốn nhiều worker xử lý các chunk độc lập, workflow phải chủ động tạo các execution/job nhỏ.

5. Làm sao retry mà không ghi dữ liệu trùng?
Dùng idempotency key hoặc unique constraint gắn với identity và operation version; ghi trạng thái job bền vững và chỉ retry lỗi tạm thời.