n8n queue mode: xử lý khi workflow xếp hàng chờ chạy

Workflow chạy đúng logic. Nhưng mất nhiều phút mới tới lượt, trong khi CPU trên VPS vẫn còn dư. Đó là dấu hiệu quen thuộc của chế độ mặc định: một tiến trình xử lý mọi thứ tuần tự, dù máy có bao nhiêu nhân đi nữa.

n8n queue mode là gì và khác chế độ mặc định ở đâu

n8n queue mode tách việc nhận trigger ra khỏi việc thực thi workflow. Một tiến trình main nhận request rồi đẩy job vào hàng đợi Redis. Một hoặc nhiều tiến trình worker lấy job ra chạy song song. Chế độ mặc định gộp cả hai việc vào một tiến trình duy nhất. Kết quả: workflow phải xếp hàng chờ tới lượt dù server còn nhân CPU rảnh.

Theo tài liệu n8n, biến môi trường EXECUTIONS_MODE quyết định n8n chạy regular hay queue. Đặt giá trị queue thì n8n bắt buộc có Redis chạy kèm. Máy chưa cài Redis từ đầu thì phải dựng thêm trước khi bật được. VPS n8n cài sẵn đã có Redis chờ sẵn cho việc này. Hàng đợi job lưu trong Redis, không nằm trong bộ nhớ của tiến trình chính.

Dấu hiệu nhận biết đã tới lúc bỏ chế độ một tiến trình

Ba dấu hiệu thường gặp. Log ghi nhiều execution cùng ở trạng thái waiting dù CPU chưa đầy. Webhook trả response chậm hẳn vào giờ cao điểm. Một workflow chạy lâu, ví dụ gọi API bên ngoài hoặc xử lý file lớn, làm nghẽn cả các workflow khác phía sau nó.

Regular mode xử lý workflow theo đúng thứ tự nhận request. Một job mất 40 giây thì mọi job đến sau, kể cả job chỉ mất nửa giây, phải đợi đủ 40 giây đó mới bắt đầu. Ba tình huống hay lộ ra vấn đề nghẽn hàng nhất: nhiều webhook bắn cùng lúc từ một chiến dịch marketing, một đợt import dữ liệu, hoặc một khách hàng gửi nhiều đơn liên tiếp.

Workflow ít, chạy rải rác trong ngày, không job nào kéo dài thì giữ regular mode vẫn đủ. Bật queue mode khi hệ thống chưa nghẽn chỉ thêm một tầng vận hành. Không đổi lại gì.

Bài toán RAM mỗi worker: vì sao thêm worker không phải lúc nào cũng lợi

Mỗi worker process trong n8n giữ riêng một bản sao workflow đang chạy trong bộ nhớ, cùng dữ liệu trung gian giữa các node. Node xử lý file hoặc mảng dữ liệu lớn kéo mức dùng RAM của một worker lên vài trăm MB chỉ trong một lần thực thi.

Thêm worker mà không tính RAM khả dụng dẫn tới hệ điều hành phải swap. Tốc độ xử lý tụt sâu hơn cả lúc chưa tách worker. Cách tính đơn giản: lấy RAM khả dụng, trừ phần PostgreSQL và hệ điều hành cần, chia cho mức RAM trung bình một worker tiêu tốn khi workflow nặng nhất đang chạy. Ra bao nhiêu thì đó là trần số worker. Không phải muốn thêm bao nhiêu cũng được.

Cấu hình tối thiểu để bật queue mode

Bật queue mode cần bốn phần đứng riêng: Redis lưu hàng đợi, PostgreSQL lưu dữ liệu execution, tiến trình main nhận webhook, và ít nhất một tiến trình worker xử lý job. Thiếu Redis, n8n không khởi động được ở chế độ này. Đây là điểm khác biệt lớn nhất so với regular mode, vốn chỉ cần SQLite là chạy.

Ba biến môi trường cốt lõi. EXECUTIONS_MODE=queue bật chế độ hàng đợi. QUEUE_BULL_REDIS_HOST trỏ tới địa chỉ Redis. N8N_CONCURRENCY_PRODUCTION_LIMIT giới hạn số job một worker xử lý đồng thời. Tài liệu n8n khuyến nghị đặt limit theo tài nguyên thực của worker thay vì để mặc định. Tránh một worker ôm quá nhiều job cùng lúc rồi hết bộ nhớ.

Tách main process và worker process

Trong queue mode, lệnh n8n start chạy tiến trình main. Lệnh n8n worker là lệnh riêng để khởi động tiến trình worker. Hai tiến trình này chạy được trên cùng một VPS. Cũng tách được ra hai máy khác nhau khi khối lượng lớn hơn.

Theo dõi worker còn sống hay đã treo

Worker treo mà không ai biết là lỗi hay gặp nhất sau khi tách tiến trình. Job vẫn vào hàng đợi nhưng không ai lấy ra chạy. Execution đứng ở trạng thái chờ vô thời hạn. Cần một cơ chế kiểm tra tiến trình worker định kỳ. Dashboard n8n không tự báo worker đã chết, đây là việc quản trị máy chủ theo tháng thường đảm nhận thay đội kỹ thuật nội bộ.

Chuyển sang queue mode ảnh hưởng gì tới workflow đang chạy

Chuyển đổi không tự sửa lại workflow đã dựng. Nhưng nó đổi cách webhook phản hồi. Main process trả response ngay sau khi đẩy job vào hàng đợi. Kết quả thực thi thật sự đến sau, qua worker. Workflow nào cần trả dữ liệu xử lý ngay trong response webhook phải kiểm tra lại logic. Thứ tự trả về đã khác so với regular mode.

Một điểm dễ bỏ sót: dữ liệu binary như file tải lên, ảnh, PDF, truyền giữa main và worker qua Redis hoặc hệ thống file chung. Nó không còn nằm trong bộ nhớ một tiến trình duy nhất như trước. Workflow xử lý file cần kiểm tra cấu hình lưu trữ binary trước khi chuyển. Không thì file rơi mất giữa hai tiến trình.

Khi nào cấu hình máy chủ cần nâng cấp thay vì thêm worker

Thêm worker chỉ giải quyết được nghẽn hàng đợi khi máy còn tài nguyên chưa dùng tới. CPU đã chạy gần kín, hoặc RAM đã sát trần lúc chỉ có một worker? Thêm worker thứ hai không chia đều tải. Cả hai tranh nhau tài nguyên. Kết quả chậm hơn ban đầu.

Hai dấu hiệu cần nâng cấu hình thay vì thêm worker: mức dùng CPU trung bình đã trên 70% khi chỉ chạy một worker, hoặc RAM còn lại sau khi trừ PostgreSQL và Redis không đủ cho một worker chạy job nặng nhất. Lúc này nâng từ gói 2 vCPU lên 4 vCPU, hoặc từ 4 GB lên 8 GB RAM. Giải quyết đúng gốc vấn đề. Nhồi thêm worker vào máy đã chật không giúp được gì. Đội chưa quen theo dõi CPU và RAM hàng ngày có thể để đội vận hành máy chủ BizMaC giám sát và đề xuất nâng cấp đúng lúc.

Chưa muốn tự dựng cụm worker thì có thể bắt đầu bằng gói VPS n8n cài sẵn, nâng cấu hình khi lượng workflow tăng.

Câu hỏi thường gặp về n8n queue mode

Ghi nhanh

• Regular mode gộp nhận request và thực thi vào một tiến trình. Workflow xếp hàng tuần tự dù CPU còn rảnh.
• Queue mode cần Redis bắt buộc. Tách main process nhận webhook khỏi worker process chạy job.
• RAM mỗi worker tiêu tốn khác nhau theo workflow. Tính trần số worker từ RAM khả dụng, đừng đoán.
• Máy đã chạy CPU trên 70% với một worker thì nâng cấu hình trước, thêm worker sau.